Wikipedia:Village pump (proposals)/Archive 155

As raised on this thread at

• Version A – No
  bureaucrats
  , are allowed to self-unblock.
• Version B – Only bureaucrats can unblock themselves. Other admins cannot unblock themselves.
• Version C – Status quo. Any admin can self-unblock.

^Semi_Hypercube ✎ 14:42, 23 November 2018 (UTC)

Clarification I'm not talking about policy, I'm talking about the technical ability (the (unblockself) permission) to self-unblock. ^Semi_Hypercube ✎ 20:29, 23 November 2018 (UTC)

Er, what? Version C is pretty much diametrically opposite to the status quo, which is Version A other than in the case of self-blocks, as spelled out in weary detail at

Iridescent

15:01, 23 November 2018 (UTC)

@

Iridescent: my reading of this is that it is about technical measures. And it should not be hard to remove the 'unblockself' permission from the sysop group if we really wanted to for just our project. — xaosflux ^Talk

15:17, 23 November 2018 (UTC)

Removing unblockself could create a security hole if a rogue or compromised admin manages to block all other (active) admins. Doubly so since apparently phab:T19014 implies that blocked bureaucrats would not be able to stop the compromised account. You'd have to wait for steward action which would prolong the time it takes for damage to be constrained. Also, added a phab task where this RfC question is being discussed. Jo-Jo Eumerus (talk, contributions) 15:24, 23 November 2018 (UTC)

@Jo-Jo Eumerus:, but with 'option B' above, a blocked crat (who is also an admin) could unblock themselves, then block the offender, then start unblocking admins who could then in turn unblock other admins. — xaosflux ^Talk 15:29, 23 November 2018 (UTC)

• It seems like common sense to me that if there is a clear cut case of a compromised admin account or an admin gone rogue blocking numerous other admins, an exception to the prohibition on self-unblocking should be in place. Otherwise, in the course of more normal circumstances, neither an admin nor a 'crat should be able to self-unblock. bd2412 T 15:38, 23 November 2018 (UTC)

  @BD2412: I think this is about 'technical controls' not policies. Currently the only practical ways to stop a rogue admin is: (a) desysop them, (b) get a steward to globally lock them. — xaosflux ^Talk 15:42, 23 November 2018 (UTC)

• Version B, assuming that we're talking about technical capabilities. The only generally acceptable reason for an admin to unblock themselves is if they self-blocked, and there's really no reason to do that. Self-blocking by mistake or to enforce a wikibreak is easily rectified by pinging another admin, and we have test accounts for admins to test the block functions. An admin blocked by a rogue account can and should contact a 'crat immediately. The community has already basically strongly rebutted all other previous and potential uses of self-unblock; there is no good reason for it to be available, and several very good reasons why it should not. But as Jo-Jo Eumerus and xaosflux already suggested, disallowing 'crats from self-unblock is a Bad Idea. Ivanvector (^Talk/_Edits) 15:46, 23 November 2018 (UTC)
• Can we get some stats on how often admins unblock themselves, and under what circumstances? The only bad self-unblock recently has come from Fred Bauder. If there has even been one legitimate self-unblock between now and whenever the last bad one was before Fred, I would be hesitant to remove this permission. -- Ajraddatz (talk) 16:38, 23 November 2018 (UTC)
  • @Ajraddatz: quarry:query/31445. Of the other 8 self-unblocks since 2017-01-01, 4 are undoing accidental self-blocks, 2 are undoing self-blocks for retirement/wikibreaks, and 2 are undoing self-blocks made without any comment. Anomie⚔ 19:55, 23 November 2018 (UTC)
• Status quo our current policy works fine. One person self-unblocking themselves is not a big issue that we need a large RfC on. Admins occasionally do block and unblock themselves and that's perfectly fine. There's no real need for any sort of technical controls such as removing the ability, because self-unblocks that violate policy happens really rarely, and when it does, no real harm is caused. Galobtter (pingó mió) 17:01, 23 November 2018 (UTC)
• I agree that the status quo works just fine. As a practical matter, when I first became an admin, the first user I blocked was myself, to explore how the tool worked. And, then (after a vaguely amusing thread where I asked for help), I unblocked myself. It's not entirely clear if this proposal is intended to address can (as in, the software allows it), or, may (as in, policy allows it). Ether way, what we've got now needs no modification. -- RoySmith (talk) 17:14, 23 November 2018 (UTC)
• Oppose technical restriction – I oppose any technical restriction on self-unblocking for one reason. That's because the bright line that exists is useful for weeding out bad administrators. All administrators have the ability to unblock themselves, but very few will ever actually use that power. Any administrator that is bewitched by the temptation to use it to try and get out of a block placed by another administrator clearly doesn't deserve the administrator bit. The status quo is, in-and-of-itself, a test of fitness to serve. We trust administrators to be able to use their tools responsibly. If they cannot do so, they should be removed. RGloucester — ☎ 17:15, 23 November 2018 (UTC)
• Status quo – No rationale has been provided for the need to remove the technical ability to unblock yourself as admin. Unblocks in violation of
  WP:NEVERUNBLOCK can be handled by desysops as it is done right now. --AFBorchert (talk
  ) 17:26, 23 November 2018 (UTC)
• Keep as is Admins should have the technical ability, but (by policy) are generally not permitted to self-unblock (although I can't see why restoring talk page or e-mail, if needed is generally OK). Crouch, Swale (talk) 17:31, 23 November 2018 (UTC)
• Status quo - it's a bit chilly out tonight, I predict snow. Cabayi (talk) 19:46, 23 November 2018 (UTC)
• Status quo - the timing for this is interesting. Old admin accounts are being hacked and blocks to active admins applied. They should certainly have the ability to reverse this trolling. Flare ups like the the that brought this proposal about can be dealt with on an individual basis. MarnetteD|Talk 19:53, 23 November 2018 (UTC)
• Can you explain what problem you think changing this would solve? Natureium (talk) 21:23, 23 November 2018 (UTC)
• No reason to change. What if someone finds an admin's password (two examples in the last 48 hours) and uses a script to block every other admin? Johnuniq (talk) 22:42, 23 November 2018 (UTC)

I assume in such a situation, the fix would be for a developer to do some direct database manipulation to block the rogue user and unblock all the admins. -- RoySmith (talk) 04:37, 24 November 2018 (UTC)

In 2015, when we were doing the batch adminbot blocks for the Orangemoody socking case, it took 14 minutes to block 381 accounts, and it was blocking based on an account list posted on enwiki; it's my understanding that blocking was throttled to 30/min. I'm pretty sure if we suddenly saw 30 accounts a minute being blocked, someone would be able to get it globally locked within the first 3-5 minutes of action, and I'm also sure that blocking the bad-guy account would disrupt the process, as well. But it wouldn't take very long to unblock, especially if someone had an adminbot handy. Risker (talk) 05:18, 24 November 2018 (UTC)

With Version B, if every other admin were blocked, a bureaucrat could unblock themselves and then desysop the rogue/compromised admin account and unblock the previously blocked admin. ^Semi_Hypercube ✎ 18:06, 24 November 2018 (UTC)

@SemiHypercube: in version B the desysop wouldn't even have to happen, the bad admin could just be blocked (since they wouldn't be able to unblock themselves). — xaosflux ^Talk 18:12, 24 November 2018 (UTC)

@Xaosflux: Which could also mean that if they were fast enough, any admin could block and stop the rogue/compromised admin, rather than only a bureaucrat. ^Semi_Hypercube ✎ 18:16, 24 November 2018 (UTC)

• Status quo: This proposal is an engraved invitation to a Denial-of-service attack. --Guy Macon (talk) 06:30, 24 November 2018 (UTC)
• Status quo - The number of appropriate self-unblocks (i.e. for self-blocks) far exceeds the number of inappropriate ones. This hasn't really been a serious issue for years, and I've long considered not self-unblocking to be like a cardinal rule of being an administrator, to the extent that it begs the question: if we can't trust an administrator not to unblock themselves, then why should we trust that user to be an administrator at all? Mz7 (talk) 00:09, 25 November 2018 (UTC)

  Striking my comment in light of the new information below – apparently removing (unblockself) from the administrator package will not prevent the administrators from unblocking themselves if they were the ones who blocked themselves. I will have to think this over some more, but that takes care of the main issue I had with Versions A and B of the proposal. Mz7 (talk) 03:12, 26 November 2018 (UTC)

• Version A The commonly cited objection of accidental self-block isn't a real issue given Anomie provided statistics above. Worry over a rogue admin account blocking every other (active) admin accounts and presumingly then being able to go on a wrecking spree unchecked is perhaps misguided. When there's a rogue admin account, we already require either crat desysop or outside assistance (steward lock) to stop them precisely because such an account is able to self unblock. Removing unblockself means a rogue admin account can be stopped immediately by another admin blocking them. In the scenario of a rogue admin account blocking every other admin, given the throttle mentioned by Risker, the rogue account would be locked long before they're able to finish what they're doing. -- KTC (talk) 02:03, 25 November 2018 (UTC)
• Question Can a blocked admin account block someone else? -- KTC (talk) 02:03, 25 November 2018 (UTC)

  @KTC: no, the only thing a blocked admin can do that a normal blocked editor can not do is unblock themselves. — xaosflux ^Talk 02:07, 25 November 2018 (UTC)

  @Xaosflux: Thanks for the response, but are you sure? I just remembered someone admining through a block back in 2015 by doing revision deletion on a page while they were blocked (and was desysop as a result partly because of that). -- KTC (talk) 02:30, 25 November 2018 (UTC)

  I think there are a few random things that are still allowed even if you are blocked. I did go over to testwiki/test2wiki (where I am an admin), blocked myself, and found that I could not block anyone else. --Rschen7754 02:34, 25 November 2018 (UTC)

  @Rschen7754:, @KTC:, I was wrong - there are still some things blocked admins can do. I'm not going to publish a whole list here. — xaosflux ^Talk 02:46, 25 November 2018 (UTC)

  Notably "edit" and "block users" are not some of them. — xaosflux ^Talk 02:48, 25 November 2018 (UTC)

  @KTC: revision delete is not one of them, however viewdeleted is. — xaosflux ^Talk 02:51, 25 November 2018 (UTC)

• Status quo There is a
  policy restricting it. ―Abelmoschus Esculentus ^{talk / contribs}
  03:02, 25 November 2018 (UTC)

  @Abelmoschus Esculentus: I don't know how much we have to say this: this is for the technical ability of admins to self-unblock, not policy. ^Semi_Hypercube ✎ 03:59, 25 November 2018 (UTC)

@SemiHypercube: I am saying that since there is a policy restricting it, there’s no need to have technical restrictions on it. Also, what if the situation mentioned by Johnuniq really happens? Sorry for not making it clear. ―Abelmoschus Esculentus ^{talk / contribs} 04:14, 25 November 2018 (UTC)

self-unblock (when blocked by other sysop) - desysop ―Abelmoschus Esculentus ^{talk / contribs} 04:18, 25 November 2018 (UTC)

• Status quo It might seem like a good idea at first, but we have a lot of test blocks and accidental block to oneself, as well as when rouge admins block legit ones. Even when problems occur, they can get resolved by other means (ArbCom, desysoping) quite quickly. funplussmart (talk) 05:14, 25 November 2018 (UTC)
• Version A solves a number of problems both in general situations (two admins wheel warring for example), but also, more so IMHO, in the security of accounts, one block by any admin immediately stops a compromised account. As well as for compromised accounts this will also likely remove the necessity for emergency desysops since a normal enforcement method, used on every other account, will actually be able to stop an admin account. Stewards have shown in the latest series of compromised admin accounts that they are very able to respond quickly if there is a problem. Regarding the comments about blocking oneself unintentionally, there's already a warning which appears when trying to do that, so if there's a concern that people will miss that it can be made more obvious. Callanecc (talk • contribs • logs) 07:48, 25 November 2018 (UTC)
  • Just coming back to reinforce my support for version A after I found that admins even without the selfunblock permission can still remove blocks they imposed on their own account. Callanecc (talk • contribs • logs) 06:42, 26 November 2018 (UTC)
• Status quo too many problems. feminist (talk) 08:10, 25 November 2018 (UTC)
• (Non-administrator comment) Is it possible to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself? (I am not
  ping me if you want my attention.) wumbolo ^^^
  10:22, 25 November 2018 (UTC)

  Not as currently implemented in the software. It would require asking the developer community to work on that for us, and that seems like a nontrivial task. But we could always ask, I suppose. Mz7 (talk) 11:37, 25 November 2018 (UTC)

  @Wumbolo: According to John Cline and Ajraddatz below, this is apparently precisely the functionality that removing (unblockself) would result in. So yes, it is possible, and if this RfC is successful, that is the functionality that we will get. Mz7 (talk) 03:12, 26 November 2018 (UTC)

• Very bad use of developer resources. Malicious self-unblocks happen maybe once every decade. They are grounds for immediate loss of sysop access. On the other hand, admins accidentally block themselves fairly often. It’s easy to click the wrong link. This is a trivial block that they are allowed to undo. Don’t waste real peoples time trying to solve a problem that almost never happens, and create a new problem that happens more frequently. Jehochman ^Talk 12:35, 25 November 2018 (UTC)

  Resources wise, we're talking seconds to add or remove a right to a userground. Malicious self-unblocks once every decade, did you miss the 3 compromised admin accounts in the last 3 days doing it? Accidental self-block unblock, 4 in last 2 years. It's really not as commons as everyone think it is, or maybe as it used to be. -- KTC (talk) 18:50, 25 November 2018 (UTC)

• One would think that an organization that spends
  many millions of dollars on software development would have long ago changed the wiki software so that if you click the wrong link and block yourself a big red ARE YOU SURE??? would come up with the user having to type in the three letters "yes" (not just "y") to continue. Alas, we have a culture where making the software elegant, easy to use and generally excellent is not a priority, and administrators are especially prone to putting up with software that is OK but not great. This attitude is not new: during the Civil War cannonballs were slow enough so that if you noticed one coming at you you had time to duck. The problem was that it wasn't considered manly to duck.^{[citation needed]} --Guy Macon (talk
  ) 19:37, 25 November 2018 (UTC)

• Adding that big red ARE YOU SURE??? would be a good thing to combine with taking away the ability to unblock anyone while you are yourself blocked. I'm just saying. --Guy Macon (talk) 19:44, 25 November 2018 (UTC)

• It alreadys does, in red, right above the field for entering who to block. -- KTC (talk) 19:56, 25 November 2018 (UTC)

Does it make you type the word "yes" (not just "y" or clicking on a button)? It is a well known effect in human engineering that people who see a lot of "are you sure?" warnings tend to click the OK button or hit the yes key on autopilot no matter what the text of the message is. making them type something different for the rare warnings is a proven method of avoiding such errors. --Guy Macon (talk)

@Guy Macon: If you try to block your self you get 2 differences: (1) A big red warning (2) You have to check an extra "confirm block" box before proceeding. — xaosflux ^Talk 17:43, 26 November 2018 (UTC)

(ec) Anyone capable of accidentally blocking themselves after that lacks the reading skills necessary for adminship. DuncanHill (talk) 17:48, 26 November 2018 (UTC)

And we could change that to "Confirm self-block - you will not be able to undo this!" or the like. — xaosflux ^Talk 17:46, 26 November 2018 (UTC)

Note that even without unblockself admins can still remove self-imposed blocks - tested and confirmed with technical staff. -- Ajraddatz (talk) 17:51, 26 November 2018 (UTC)

Yeah, I should clarify—in case my comment directly above yours was confusing—that revoking the ability to unblock oneself is a solution that has indeed already been implemented, and it would be trivial work to remove that right from administrators, and that is what this discussion is about. What hasn't been implemented is "to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself". Mz7 (talk) 20:39, 25 November 2018 (UTC)

John Cline (talk

) 02:01, 26 November 2018 (UTC)

Fascinating. I just tested and it is still valid; removing the unblockself permission will not prevent admins from unblocking themselves unless this is changed. -- Ajraddatz (talk) 02:09, 26 November 2018 (UTC)

@

John Cline: Wait... really? This is a game-changer, actually. If this had been advertised from the start of the RfC, I think it would have changed some minds. I will go and strike my comments above as I rethink. Mz7 (talk

) 03:14, 26 November 2018 (UTC)

@

John Cline: fix ping Mz7 (talk

) 03:14, 26 November 2018 (UTC)

Yep, just did some more tests to confirm. On the beta cluster, I created a user group with only the block right and not unblockself. My test account was able to block itself and remove the self-imposed block. When I blocked my test account with my main account, my test account was unable to unblock itself. Tl;dr if we remove the unblockself permission from admins here they would still be able to remove self-imposed blocks. -- Ajraddatz (talk) 04:21, 26 November 2018 (UTC)

• Support Version A. The rest of us can't unblock ourselves if an admin has a moment's idiocy, I don't see why, in the case of a self-block, the person who had the moment's idiocy should be allowed to unblock themselves, and if they've been blocked by someone else then they should follow the same procedures to request an unblock as the rest of us. DuncanHill (talk) 19:42, 25 November 2018 (UTC)
• Comment would it be possible to add a ten-minute "cooldown" before the unblock can occur? The recent hijacking-vandalism has involved multiple admin-self-unblocks, and a ten-minute cooldown would be a benefit for all of them.
  π, ν
  ) 19:50, 25 November 2018 (UTC)
• Support Version A. Administrators should not be more equal than others. Even in the event of a mistake and blocking themselves, the administrators are enough of a clique they can contact another administrator and at worst suffer the indignity of being blocked for a few minutes. How many of them already have multiple accounts, much less the email addresses of some of their cohorts? Or at worst, sign in as an IP. If someone is blocked for cause, there should be enough documentation that anybody of the stature of an administrator should be able to make a rational decision as to whether the block is for cause or an accident. Trackinfo (talk) 20:00, 25 November 2018 (UTC)

@

there's a cabal? Not criticism of your reasoning, just what I'm wondering. ^Semi_Hypercube ✎

01:50, 26 November 2018 (UTC)

• Support A. How many of you remember the Robdurbar incident? An admin went rogue, blocking a collection of people and deleting a bunch of important pages, and it took a good while to find anyone able to desysop him. Three times he was blocked, and three times he unblocked himself — there was no way to stop him from continuing his rampage until he lost sysop rights. From a technical perspective, any admin should be able to stop any other admin and any bureaucrat from acting until someone else intervenes: we're too big for a single user to be able to block everyone else without getting noticed and stopped (and we also have the stewards who could intervene), and in the event of a rogue admin, there will be no difficulty whatsoever in unblocking all the wrongly-blocked people once the rogue has been stopped. Note that I've three times attempted a self-unblock: once after blocking myself, once after someone else blocked me (I requested a block to do some testing, so I unblocked once the test was complete), and once after autoblocking myself via blocking my alt account (I had to request assistance for that one). In the final situation, I had to wait only ten minutes despite some confusing technical issues; if you can demonstrate that a compromised account has blocked you, the unblock should be nice and quick, and you can use the opportunity to say "User:Soandso is compromised or rogue and should be blocked before you unblock me" so others are aware of the situation. Nyttend (talk) 22:21, 25 November 2018 (UTC)
• Status quo The problem this purports to solve is small conpared to the problem that it might create.S Philbrick(Talk) 00:12, 26 November 2018 (UTC)
• Version A. If there is a disagreement or issue as to why, like everybody else, a discussion can be had at an appropriate place to work out the next step. There is no emergency as to why an admin will need to unblock themselves to do something. This ability IMO is strange and prone to disruption; the ability of an admin to go on a short break without admin tools does not justify it. --Tom (LT) (talk) 00:31, 26 November 2018 (UTC)
• Version B. If a crat account goes haywire, it would be very difficult to deal with, but the difficulty is only increased marginally with version B. Furthermore, version B prevents 'Crats from being locked out by a hijacked admin account, and hence unable to unblock admins, or indeed perform a desysop (probably? I don't know for sure). The status quo allows havoc until a desysop occurs - in one recent case, version B would have reduced the vandalism of the main page to one occurrence, rather than two. Of course, a legitimate alternative is to allow blocked admins to unblock users other than themselves, but in the context of recent compromised accounts, that's unlikely to prevent the attacks, since multiple admin accounts have been hijacked. And there's the old idea of allowing sacrificial desysopping by admins, which I would suggest is probably a better solution than any of the current options. ∰Bellezzasolo✡ Discuss 01:11, 26 November 2018 (UTC)

• Bellezzasolo, I've supported that in the past, and I'd support it again if it were proposed; it would resolve the issue at hand here without affecting people who have good reason to unblock themselves uncontroversially. I just doubt that such a proposal would go anywhere. Nyttend (talk) 01:42, 26 November 2018 (UTC)

• Someone wrote an extension to do that some time ago. Since stewards have a ~2 minute response time, and compromised accounts should typically be locked before they are desysopped, I'd say that there would be limited benefit to actually implementing this extension. -- Ajraddatz (talk) 01:49, 26 November 2018 (UTC)

• @
  WP:BEANS and all that, but a compromised crat account plus an automated script might take a concerted effort of stewards to solve. Actually, that's something that none of the proposals here address, I've emailed the beans. ∰Bellezzasolo✡ Discuss
  14:49, 26 November 2018 (UTC)

• Yes, we can all think of doomsday scenarios. But the better approach is to focus on attacks that are likely to happen and reduce the risk that they do. Version A helps in both a doomsday blockbot scenario and the previously-seen compromise attacks, since any "good" admin can stop the abuse immediately without steward intervention. -- Ajraddatz (talk) 16:02, 26 November 2018 (UTC)

• I strongly disagree. We should make Wikipedia resistant to attacks that haven't happened yet. Ignoring a known vulnerability because nobody has exploited it yet is a classic indicator that idiots are in charge of security. (To be clear, I am talking about those in charge of security, not anyone here. We aren't expected to know about such things. Also, the WMF people in charge iof security appear to be doing an excellent job.) "That would be really easy to correct if it ever happened and a lot of work to prevent" is a good argument for ignoring a known threat, but "nobody has tried that one yet" is not. --Guy Macon (talk) 17:49, 26 November 2018 (UTC)

• Version B - self-unblocks only add fuel to the drama fire. (Ideally, would support version A, but there might be a security risk with blocking CRATs). Renata (talk) 02:31, 26 November 2018 (UTC)
  • @Renata3: What would the security risk be? Stewards have shown that they're very quick to respond to a compromised account. Having a compromised crat account which can remove userrights as well as everything else is worse than an admin account. Callanecc (talk • contribs • logs) 07:15, 26 November 2018 (UTC)
    • There are certain hours of the day (at least when I was a global sysop looking for a steward) when there are fewer around. Won't say what those are onwiki, of course. Personally, I would like to see self-unblock restricted to a group like CU/OS or even interface admin, as those groups are pragmatically required to take extra precautions with their accounts. A lot of our bureaucrats are sadly as inactive as the admins who are getting their accounts compromised. --Rschen7754 07:41, 26 November 2018 (UTC)
• Status quo There is no demonstrated need for a change; the current situation works fine. --Jayron32 03:15, 26 November 2018 (UTC)
• Version A basically per Nyttend -FASTILY 05:54, 26 November 2018 (UTC)
• Version A. If an admin blocks every other admin, that's what we have stewards for (who all have global unblockself permissions). There is no security problem here. Kevin (aka L235 · t · c) 06:04, 26 November 2018 (UTC)
• Version A because there is no reason for administrators on enwiki to have this right. ~ ToBeFree (talk) 07:13, 26 November 2018 (UTC)
• None of the above I don't really like any of these options. With option A, yes, stewards could self-unblock if everyone was desysopped, but the response time to clean up the damage would be significant, especially if it is a time of day where stewards are not that active. With option B, I'd rather that it wasn't the bureaucrats, as many are sadly as inactive as the admins who are getting their accounts compromised. I'd rather have the self-unblock right be held by CU/OS or even interface admin since they already have to take precautions with their accounts. If I had to go with any I'd say option C, but of course that has its flaws too. --Rschen7754 07:46, 26 November 2018 (UTC)

  @Rschen7754: So basically you're saying a tighter version of version B, right? I mean, that's not a bad idea either, while bureaucrats can desysop it wouldn't be needed with Version A or B if this was just a rogue/compromised admin account, since blocking them would stop since they couldn't self-unblock. ^Semi_Hypercube ✎ 14:15, 26 November 2018 (UTC)

  It would be kinda cool if unblockself could only be used by admins with 2FA enabled. Now that the previous security hole has been patched, it is nearly impossible that a 2FA-enabled account could be compromised. So admins that hate 2FA could continue to not use it, but if their account gets compromised they could be stopped by someone with a safer account. -- Ajraddatz (talk) 16:01, 26 November 2018 (UTC)

• Status quo: It's interesting to note that this RfC meets four out of five of Goode and Ben-Yehuda's characteristics for a moral panic. I bet that after some time has passed, it'll end up meeting all five of them.  Spintendo  08:12, 26 November 2018 (UTC)
• Version A -- No legitimate reason to unblock yourself. I would honestly go further and remove an admin's technical ability to block themselves as well. -- Dolotta (talk) 17:04, 26 November 2018 (UTC)
• Version A - Ofcourse admins have blocked themselves accidentally in the past (or have done so as a test) however both are extremely rare these days (those that block themselves usually ask to be blocked and unblocked) so I don't really see a reason as such to allow self-unblocking. –Davey2010^Talk 18:07, 26 November 2018 (UTC)

  @Davey2010: It has been noted above that even if the (unblockself) permission were removed, admins could self-unblock for self-blocks. ^Semi_Hypercube ✎ 18:15, 26 November 2018 (UTC)

• Status quo. @Nyttend: as one of the affected accounts of the robdurbar incident I still feel, that the DOS affect of the other options is worse that the dangers of leaving the technical abilities as they are. Also since then we have given crats the ability to desysop. Back then we had to wait for a steward. Agathoclea (talk) 18:27, 26 November 2018 (UTC)

• Agathoclea, while I disagree with your conclusion, I have to respect it more strongly because you were involved in the incident. Just one question: DOS affect? If you mean "denial of service", I'm unclear how that fits, so more details would help. Nyttend (talk) 01:57, 27 November 2018 (UTC)

@Nyttend: while this is a moo point now, It allows for a wiki to be shut down if the assailant is fast enaugh and hits the active admins first. Back in the day, the suggestion was made that blocking an admin should result in a automatic desysop. That would stop a rampage in its tracks. the auto de-sysop would be quickly reversed in obvious cases. In not so obvious ARBCOM would decide which of the two gets his bit back Agathoclea (talk) 08:52, 27 November 2018 (UTC)

• Version A I'm pretty sure version A is going to happen soon regardless of the outcome of this discussion. It's not necessarily permanent, though. Right now, accounts are being compromised left and right, a number of them are sysops. Drastic times call for drastic measures. Sometimes every second counts, for example when graphic pornography is placed on the Main Page. The time it takes to go to IRC and type !steward please lock <user> and wait for action is just too long. — MusikAnimal ^talk 18:48, 26 November 2018 (UTC)
• Status quo - Wrong approach to dealing with compromised administrator accounts; better to elect a few more Bureaucrats who are highly active and in various time zones so that emergency desysops are less of a worry. — Godsy ^(TALK_CONT) 20:12, 26 November 2018 (UTC)

  @

  RfB, then go right ahead. Try to find an admin who is up for it. ^Semi_Hypercube ✎

  20:26, 26 November 2018 (UTC)

• These options all have problems. Perhaps a solution could be for blocked admins to be able to block other admins and for admins to be unable to unblock themselves. --Yair rand (talk) 20:28, 26 November 2018 (UTC)

• User:Yair rand, I'm not quite clear what you mean. Currently, you can't block someone if you're currently subject to a block, at least here at Wikipedia (is it different at Wiktionary?). Are you proposing that blocked admins be given this permission (and if so, why?), or do you mean something else? Nyttend (talk) 02:00, 27 November 2018 (UTC)

  @Nyttend: That is what I'm proposing, yes. In case of a rogue admin, the priority would be to stop damage from being done as soon as possible. If self-unblocking is allowed, blocking can't stop a rogue admin. If self-unblocking is not allowed and blocked admins can't block other admins, the rogue admin could preemptively block the other admins and remain as the only unblocked admin. If self-unblocking is not allowed and blocked admins can block other admins, any admin can block the rogue admin immediately and shut down all further actions other than the possibility of blocking the remaining admins. On further thought, however, I'm not sure that would be an improvement: All admins being temporarily unable to fix things up (like vandalism) until a steward or bureaucrat shows up might actually be worse than the alternatives... I am unsure. --Yair rand (talk) 05:49, 27 November 2018 (UTC)

• Not of fan of anything out there right now, so status quo for me. For example, if you have a self block, I'm fine with a self-unblock. If an account is compromised, or appears to be, then de-sysop until the account is back under control.
  b
  } 20:48, 26 November 2018 (UTC)

• Version A If an administrator gets blocked, it is probably for a good reason. —Eli355 (talk • contribs) 00:53, 27 November 2018 (UTC)

• Per phab:T150826 and Special:ListGroupRights, sysops and bureaucrats no longer have unblockself. ~ Amory (u • t • c) 02:03, 27 November 2018 (UTC)

• At that ticket, Ajraddatz said "self-imposed blocks can always be self-removed". I've just blocked and unblocked myself, so I can confirm that this is still the case. Could someone block me (and then ping me) so we can see whether the new settings are live yet? Please be careful to disable autoblock and enable talk-page access, of course :-) Nyttend (talk) 02:12, 27 November 2018 (UTC)

• Nyttend Done ;) ~ Amory (u • t • c) 02:16, 27 November 2018 (UTC)

• Already did these tests and reported back a few comments up, but that's ok, you guys can test it out again if you want ;-) -- Ajraddatz (talk) 02:24, 27 November 2018 (UTC)

• Ah, sorry, I guess I didn't read as much as I thought I had. The test went as expected; when I tried to unblock myself, I got a new message:

  You are not allowed to unblock yourself.
  
  Return to Main Page.

  Nyttend (talk) 02:27, 27 November 2018 (UTC)
• Considering that the devs have gone and removed the problem for us, should this RfC be closed then? — AfroThundr ^{(u · t · c)} 02:33, 27 November 2018 (UTC)

• I think so. I wish they'd waited for this discussion to close (someone mentioned this discussion, so they were aware of it), but since they didn't, there's no point in continuing. The only possible change would be a consensus to request the return of unblockself, and since they removed it on their own accord, I doubt they'd grant a request to revert themselves. Nyttend (talk) 02:35, 27 November 2018 (UTC)

• I say let the RfC play out. I for one can't fucking believe this was done behind the scenes without community consent. I find it hard to believe that the devs can't see the double-edged blade staring directly back at them us. If the inability to self-unblock can be used as a weapon against these rogue/compromised/abusive accounts, it can be used by these accounts, against us. I really don't think "Robdurbar" would have attacked the main page if he knew it would be over the second he did so. He may have instead strategized the best way to evade a block for as long as possible while inflicting as much damage as possible. This is a big project, with plenty of dark corners. It's really not hard for me to brainstorm creative ways to go rogue without being immediately blocked. I'm sure whoever is behind the compromised admin accounts is not terribly stupid either. There's not that many admins active at any given time. If we're lucky, there will be a crat or steward around to perform an emergency desysop when needed. Some nonsensical IP user can commit blatant anti-Semitic vandalism on an obvious target for that sort of thing, and no one will notice for nearly 48 hours. Or, they can go on an unhinged BLP violating/edit warring spree, while their name sits in a backlogged administrative noticeboard. If IPs can fly under the radar, do you really think that rogue/compromised admins can't get away with it if they really try? We're just giving these people reasons to engage in pre-emptive admin blocking, not to mention stealth sprees, and that can cause far more damage than anyone has ever tried to cause before. Yeah, it sounds like a good idea with no downsides at first, but there's a huge potential for this shit to backfire. Smdh.  Swarm  talk  02:40, 27 November 2018 (UTC)

  Swarm, No point in it now, I guess. FWIW if you're interested in numbers, I've been watching them for a while. On average there are 40-60 admins active on enwiki per hour, and about 500-700 per week. SQL^{Query me!} 02:50, 27 November 2018 (UTC)

  Imagine if you looked at the numbers where you take the body of "active" admins in a given time, weed out the ones who aren't actually working on/involved with the administrative backlog proper, spread them out across every venue where there are outstanding reports or requests for admin action, and then compare the rate of admin work that can be, or is being, completed with that workforce, relative to the rate of new admin work being created. Reports at AIV can sometimes sit for hours. Reports at AN/I, RfPP, PERM, or AN3 can sit for days. There's basically one person who has been handling the histmerge backlog over the years. It doesn't do me much good to know that there's 60 active admins here at any given hour when I'm waiting two or three days for a simple report to get an admin's response. We're not as on top of things as you'd think.  Swarm  talk  03:11, 27 November 2018 (UTC)

  I know we are all very enwiki-centric here but this was also done globally. How about those small projects where there are two or three admins? Block, block, and you have the run of the place until a steward steps in. --Majora (talk) 02:43, 27 November 2018 (UTC)

  For what it's worth, before this change such rogue admin account already had the run of the place until a steward interfere since no blocks can stop them, and their crats don't have the power to desysop. -- KTC (talk) 12:31, 27 November 2018 (UTC)

• Version A – I originally supported maintaining the status quo, but I have been persuaded by two arguments. Firstly, per this 2011 change found by John Cline and confirmed by Ajraddatz above, removing (unblockself) from the administrator toolset will not prevent administrators from unblocking themselves if they were also the one who blocked themselves. Most self-unblocking events on Wikipedia are administrators accidentally blocking themselves, and this proposal, as written, will not hinder administrators' ability to correct such uncontroversial errors. Secondly, per Callanecc above, this proposal would be useful in the event that an administrator account is compromised, which does occur every few years. Currently, the only effective way to stop a compromised administrator account is for a bureaucrat or steward to do an emergency desysop/global lock. The wait time for this can take several minutes, whereas this proposal would shorten the response time by allowing any administrator—not just stewards and bureaucrats—to neutralize the compromised account via a block. As MusikAnimal notes: in such a case, every second counts. Mz7 (talk) 03:12, 27 November 2018 (UTC)
  • Here's why I didn't support this option: what if someone did succeed in running a script to block all (active) admins? We have to weigh the time we save with option A and compare it against the probability of someone succeeding in doing this and the length of time it would take for intervention in that scenario. --Rschen7754 03:55, 27 November 2018 (UTC)

• Version C I basically agree with the latter half of User:Mz7's stricken post (the bit about whether someone who can't be trusted not to self-unblock can be trusted to be an admin, which is basically unrelated to whether self-blocks would be included, although I do applaud the detective work that was apparently involved there), with the addition that it seems to be in only extreme cases where admins get blocked at all (I've seen admins do/say things that would get any experienced non-admin blocked on-site, but with admins a more popular approach seems to be to ask ArbCom to desysop, as though it was taken as a given that if someone does something blockworthy their mop should be taken away first), and admins having the ability to self-unblock would seem to be useful to weed out the really extreme cases. I should also say that one way or the other this question would be better resolved after Wikipedia:Arbitration/Requests/Case/Fred Bauder is resolved, since desysopping someone for abusing an admin tool that has already been removed from all admins is ... well, it serves a function, but still feels kinda silly. Hijiri 88 (聖やや) 07:42, 27 November 2018 (UTC)
• Version D User:Jesse_Viviano's proposal that an admin can sacrifice their bit to desysop another admin.--v/r - TP 16:43, 27 November 2018 (UTC)
• status quo, too rare of a problem to need a special solution. Andrew Lenahan - Starblind 18:03, 27 November 2018 (UTC)