Fwiw: on the subject of unblockself rights - even if all admins have that the attacker could still just immediatly (via an automated script) reblock anyone who unblocks themselves as soon as they do so, before they can block attacker. Sure eventually a defender could write a script to win the race condition, but it would probably take longer to do that then just fetch a steward. So i dont think removing unblockself significantly increases the risk of an attacker blocking all other admins.

On the subject of rate limits: i guess it could make sense if they only applied when blocking a user with the ability to block other accounts. I still think the block user who blocked you is a better mitigation

Counter-blocks are a good mitigation for small projects, where the concern is that the attacker would quickly block all other privileged users and have free reign until the stewards arrive (which could take a while if there are language and knowledge barriers). The mitigation can be defeated if the attacker can compromise two different admin accounts, and use only one of them for the blocks, but I don't think we can do much about that. (Two compromised admin accounts are a problem in general as they can unblock each other. Kind of like IRC op wars in old times, automation gives you a big edge.)

A rate limit on blocking privileged users on the other hand is a good mitigation for large projects where the concern is that the attacker blocks all the dozens or hundreds of admin accounts very rapidly, taking advantage of human reaction times being much slower than API speeds. A rate limit with a large time window (a hourly or daily limit) would work well against that without getting in the way of normal usage, IMO. How often do you need to block more than 10 admins a day? Maybe when an attacker compromises a bureaucrat and spawns malicious admin accounts but at that point you probably have bigger problems.

So I think the two are somewhat complimentary.

In T150826#4779676, @Tgr wrote:

The mitigation can be defeated if the attacker can compromise two different admin accounts, and use only one of them for the blocks, but I don't think we can do much about that.

That is unlikely. But possibly more likely is a scenario in which one gains access to a bureaucrat account, blocks every other privileged account, and promotes another user account he owns to sysop, before any of the other privileged accounts can react. This way, even if they block the compromised bureaucrat account, there still exists a newly created sysop account that no other user can block.

As an alternative strategy: can we allow Oversighters and CheckUsers to have unblock self? Or perhaps, only those of them who have 2FA enabled? This would be a very limited group of highly trusted individuals who are using a higher standard of security. Mid-sized projects usually have one or the other (i.e. CU or oversight) and this can help in the unlikely scenario of a compromised sysop.

In T150826#4779881, @Huji wrote:

In T150826#4779676, @Tgr wrote:

Or perhaps, only those of them who have 2FA enabled?

Unfortunately, this could be pretty easily bypassed.

yeah if an attacker gains control over an account without 2FA, but finds themselves restricted by not having 2FA on the account, they could just enable it :/

What do we want going out in Tech News on Monday?

• Self-unblock will only be possible if one is self-blocked. If this is a problem for your wiki, report it here or [on-wiki way to tell this].

Anything else that's decided or we want to ask the communities if they have input on? Being able to block the admin who blocked you feels like it's a bit too much in the discussion phase to put in the newsletter?

Moreover, it just adds unnecessary complexity. I could understand allowing it in phases for advanced perm holders as 2FA is required for each in turn, but that still seems needlessly complex. Tgr's one-two punch would help with most situations, and at the least wouldn't make anything worse in the compromised 'crat scenario.

In T150826#4779917, @Krenair wrote:

yeah if an attacker gains control over an account without 2FA, but finds themselves restricted by not having 2FA on the account, they could just enable it :/

You could make it harder to enable 2FA (email verification for example) or make them wait a day or two before the additional restrictions are lifted. (Speaking of which, maybe this scenario should be considered. If someone hacks an admin account and enables 2FA, it would make it a lot harder for the original owner to regain access).

In T150826#4779945, @Rschen7754 wrote:

In T150826#4779917, @Krenair wrote:

yeah if an attacker gains control over an account without 2FA, but finds themselves restricted by not having 2FA on the account, they could just enable it :/

You could make it harder to enable 2FA (email verification for example) or make them wait a day or two before the additional restrictions are lifted.

I don't think we want to start putting up barriers to enable 2FA (beyond the current thing over which users are allowed to use it). I think it's best to just avoid handing out most serious permissions in the first place to users who don't already have 2FA enabled, and take any away if they do disable it.

In T150826#4779945, @Rschen7754 wrote:

If someone hacks an admin account and enables 2FA, it would make it a lot harder for the original owner to regain access

Right now I think all you'd need to do is change the email address and password. 2FA would be an extra problem but easily resolved by whoever comes along to fix the account's other details.

Regarding auto-removal, note that the current way for generating new backup
codes is disabling 2FA and enabling it again ^^

In T150826#4778848, @Adotchar wrote:

In T150826#4778796, @Bawolff wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

Please, please, please do not do this globally without a meta RfC or some form of other discussion. (and should require every wiki’s community to be notified, or for it to be handled on a wiki-by-wiki basis)

I am strongly opposed to this, and I’m sure many others are as well who are not watching this ticket.

What is the downside? Why would any admin need to block more than let's say 5-10 admins in one single sitting.

In T150826#4784223, @Ankit-Maity wrote:

What is the downside? Why would any admin need to block more than let's say 5-10 admins in one single sitting.

The ratelimit applies to accounts, not just to admins. And there are definitely times when admins need to block more than 5-10 users in one go, especially on large wikis.

In T150826#4784325, @jrbs wrote:

In T150826#4784223, @Ankit-Maity wrote:

What is the downside? Why would any admin need to block more than let's say 5-10 admins in one single sitting.

The ratelimit applies to accounts, not just to admins. And there are definitely times when admins need to block more than 5-10 users in one go, especially on large wikis.

@Ankit-Maity is referring to blocking 5-10 admins not ordinary users.

In T150826#4784325, @jrbs wrote:

The ratelimit applies to accounts, not just to admins. And there are definitely times when admins need to block more than 5-10 users in one go, especially on large wikis.

No, what @Tgr suggested is a ratelimit for blocking privileged accounts. See bellow:

In T150826#4779676, @Tgr wrote:

A rate limit on blocking privileged users on the other hand is a good mitigation for large projects where the concern is that the attacker blocks all the dozens or hundreds of admin accounts very rapidly, taking advantage of human reaction times being much slower than API speeds.

In T150826#4784388, @Ammarpad wrote:

@Ankit-Maity is referring to blocking 5-10 admins not ordinary users.

In T150826#4784390, @Agabi10 wrote:

No, what @Tgr suggested is a ratelimit for blocking privileged accounts. See bellow:

In T150826#4779676, @Tgr wrote:

A rate limit on blocking privileged users on the other hand is a good mitigation for large projects where the concern is that the attacker blocks all the dozens or hundreds of admin accounts very rapidly, taking advantage of human reaction times being much slower than API speeds.

Ah, mea culpa. Didn't realise that was possible!

Some itwiki admins pointed out that removing the unblockself right makes it impossible for sysop to undo an Abusefilter block on themselves. Although this shouldn't happen at all, and the AbuseFilter could be used as well by a compromised account to block users, would it be possible to allow unblocking self if the block originates from a system user?

In T150826#4779940, @Johan wrote:

What do we want going out in Tech News on Monday?

• Self-unblock will only be possible if one is self-blocked. If this is a problem for your wiki, report it here or [on-wiki way to tell this].

Or...

• Administrators are no longer able to unblock themselves except in cases of self-blocks (task number).

Anything else that's decided or we want to ask the communities if they have input on? Being able to block the admin who blocked you feels like it's a bit too much in the discussion phase to put in the newsletter?

I'm not sure where to direct people to ask questions. Maybe [[m:Tech]]?

Change 476492 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/core@master] Allow unblocking if the blocker is a system user

https://gerrit.wikimedia.org/r/476492

In T150826#4784526, @Daimona wrote:

Some itwiki admins pointed out that removing the unblockself right makes it impossible for sysop to undo an Abusefilter block on themselves. Although this shouldn't happen at all, and the AbuseFilter could be used as well by a compromised account to block users, would it be possible to allow unblocking self if the block originates from a system user?

^ I guess the patch above will need some discussion, but there it is.

In T150826#4784526, @Daimona wrote:

Although this shouldn't happen at all, and the AbuseFilter could be used as well by a compromised account to block users, would it be possible to allow unblocking self if the block originates from a system user?

Any mass block that's initiated by the system administrators will probably use a system user, so I don't think that's a good idea. This does not seem like much of a practical problem (adding a "not admin" check to filters in trivial, I imagine you'd actually want to exclude a much wider group in most cases, and using AbuseFilter as an attack is not terribly effective as it only triggers on edits and similar actions, and not on unblock IIRC), but if we really want to prevent it, maybe add an afblock-exempt user right along the lines of ipblock-exempt?

@Tgr Hmm, didn't think about that. However, one may forget to add a "not admin" check, or a compromised admin may deliberately create a catch-all filter to block anyone (not really effective, right, but yet it's a possibility). An alternative could be to create a config var to specify a list of blockers whose blocks on yourself you can remove. But actually, while writing, I realised that people holding the "abusefilter-revert" right can undo AbuseFilter actions even if they're blocked. If that's fine, we could just keep the status quo.

(I'm side-stepping whether this change should have been made at all or in this fashion to answer this specific question.)

In T150826#4784812, @MarcoAurelio wrote:

I'm not sure where to direct people to ask questions. Maybe [[m:Tech]]?

Unless there's a dedicated page for this change like [[m:Removing the unblockself user right]] page, using [[m:Tech]] seems reasonable to me. The [[m:Tech]] forum is intended to complement the [[m:Tech/News]] subpage. :-)

In T150826#4784223, @Ankit-Maity wrote:

In T150826#4778848, @Adotchar wrote:

In T150826#4778796, @Bawolff wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

Please, please, please do not do this globally without a meta RfC or some form of other discussion. (and should require every wiki’s community to be notified, or for it to be handled on a wiki-by-wiki basis)

I am strongly opposed to this, and I’m sure many others are as well who are not watching this ticket.

What is the downside? Why would any admin need to block more than let's say 5-10 admins in one single sitting.

I'm REALLY reaching at this point, but possibly a compromised crat? IDK, I think at that point, it's out of the hands of the local wiki's admins - and more into the hands of the devs and/or stewards.

Well intended but bad idea. This will give an option not only to a comprised admin account but also to a rogue admin in a small community to block the other one or two admins in a coup (an usually in such small communities it may pass unnoticed).
A better approach would be to be able to unblock itself but in exchange to not being able to use admin tools for n time. This would give time to users/admins to report and solve the situation together with stewards.

@geraki Hi, thank you very much for the comment.

What would be the benefit of the "good" administrators being able to unblock themselves? You may hope for them to be able to stop the attacker, by blocking the compromised administrator account? The attacker can just unblock himself whenever someone attempts to stop him this way. This changes nothing.

On the other hand, if nobody can unblock himself, then a single "good" administrator can fix the problem, permanently, by blocking the compromised account.

In T150826#4791449, @geraki wrote:

Well intended but bad idea. This will give an option not only to a comprised admin account but also to a rogue admin in a small community to block the other one or two admins in a coup (an usually in such small communities it may pass unnoticed).
A better approach would be to be able to unblock itself but in exchange to not being able to use admin tools for n time. This would give time to users/admins to report and solve the situation together with stewards.

The substance of your concern has been resolved in a neater fashion already. If a rogue admin A blocks the only other admin B in a "coup" as you said, it's been made possible for blocked Admin B to also block Admin A who blocked them. Then there's stalemate. Everyone is blocked. A steward is needed.

In T150826#4792060, @Ammarpad wrote:

In T150826#4791449, @geraki wrote:

Well intended but bad idea. This will give an option not only to a comprised admin account but also to a rogue admin in a small community to block the other one or two admins in a coup (an usually in such small communities it may pass unnoticed).
A better approach would be to be able to unblock itself but in exchange to not being able to use admin tools for n time. This would give time to users/admins to report and solve the situation together with stewards.

The substance of your concern has been resolved in neater fashion already. If a rogue admin A blocks the only other admin B in a "coup" as you said, it's been made possible for blocked Admin B to also block Admin A who blocked them. Then there's stalemate. Everyone is blocked. A steward is needed.

Exactly so. The blocking admin knows the consequences of a privileged block and has to do his due diligence than mere suspicion. In the case of small wikis, the blocked admins are able to block the ones who blocked them, making any hostile takeover a remote possibility, leaving the only factor to be human response times, which is always variable as-is. The obvious downside is tit-for-tat revenge blocks but any admin remotely considering to preserve their adminship will have to conduct their due diligence before doing so, some more overworked stewards for wikis basically.

I am providing this comment as a summary of what is on this task and English Wikipedia's VP discussion for people new to this situation. If you're up-to-speed on this topic you can ignore this comment.

Overview

Important note: these notes reflect discussions on Phabricator and English Wikipedia. I can supplement later, as needed.

In Nov. ’16 this Phabricator task was opened proposing to remove the unblockself permission on all Wikimedia wikis. In November ’18 some administrator accounts were compromised and the vandal was able to unblock themselves and continue harming the projects.

The proposal to remove the unblockself permission was raised on an English Wikipedia Village Pump thread on November 23. On November 25 this Phab ticket was pinged. On November 26 a patch to remove the permission was uploaded and merged. Discussions continued after this about additional changes.

Concerns about removing the ability to unblockself

• If one admin blocks all other admin accounts, they essentially have total control over the wiki until a bcrat/steward/WMF staff is informed and arrives. This is possible on small wikis manually and large wikis with a simple bot.
• There are some situations where an admin may block themselves (testing, wikibreak, etc.) There is an exception in the code to allow an admin to unblock their self-block.

Potential further changes
The following ideas have been proposed as supplemental security checks or alternatives to removing unblockself entirely. Most of these have some support with no explicit detractors:

• Give some users unblockself — bcrats, stewards, checkusers, etc.
• Rate limiting of blocking permissioned users. In other words, an admin would only be able to block N admins per minute/hour/day but would have no limit for blocking IPs and non-admin users.
• Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage and the situation will mostly be at a standstill until stewards come and clean things up. There is an unmerged patch.
• Restore the ability for all admins to unblockself, as concern noted above could do more harm than good in a short term.

It is important to note that all of these solutions (including removing the ability to unblockself) are moot if the attacker has compromised 2+ admin accounts or a steward/bcrat account.

Notable abandoned ideas

• AbuseFilter blocks should be self-unblockable.
• Allow users with 2FA to self-unblock.
• Require a cooldown period (e.g. 10 minutes) between the block and a self unblock.
• “sysop sacrifice” — a tool that would allow an admin to remove the sysop permissions of another admin at the cost of losing their own sysop permissions.

Important notes about process

• It was questioned if removing this permission should be global or local.
  • It was decided to implement across all wikis because compromised accounts can happen on any wiki. Smaller wikis are more vulnerable to a quick takeover, therefore additional or alternative solutions would also be needed.
  • Regardless of final software changes, communication should occur to all Village Pumps.
  • If this discussion is to continue, there should be a meta RfC and the data should be provided about blocks, self-blocks, and self-unblocks.
• There was concern that WMF developers implemented a solution before an active RfC was closed.

I tell you what I find truly infuriating about this implementation

1. A solution to a problem at enWP became everyone's solution whether they had the problem or not;
2. There is nothing new about the problem, it has been known like "forever", however due to the problem at enWP, everyone got the solution and got it immediately;
3. Because the solution fits for enWP, and their circumstance, it was imposed upon everyone without consideration whether it was the right solution for those wikis, but don't worry about it, we will fix that later.
4. At small wikis the solution for enWP becomes the weakness for those wikis with smaller numbers of admins.
5. The existing process that should have occurred was the removal of the rights by local crats or stewards. That is the purpose of the process, not the block/unblock conundrum, who pulls the gun first, etc. Emergency rights removal takes about the same amount of time, and allows the security aspects to be addressed, and still allows a follow-up block action if it moves from administrative to editing.

This is another of a string of WMF-imposed decisions that have not followed the traditional consensus approach; and it is again the imposition/removal of conditions on all the wikis due to problems at enWP. Changing culture!

The security issues of weak passwords has been around forever, and purposefully not actioned. I know had the conversation with security ppl at SF office years ago.

Emended possibly reference to admins "locking themselves out". Locks are imposed by stewards and are global, blocks by admins are local to the wiki. Presuming that the ability for stewards to LOCK themselves is still present.

In T150826#4808282, @Billinghurst wrote:

I tell you what I find truly infuriating about this implementation

1. A solution to a problem at enWP became everyone's solution whether they had the problem or not;
2. There is nothing new about the problem, it has been known like "forever", however due to the problem at enWP, everyone got the solution and got it immediately;
3. Because the solution fits for enWP, and their circumstance, it was imposed upon everyone without consideration whether it was the right solution for those wikis, but don't worry about it, we will fix that later.
4. At small wikis the solution for enWP becomes the weakness for those wikis with smaller numbers of admins.
5. The existing process that should have occurred was the removal of the rights by local crats or stewards. That is the purpose of the process, not the block/unblock conundrum, who pulls the gun first, etc. Emergency rights removal takes about the same amount of time, and allows the security aspects to be addressed, and still allows a follow-up block action if it moves from administrative to editing.

This is another of a string of WMF-imposed decisions that have not followed the traditional consensus approach; and it is again the imposition/removal of conditions on all the wikis due to problems at enWP. Changing culture!

The security issues of weak passwords has been around forever, and purposefully not actioned. I know had the conversation with security ppl at SF office years ago.

The obvious solution has been implemented and rightly so. The chances small wikis will get affected is also lesser, just statistically. Plus it's a catch-all blanket measure. When there's a fire, you use a fire extinguisher and more often than not, the one at hand will be the correct one for the type of fire. Now that something is in place, consensus can form to determine what the wikis want, long story short.

@Billinghurst , one comment above yours: "Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage and the situation will mostly be at a standstill until stewards come and clean things up."

Isn't that a good solution especially for small wikis? Where is the problem?

In T150826#4808282, @Billinghurst wrote:

1. A solution to a problem at enWP became everyone's solution whether they had the problem or not;

In no way is an attacker self-unblocking less of a problem on a smaller wiki. High-profile vandalism might be less of a problem (or a less urgent one) but that's not the worst thing an attacker can do by far.

This is another of a string of WMF-imposed decisions that have not followed the traditional consensus approach

There is in fact no "traditional consensus approach". Wikipedia:Consensus#Decisions not subject to consensus of editors explicitly says In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers ... are largely separate entities. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features ... even if their actions are not endorsed by editors here. Which is really the only way software development could work, it is not reasonable to expect developers to go out and establish the consensus of the editor community before every patch. It is usually reasonable for patches which have a major impact on editor workflows, which has not been demonstrated here.

The security issues of weak passwords has been around forever, and purposefully not actioned. I know had the conversation with security ppl at SF office years ago.

Alternatively, you might misremember a conversation that happened long ago, or maybe you talked to people who are not the security people now. Or you misunderstood the "purposefully" part - there are lots of security features that could be improved, and the Security team has to pick which ones are the best use of their limited capacity, and weak passwords might be picked now because they are a more important problem now that they are actually being abused, or simple because higher-priority tasks have been finished.

Change 476080 merged by jenkins-bot:
[mediawiki/core@master] Allow users to block the user that blocked them.

https://gerrit.wikimedia.org/r/476080

@Risker I had some time to look into self-unblock patterns. Interestingly they used to be pretty common on enwiki but not anymore: P7899#46610

(Note this numbers are a bit higher than the ones in @Anomie's query (about 3x, for 2017-18). Most of the discrepancy seems to be due to repeared rows in the Hive data, so the actual numbers might be 2-3x lower but it still gives an idea of the magintudes. (Due to T211535: Comments missing in mediawiki_history table it's hard to get useful individual-block-level data out of Hive so I couldn't debug the problem more.))

Self-unblocks on all wikis in a given year: P7901#46605 - so <10 for almost all wikis, a some have between 10-20 in some years. All in all I'd say no cause for concern.

(There is no precise way to check if a block is a self-block in the data lake; unblocks performed while being blocked seemed like a decent proxy but the numbers were unrealistically low (P7900#46590) so there must be some problem with the Hive data, possible the blocked flag of the user is already changed by the time it picks up the event. But given the low number of total self-blocks does not seem worth the effort to separate them.)

Change 478581 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Rate limit blocks of admins

https://gerrit.wikimedia.org/r/478581

In T150826#4808282, @Billinghurst wrote:

I tell you what I find truly infuriating about this implementation

1. A solution to a problem at enWP became everyone's solution whether they had the problem or not;
2. There is nothing new about the problem, it has been known like "forever", however due to the problem at enWP, everyone got the solution and got it immediately;
3. Because the solution fits for enWP, and their circumstance, it was imposed upon everyone without consideration whether it was the right solution for those wikis, but don't worry about it, we will fix that later.

I just want to be clear, I took this action because I thought it was a poor default for all wikis, including small wikis, and its my belief that the only reason everyone is using this setting is because its what happens to be the default. I was not targeting enwiki specifically, other then some recent incidents at enwiki are what brought the matter to its current attention.

4. At small wikis the solution for enWP becomes the weakness for those wikis with smaller numbers of admins.

For very small wikis, it probably doesn't matter one way or another, as its unlikely for there to be more than one admin active at the same time window. Even wikis as large as meta (which is much more high profile then your average wiki of its size), vandal attacks can go on for something like 20 minutes before anyone notices - this is well past the point where seconds count. I strongly suspect that in the case of a compromised admin account on a small wiki, that Small Wiki Monitoring Team would notice the issue before another local admin notices the issue and gets into some sort of block war with the compromised account over it - and they should definitely know how to quickly escalate to stewards who could remove rights.

5. The existing process that should have occurred was the removal of the rights by local crats or stewards. That is the purpose of the process, not the block/unblock conundrum, who pulls the gun first, etc. Emergency rights removal takes about the same amount of time, and allows the security aspects to be addressed, and still allows a follow-up block action if it moves from administrative to editing.

This is another of a string of WMF-imposed decisions that have not followed the traditional consensus approach; and it is again the imposition/removal of conditions on all the wikis due to problems at enWP. Changing culture!

With all due respect, I don't think there is any historical tradition of seeking global consensus for changes to global defaults on Wikimedia as a whole. There is certainly a tradition of seeking consensus for changes that affect specific wikis. Sometimes there is informal discussion on changes. Especially those that are identified as likely to be controversial. When I look through the list of RFCs on meta, there are handful of technical ones (The one's I was able to find are: Switch_default_category_collation_to_UCA_collation_with_numeric_sorting, Superprotection, Set_SourceEditor_as_a_default_Editor_on_small_wiki, Petition_of_HTTPS_default, Password_policy_for_users_with_certain_advanced_permissions, OAuth_app_guidelines, OAuth_handover, Global_AbuseFilter, Flagged_revisions_deployment, Enable_two-factor_verification_for_all_users and Disable_local_uploads_on_smaller_wikis). This is not what a tradition of requiring consensus over changes to defaults looks like.

@Johan — Please note the new patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/476080/ appears to be scheduled for release this week.

It allows blocked admins to block the user who blocked them (but not others). That removes first-mover advantage and the situation will mostly be at a standstill until stewards come and clean things up.

For example, if User:AdminAlpha blocks User:AdminBeta, User:AdminBeta could block User:AdminAlpha but not User:AdminGamma or User:NonPermissionedUserDelta, etc.

There's a parallel discussion about this on the Wikitech-Ambassadors mailing list, where an interesting idea was raised:

How about we only remove "unblockself" from "large" wikis, where we define "large" as "having more than N admins and bureaucrats"? (N=3 and N=5 have been suggested)

This will solve the problem at hand while avoiding addressing the concerns raised on behalf of small wikis above.

@deryckchan — Thank you for bringing the discussion from the mailing list to this ticket. In earlier comments it's been discussed how the problem of a compromised admin account may actually be more of a problem on small wikis. Restoring 'unblockself' would benefit the abuser as much as the uncompromised admins attempted to restore order.

I think this new status quo — unblockself has been removed and blocked admins can block the admin who blocked them — addresses most of the problems of compromised admin accounts.

@TBolliger Please could you (or someone who knows the latest details) update the task description above, to contain an uptodate description of the change(s) that will be implemented? (The Tech/News item points here for more info, but this thread is long). Thanks!

The other problem (if that's a problem) is that there is no way to check the number of admins in the configuration. We could make a list of wikis which have more than N admins right now and use that, but it would either require constant maintenance effort or soon it would not have anything to do anymore with number of admins in the present.

Anyway I don't think anyone has point out a tangible problem with the current setup so far.

In T150826#4824454, @Quiddity wrote:

@TBolliger Please could you (or someone who knows the latest details) update the task description above, to contain an uptodate description of the change(s) that will be implemented? (The Tech/News item points here for more info, but this thread is long). Thanks!

Done. We may also want to consider marking this task as resolved, depending on what we want to do with the rate limiting patch: https://gerrit.wikimedia.org/r/478581

Oops, edit conflict.

@Tgr: Can you please confirm what the latest state of affairs is? Has
unblock-self been removed from all WMF wikis? Are blocked sysops allowed to
block the sysop who blocked them, as of now?

In T150826#4831651, @deryckchan wrote:

@Tgr: Can you please confirm what the latest state of affairs is? Has unblock-self been removed from all WMF wikis? Are blocked sysops allowed to block the sysop who blocked them, as of now?

Yeah, the task description should be accurate. There's a rate limiting patch open, all else has been deployed to production.

Change 476492 abandoned by Daimona Eaytoy:
Allow unblocking if the blocker is a system user

Reason:
Per above.

https://gerrit.wikimedia.org/r/476492