Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker)
Open, LowPublic

Description

Original report

Point of right is to stop newbie third parties from blocking themselves. Wikimedia has all sorts of help to deal with that situation, so we should not give anyone unblockself. Or at least limit it to say stewards/crats so they can deal with the case of a compromised account that blocks everyone, but we still stop average admins from unblocking themselves.


Summary of this ticket and changes that have been made

In Nov. 2016 this Phabricator task was opened proposing to remove the unblockself permission on all Wikimedia wikis. In November 2018 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 for all Wikimedia wikis.
  • It was also suggested to 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 a patch was merged on December 9.
  • There is still an unmerged patch to rate limit how fast an admin can block other admin accounts.
  • Self-blocks (e.g. User:AdminApples blocks User:AdminApples) have always been able to (and will continue to be able to) unblock themselves.

See also summary of comments from Nov 15 2016 to Dec 4 2018: T150826#4798765

There are a very large number of changes, so older changes are hidden. Show Older Changes
Tgr added a comment.Tue, Nov 27, 6:39 AM

Apparently we don't record which block the unblock is undoing, d'oh. (Filed T210476.) In theory that's surmountable by taking the last block that's older than the unblock but my SQL fu is not good enough to convince MariaDB to use a decent plan (attempts: 31588, 31589).

KTC added a subscriber: KTC.Tue, Nov 27, 12:39 PM
 In T150826#4775305, @Tgr wrote:

[...]

    Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage on small wikis - in case of >serious trouble the admins will lock each other out and things will mostly be at a standstill until stewards come and clean things up.

I like this idea.

I believe this should be handled by a meta RfC rather than discussion at the enwiki Village Pump and a Phab ticket. (Unless, of course, the WMF wants to act on it immediately as a security issue)

Why was this done globally instead of just to enwiki as requested? No other project requested this as far as I'm aware. To remove unblockself from all wikis, especially smaller ones where there are only one or two admins, raises a bunch of problems. It would be better if the devs only did this on the projects that requested it instead of extending the massive paranoia to every single project.

I consider the 'unblockself' thing to be a poor default in the Wikimedia. I think the only reason we have this is it was set to the default way back. I think communities that want it could opt back in, but I don't think we should continue to have this solely because it was a default from forever ago

4nn1l2 added a subscriber: 4nn1l2.Tue, Nov 27, 4:30 PM
Stryn added a subscriber: Stryn.Tue, Nov 27, 6:15 PM

Change 476080 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] Allow users to block the user that blocked them.

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

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.

Adotchar added a comment.EditedTue, Nov 27, 7:17 PM

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.

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.

Not planning to implement that at this time (unless people start explicitly asking for it), just recording it as an idea.

I think the problem is, in order not to be annoying it would have to be a high limit (imo, I think the lowest that would be reasonable would be 30 blocks / minute) And then it becomes not that useful in the attack scenario.

My general plan for alleviating the threat of someone blocking all admins is tgr's idea about being able to block the person who blocked you.

Up next might be compromising a steward and global lock everyone else out before losing permissions, but if you can't log in, have fun identifying yourself to operations to restore access, and deal with the attacker. Securing permissions with e.g. OATHAuth is a problem if the authenticator key gets compromised too, though that's less likely, therefore its favored that sysops be required to use OATH, IMHO

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.

Not planning to implement that at this time (unless people start explicitly asking for it), just recording it as an idea.

I think the problem is, in order not to be annoying it would have to be a high limit (imo, I think the lowest that would be reasonable would be 30 blocks / minute) And then it becomes not that useful in the attack scenario.

My general plan for alleviating the threat of someone blocking all admins is tgr's idea about being able to block the person who blocked you.

Let's not complicate this situation further by giving admins the ability to block the people who blocked them - in fact, that's exactly the scenario that all of this is trying to prevent. In the three cases on enwiki that immediately come to mind, the blocked admin blocked the administrators who blocked them. Status quo ante, they had to unblock themselves first to do that. This wouldn't even require them unblocking themselves. Please don't go there.

Several projects have fully authorized adminbots that block from specified lists at a rate of higher than 30 blocks/min. A couple of years back when we blocked the Orangemoody socks with an adminbot that was described as "slow", it was running at better than 30 blocks/min. So while I like the principle, I don't see it as really practical, particularly on large wikis that block as many users in an hour as smaller wikis have editing in a week.

jrbs added a comment.Tue, Nov 27, 9:03 PM

Let's not complicate this situation further by giving admins the ability to block the people who blocked them - in fact, that's exactly the scenario that all of this is trying to prevent. In the three cases on enwiki that immediately come to mind, the blocked admin blocked the administrators who blocked them. Status quo ante, they had to unblock themselves first to do that. This wouldn't even require them unblocking themselves. Please don't go there.

I think the situation being described here is:

  • Admin Foo is compromised by some attacker
  • Admin Foo begins blocking people, including Bar
  • Bar notices this, and blocks Foo, preventing him from continuing to block random users and therefore stopping the immediate threat

So I mean, I'm not sure that's a terrible outcome, at least in the short term - unless I'm missing something. It provides at a counter to that first-block advantage that currently exists, and in presumably all cases, blocking the guy who blocked you without cause would be pretty much immediate desysopping from a Steward/'crat.

I would have to agree that the ability to block the person who blocked you would mitigate the problems with small wikis that have very few admins that the removal of this permission presents. At least with that there is the ability to stop the damage being done if the entire admin staff is blocked by a compromised account. Non-compromised accounts can be easily unblocked and the vandalism would be stopped. As for rate limits I really don't think that is a good idea. The limit would need to be set so high as to be rather useless as to not interfere with the normal administrative duties that occur.

Let's not complicate this situation further by giving admins the ability to block the people who blocked them - in fact, that's exactly the scenario that all of this is trying to prevent. In the three cases on enwiki that immediately come to mind, the blocked admin blocked the administrators who blocked them. Status quo ante, they had to unblock themselves first to do that. This wouldn't even require them unblocking themselves. Please don't go there.

This would only allow them blocking the admin who blocked them, but not all the other admins too. It's way better than the existing status quo where they can't be blocked due to their ability to unlock themselves, and it's also better than the situation where they can block all other admins and continue vandalizing whatever they want until the account is blocked in a way they can't unlock themselves.

Several projects have fully authorized adminbots that block from specified lists at a rate of higher than 30 blocks/min. A couple of years back when we blocked the Orangemoody socks with an adminbot that was described as "slow", it was running at better than 30 blocks/min. So while I like the principle, I don't see it as really practical, particularly on large wikis that block as many users in an hour as smaller wikis have editing in a week.

That could be easily fixed adding a permission to ignore the block rate and giving that permission to fully authorized admin bots. It would decrease the attack vector preventing attackers from using bots to block admins with a normal admin account while allowing adminbot accounts running full speed. It's not perfect, but at least the risk is lower.

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

Tgr added a comment.Tue, Nov 27, 11:25 PM

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.

Huji added a subscriber: Huji.EditedWed, Nov 28, 1:35 AM

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.

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 :/

Johan added a subscriber: Johan.Wed, Nov 28, 2:26 AM

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.

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).

Krenair added a comment.EditedWed, Nov 28, 2:34 AM

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.

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 ^^

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.

jrbs added a comment.Thu, Nov 29, 8:28 AM

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.

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.

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:

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.

jrbs added a comment.EditedThu, Nov 29, 9:06 AM

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

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

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?

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

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.

Tgr added a comment.Thu, Nov 29, 4:59 PM

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.)

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. :-)

SQL added a comment.Fri, Nov 30, 5:53 AM

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.

Lofhi added a subscriber: Lofhi.Fri, Nov 30, 3:50 PM
geraki added a subscriber: geraki.Sat, Dec 1, 6:32 PM

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.

ToBeFree added a comment.EditedSat, Dec 1, 6:54 PM

@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.

Ammarpad added a comment.EditedSun, Dec 2, 1:59 PM

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.

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.

TBolliger added a comment.EditedTue, Dec 4, 9:06 PM

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.
Mvolz added a subscriber: Mvolz.Sat, Dec 8, 12:56 PM

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.

Billinghurst updated the task description. (Show Details)Sun, Dec 9, 10:47 AM

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.

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?

Tgr added a comment.Sun, Dec 9, 7:15 PM
  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

Tgr added a subscriber: Anomie.Mon, Dec 10, 3:23 AM

@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.)

demon removed a subscriber: demon.Mon, Dec 10, 4:02 AM

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

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.

  1. 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.

  1. 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!

Tgr added a comment.Fri, Dec 14, 6:38 PM

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.

TBolliger renamed this task from Remove unblockself right on wikimedia wikis to Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).Fri, Dec 14, 6:43 PM
TBolliger updated the task description. (Show Details)
Tgr renamed this task from Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker) to Remove unblockself right on wikimedia wikis.Fri, Dec 14, 6:44 PM
Tgr updated the task description. (Show Details)

@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

Tgr added a comment.Fri, Dec 14, 6:44 PM

Oops, edit conflict.

Tgr renamed this task from Remove unblockself right on wikimedia wikis to Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).Fri, Dec 14, 6:45 PM
Tgr updated the task description. (Show Details)