Can Wikipedia Administrators Really Do All These Things?

[Triptych]

Can anyone confirm this, or even shed a little "yeah I'm pretty sure that's right from what I've seen" on it?

Yes, Admins have all sorts of useful powers, including:

* Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
* Bypass automatic blocks of proxies (proxyunbannable)
* Disable global blocks locally (globalblock-whitelist)
* Not be affected by IP-based rate limits (autoconfirmed)
* Not be affected by rate limits (noratelimit)
* Unblock oneself (unblockself)

I'm not meaning to doubt Poetlister in the slightest. His contributions here are respectable as far as I've seen. I've communicated with him and I trust him. I'd just like to get some verification on this, particularly the bypassing of IP blocks. So this would mean administrators may use anonymous proxies, Tor, and so forth at their discretion. Common editors of course are hyperactively and elaborately barred from it.

So this also is connected to my objection to the revision of the Access to Non-Public Information policy a couple months ago that allows completely anonymous checkusers and so forth access to the information of editors that could easily identify them.

As a semi-related side question: The abusive administrator infection on English Wikipedia is overwhelming. They've been killing that patient for an extended period. But what about Meta (meta.wikimedia.org)? Who's running that? Is that basically the WMF's territory? Do the bullying jackass administrators like Bwilkins and Kww and Wormthatturned and so forth have any powers on Meta? Can Wikipedia checkusers checkuser somebody that makes an edit on Meta, to further all their stalking bull? I'd be happy to hear any informed comments on all this stuff.

[Poetlister]

If I can be allowed to confirm my own statement, all user rights are listed here:

http://en.wikipedia.org/wiki/Special:ListGroupRights

There are admins on nearly all WMF sites and checkusers on all the big ones. In general, having powers on one site gives you no powers anywhere else, but of course it is possible to be an admin on several sites. There is a tool to list these things:

Bwilkins: http://tools.wmflabs.org/quentinv57-too ... erousPanda

Kww: http://tools.wmflabs.org/quentinv57-too ... ername=Kww

Nothing anywhere except English WP.

Worm: http://tools.wmflabs.org/quentinv57-too ... hat+Turned

Trivial power on Meta, otherwise nothing.

Thus a checkuser has no power on other sites, although all checkusers exchange information via a mailing list and no doubt some use private e-mails. And of course they can ask each other to do checks. There are five checkusers on meta: Barras, Billinghurst, Tiptoety, Trijnstel and Vituzzu. Stewards can checkuser on any site but as a courtesy are unlikely to on a site with its own checkusers.

[spartaz]

The answer to the question is yes. I have no idea why that is but it was certainly useful when I worked in the Gulf and frequently posted from locations where the local internet proxies often left you looking like everyone shared the same IP address (Qatar I'm looking in your direction)

Hope this helps.

[Poetlister]

The answer to the question is yes. I have no idea why that is but it was certainly useful when I worked in the Gulf and frequently posted from locations where the local internet proxies often left you looking like everyone shared the same IP address (Qatar I'm looking in your direction)

Hope this helps.

I assume that it was to enable admins to be more anonymous if they wished.

[spartaz]

I don't know. I don't think it was part of the original admin features bundle when I got my bit in 2007 (but I may be wrong) and no-one bothered to ask me my opinion if it was added on later....

[turnedworm]

Indeed, admins can do all those things. I believe that each time something new gets created, it gets added to the admin toolset by default, which means the toolset gets bigger, the potential harm grows and the standard for new admins grows. How people can still argue that it's "no big deal" is beyond me. Ip-block exception can be granted to individual user if you can find a friendly admin (should be a checkuser) and persuade him/her that there is a good reason to have it for the user. I would prefer it was unbundled from the admin toolset by default so that we could see which admins are adding it to themselves (similar to the edit filter manager)

On the side note, I had no idea I was autopatrolled on meta - it seems an admin added it to my account in 2011, certainly without my asking. I was a lot more active on en.wp at the time, perhaps he'd spotted me.

[Triptych]

Thanks for the great information and confirming links, Poetlister. Thanks for saying "yes, I did that" Spartaz.

In those links it does in fact say that administrators may "bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)." So they can, for example, use Tor.

What Wikipedia English has done over the last several years is create an untouchable and supreme class of user: the administrator. It's attracted the very worst kind of individuals. Something needs to be done. The WMF needs to know that these people are not helping the project. It could vanish the administrative rights of the entire population of WP:AN/ANI and eliminate every checkuser, and I really think Wikipedia would benefit. It could get rid of Arbcom. What is it worth? Nothing. Look at what it does right now: it indulges in a huge bureaucratic undertaking with all these ridiculous court of law-style trimmings in order to figure out what to do about a trio or so of trollish deleters on Jimbo's talkpage. It's stupid. It does nothing worthwhile. It does only bad things. Who the heck trusts Arbcom to hand out checkuser rights? No-one should. Disband it and let the little chumps get back to their original hobbies of blocking good content editors, snickering amongst themselves, and patting each other on the back about it.

[Jim]

Ip-block exception can be granted to individual user if you can find a friendly admin (should be a checkuser) and persuade him/her that there is a good reason to have it for the user. I would prefer it was unbundled from the admin toolset by default so that we could see which admins are adding it to themselves (similar to the edit filter manager)

That sounds like a good idea. Some sort of audit trail seems eminently sensible for an ability which could be used to avoid scrutiny. It cuts both ways - admins who hadn't enabled this for themselves would be less open to speculation of possible abuse. Maybe, like unblocking, it should also be unwise to do this for oneself, instead needing to have a recorded request/reason? That shouldn't be an issue for someone with a genuine need.

[Triptych]

Ip-block exception can be granted to individual user if you can find a friendly admin (should be a checkuser) and persuade him/her that there is a good reason to have it for the user. I would prefer it was unbundled from the admin toolset by default so that we could see which admins are adding it to themselves (similar to the edit filter manager)

That sounds like a good idea. Some sort of audit trail seems eminently sensible for an ability which could be used to avoid scrutiny. It cuts both ways - admins who hadn't enabled this for themselves would be less open to speculation of possible abuse. Maybe, like unblocking, it should also be unwise to do this for oneself, instead needing to have a recorded request/reason? That shouldn't be an issue for someone with a genuine need.

We're overthinking this. Why should administrators be granted this fringe benefit at all? It's not something they need to administrate. Presumably there's a request procedure for the ability to use an anonymous proxy. Let everybody go through that, with neither special status for administrator nor suspicion cast at common editor.

EDIT: or just allow editing across the board from anonymous proxies.

[Jim]

We're overthinking this. Why should administrators be granted this fringe benefit at all? It's not something they need to administrate. Presumably there's a request procedure for the ability to use an anonymous proxy. Let everybody go through that, with neither special status for administrator nor suspicion cast at common editor.

Maybe. Mostly I was just acknowledging that it was something which Worm had already considered, and engaging with what might be productive discussion.
You could be right, though, admins don't need it by default. Except... who will you then trust to grant the right?

Admins granting stuff like rollback, reviewer etc is already done either at "requests for permissions" boards, or by asking an admin personally, so that would be not unlike what I said, and Worm described how IP block exception is currently done for non admins.

[Peryglus]

Here is the full list of admin tools, if anybody is in doubt. Yes, it is very extensive, and yes, it should be treated as a big deal.

Add or remove campus volunteers to courses (ep-campus)
Add or remove instructors to courses (ep-instructor)
Add or remove online volunteers to courses (ep-online)
Add or remove yourself as campus volunteer from terms (ep-becampus)
Add or remove yourself as instructor from courses (ep-beinstructor)
Add or remove yourself as online volunteer from terms (ep-beonline)
Add or remove yourself as reviewer from articles (ep-bereviewer)
Block a user from sending email (blockemail)
Block other users from editing (block)
Bulk delete courses (ep-bulkdelcourses)
Bulk delete institutions (ep-bulkdelorgs)
Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
Bypass automatic blocks of proxies (proxyunbannable)
Change protection levels and edit cascade-protected pages (protect)
Close Flow topics (flow-close)
Configure how the latest accepted revision is selected and displayed (stablesettings)
Create new user accounts (createaccount)
Delete Flow topics and posts (flow-delete)
Delete and undelete specific log entries (deletelogentry)
Delete and undelete specific revisions of pages (deleterevision)
Delete pages (delete)
Disable global blocks locally (globalblock-whitelist)
Disassociate articles from students (ep-remarticle)
Edit Flow posts by other users (flow-edit-post)
Edit other users' CSS files (editusercss)
Edit other users' JavaScript files (edituserjs)
Edit pages protected as "Allow only administrators" (editprotected)
Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)
Edit protected templates (templateeditor)
Edit the user interface (editinterface)
Enroll in Education Program courses (ep-enroll)
Enroll users as student (ep-addstudent)
Have one's own edits automatically marked as patrolled (autopatrol)
Have one's own revisions automatically marked as "accepted" (autoreview)
Hide Flow topics and posts (flow-hide)
Import pages from other wikis (import)
Manage Education Program courses (ep-course)
Manage Education Program institutions (ep-org)
Manage central notices (centralnotice-admin)
Mark others' edits as patrolled (patrol)
Mark revisions as being "accepted" (review)
Mark rolled-back edits as bot edits (markbotedits)
Mass delete pages (nuke)
Merge the history of pages (mergehistory)
Move category pages (move-categorypages)
Move files (movefile)
Move pages (move)
Move pages under pending changes (movestable)
Move pages with their subpages (move-subpages)
Move root user pages (move-rootuserpages)
Not be affected by IP-based rate limits (autoconfirmed)
Not be affected by rate limits (noratelimit)
Not create redirects from source pages when moving pages (suppressredirect)
Override files on the shared media repository locally (reupload-shared)
Override the spoofing checks (override-antispoof)
Override the title or username blacklist (tboverride)
Overwrite existing files (reupload)
Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)
Quickly rollback the edits of the last user who edited a particular page (rollback)
Remove reviewers from articles (ep-remreviewer)
Remove students from courses (ep-remstudent)
Reset failed or transcoded videos so they are inserted into the job queue again (transcode-reset)
Revert all changes by a given abuse filter (abusefilter-revert)
Search deleted pages (browsearchive)
See Education Program enrollment tokens (ep-token)
Send a message to multiple users at once (massmessage)
Unblock oneself (unblockself)
Undelete a page (undelete)
Upload files (upload)
Use higher limits in API queries (apihighlimits)
View information about the current transcode activity (transcode-status)
View a list of unwatched pages (unwatchedpages)
View abuse filters marked as private (abusefilter-view-private)
View deleted history entries, without their associated text (deletedhistory)
View deleted text and changes between deleted revisions (deletedtext)
View detailed abuse log entries (abusefilter-log-detail)
View the spam blacklist log (spamblacklistlog)
View title blacklist log (titleblacklistlog)
jsonconfig-flush (jsonconfig-flush)
Add groups: Edit filter managers, Account creators, Autopatrolled, Confirmed users, File movers, Reviewers, Rollbackers, Template editors, Mass message senders, IP block exemptions, Autochecked users, Course online volunteers, Course campus volunteers, Course instructors and Course coordinators
Remove groups: Rollbackers, Account creators, Edit filter managers, Autopatrolled, Confirmed users, Reviewers, File movers, Template editors, Mass message senders, IP block exemptions, Autochecked users, Course online volunteers, Course campus volunteers, Course instructors and Course coordinators

[Scott5114]

A lot of these are so that an admin is not collateral damage due to another administrator's actions. The IP block exemption is probably there so that if there is someone else in your school/company/neighborhood/building that is vandalizing and they get blocked, the admin does not get blocked as well, and thus can assist in the cleanup effort. Unblockself is to prevent an admin from taking control of the site or simply causing mass chaos by blocking a large chunk of the site's active admins and doing mischief while someone goes and gets a steward.

There's also some rights that simply make little difference whether they're there or not, like autoconfirmed. Any user granted adminship would have necessarily have edited enough to be automatically granted autoconfirmed, and even if they didn't, admins can edit protected pages anyway, so not having autoconfirmed wouldn't stop them from editing a semi-protected page anyway.

Many of these permissions make more sense on a smaller wiki than they do on today's Wikipedia. Also, there is the thinking that by being granted admin rights, the user must surely be trustworthy enough to hold these rights, since otherwise they wouldn't have been granted in the first place (which explains things like autopatrolled and the IP block exemption, since surely an admin wouldn't be vandal too).