Page MenuHomePhabricator

Allow blocking of global accounts
Open, MediumPublic

Assigned To
Authored By
Pathoschild
Aug 24 2008, 9:45 PM
Referenced Files
F37754144: 图片.png
Sep 23 2023, 2:48 PM
F5201: caldiff
Nov 21 2014, 10:21 PM
Tokens
"Burninate" token, awarded by Sj."Hungry Hippo" token, awarded by laodongvieclam."Like" token, awarded by ToBeFree."Love" token, awarded by Honischboy."Like" token, awarded by Vituzzu."Like" token, awarded by Liuxinyu970226."Like" token, awarded by EddieGP."Doubloon" token, awarded by Nemo_bis."Like" token, awarded by TerraCodes."Like" token, awarded by Luke081515.

Description

Global accounts currently cannot be blocked, so that stewards must lock users out of their accounts to stop them. This leads to a range of challenges:

  1. Locks are opaque and confusing: they did not initially give an error message -- from the user's perspective, their session simply disappears and their password no longer works. This makes locks impossible to appeal or understand for users, which exacerbates the situation of false-positives.
    • It would be beneficial to let stewards block accounts, with an appropriate you've-been-blocked message when they try to edit or create/unify local accounts. [NB: this may be improving as of 2023]
  2. A global block can be locally disabled if needed, or time-limited (we can workaround it with something like this, but this is currently not used in practice).
    • Here is a case that could use a short-time global block (instead of a global lock).
  3. Global locks were designed for troublemakers that aren't usually worth a second chance, such as spammers, LTA sockpuppets, globally banned users and the like. However, they are also the only global recourse for less severe cases like blocking non-VOA users ( example ), so appeals may be expected.
    • Having a Meta user talk page open allows blocks to be discussed on Meta; not possible for locked users

Related Objects

StatusSubtypeAssignedTask
In ProgressNiharika
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenSkizzerz
OpenDreamy_Jazz
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedDreamy_Jazz
OpenNone
OpenDreamy_Jazz
OpenDreamy_Jazz
OpenNone
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
Resolved Marostegui
Resolved Marostegui
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
OpenTchanders
OpenDreamy_Jazz

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Bugreporter I updated the description with your examples, thanks for the added clarity about the current state across a range of projects.

It seems that a primary concern of the user story in the request is that locked users are lost and have no idea what to do? This appears to have improved over the 15 years since this request was opened. We routinely get global lock appeals via the contact form today.

See T47469#9036661. You can also try to log in via username=test and any password and this is what you will got:

图片.png (586×485 px, 39 KB)

This is better than those in 2008, though not in a perfect state: we should also provide (1) the performer of lock and (2) reason of lock.

It seems that a primary concern of the user story in the request is that locked users are lost and have no idea what to do? This appears to have improved over the 15 years since this request was opened. We routinely get global lock appeals via the contact form today.

See T47469#9036661. You can also try to log in via username=test and any password and this is what you will got:

图片.png (586×485 px, 39 KB)

This is better than those in 2008, though not in a perfect state: we should also provide (1) the performer of lock and (2) reason of lock.

As well, short-term global locks should be supported.

@Xaosflux - how has T19929 been adressed since that bug's creation? How much is that still a parent task for this?

@Sj not sure this is a component of the above, the linkage was made by @JJMC89

One thing I wonder about is what features are needed for such a function. Just because normal blocks are appealed on a talk page doesn't mean that this is the desired functionality for a global block, which may be better handled on a central page. And is there really an usecase for expiring global blocks?

And is there really an usecase for expiring global blocks?

See also the (updated) task description. A longer explanation:

Not every locked users are vandalism or spam-only. And currently global locks are used for several types of disruption: (1) a VOA/SOA one; (2) a ongoing one which is likely the result of spillover of local ongoing dispute; (3) a long-term one

In case (1) global locks may be issued
(2) Since Wikimedia projects are largely autonomous, in my opinion a ongoing spillover disruption should be handled by a short-term global block, and let local community handle the rest (or the lock can be reinstated if further disruption occurs). example.
(3) Should better be handled via global bans instead of locks.

I am pretty sure that a global ban would still be enforced by a global lock. So I don't see (3) as an use-case. The example given for (2) sounds like it'd end up a whack-a-mole case, especially considering the sheer amount of blocks in the history, which is really the common failure mode of time-limited restrictions. I also worry that we'd end up overusing time-limited blocks.

Yes I believe global ban would still be enforced by a global lock. For a whack-a-mole case: most vandal are not long-term, so for a Wikimedia project (even if not consider CentralAuth), time-limited blocks has its use. Similarly, for users that have an ongoing global disruption, we can try global block for some time (1 day to 1 year), and if the user clearly do not stop such behavior, it may be a candidate for global locks (or global bans, for non-VOA). However if there are no current disruption after latest administrative action (such as local blocks, or time limited global blocks in the future), or if you believe local community can handle them even if the abuse is cross-wiki, then (since we do not want stewards to act as super admins above local community) it is not a good usecase of global lock (or block) - and if there are previous time-limited global block issued, they served their purposes.

BTW (not directly related): In my opinion globally lock is overused, i.e. even abided by the current de facto guideline (heck, currently we do not have a formal policy governing global locks, and I think we need one, but I don't know what a formal policy should look like), the global locks may be not necessary to prevent damage or disruption, or in other word, there are no signs that future disruption will occur with the current treatment (local blocks, which may be enough). I have criticized stewards' action multiple times for this reason, such as this one.

Updated 2024-01-07: In my opinion

  • Valid use case of global locks: globally banned users and socks; compromised users; deceased users; users with improper name without constructive edits
  • Valid use case of global blocks or locks: spam and vandalism-only accounts; socks of users have cross-wiki improper activity
  • Debatable use case of global blocks or locks: cross-wiki disruption that can not be stopped by short-term global blocks - but in some case we need a formal sanction, i.e. global ban
  • Short-term global blocks: main account of users with ongoing cross-wiki disruptive (but not disruption-only) behavior - if only activity are socks, we only need to block the socks
    • In principle, main accounts (of non-VOA/SOA) should not be globally locked unless there are ongoing abuse that can not be managed by local measure (such as blocks).
  • Not a use case for global blocks and locks: main account with discovered disruptive behavior that have been handled by local wikis, and is not ongoing (even if otherwise meeting other criteria for lock)

Update 2024-01-09:
Global locks is a strong measure to user, and we may also want a weaker one. This is why we have (and use) fixed time block in addition to indefinite ones.

In a nutshell, I will not oppose locking sock accounts, but in most cases, main accounts with long-term activity should better be handled by local community, or via short-time global blocks (for immediate issue), or global bans.

As I observe, many disruption are not premeditated or purposeful (intended to cause cross-wiki disruption at its beginning); instead, many are like someone moving their dispute to another wiki, or harassing wiki A admin in wiki B, once they are blocked in one wiki. This does not have a long-term disruption pattern either, nor if cross-wiki disruption will occur without the first local block. In these cases, we only need short time global block, and let local communities handle the rest.

Update 2024-01-28: In a nutshell, disruption due to strong impulse (e.g. anger) would be a common use case of short-term global block; this stops immediate risk for disruption where still allows local community to handle the potential long-term issue.

I am pretty sure that a global ban would still be enforced by a global lock. So I don't see (3) as an use-case. The example given for (2) sounds like it'd end up a whack-a-mole case, especially considering the sheer amount of blocks in the history, which is really the common failure mode of time-limited restrictions. I also worry that we'd end up overusing time-limited blocks.

We really do need global blocks for temporary accounts which act similar to registered users with respects to locking / global blocks. Locking the accounts would cause them to be logged out and unless we set appropriate auto blocks, it means that the user could just create a new account on their next edit without even realising they had been locked in the first place.

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

Personally I think not allowing global blocks be disabled locally breaks wikis' self-governance, although this is already the case of global locks. Once we start applying global blocks to temporary users, unblocking temporary users locally is similar to disabling global IP blocks locally currently.

Another thing to consider is how will we use global account blocks vs global locks. There are current no community-approved policy for any of them, but as I said multiple time previously, we need one and the current status quo sucks (I have no idea what a proper global lock policy should be, though the next comment provided some ideas). For global account block usage only, there are three options:

  1. The most conservative usage and the one closest the status quo is only using global account blocks for temporary accounts and still use global locks for regular users. Then global account blocks are similar to global IP blocks, which can be locally disabled. I will oppose this opinion.
  2. What I support is the second option: global locks should only be used by globally banned users and socks; compromised users; deceased users; users with improper name without constructive edits - these are cases not supposed to be overrided (i.e. disabled) by local wikis. For cross-wiki vandalism or spam only users, and potentially disruptive socks of global blocked users, we may issue a indefinite global block; for ongoing disruptive user that is not VOA/SOA, we issue a short-time global block (or potentially indefinite if we exhausted short-term one, but in this case a global ban may be considered). Global blocks may be locally disabled. For non-ongoing issues that are not VOA/SOA and do not warrant a formal global ban (example one that meets the current de facto practice of global lock), I will suggest neither global block nor lock and they should be handled by local community.
  3. Tgr suggests to eliminate global locks completely, fully replacing them with global blocks. To prevent compromised users from exploiting accounts, we need T222281: Add a way to prevent user from log in and disable a users session when blocking; to enforce global bans, we need T355385: Allow marking global blocks not disablable by local wiki.

Thanks for the comments.

Based on these comments, I will proceed with making it possible to disable global account blocks on a local wiki. If this is something that is rejected by the community, then a configuration to disable this ability can be added.

Also this task allows globally blocking accounts and temporary accounts. Would it be useful to add configuration to control whether global blocks can be placed on registered users? My thinking is that this would make it possible to enforce the first option on WMF wikis if the community rejects the idea of global blocks for registered/named accounts.

My proposed simple guide: (THIS IS NOT THE CURRENT DE FACTO GUIDELINE!)

  1. Are user one of the following cases: globally banned users and socks; compromised users; deceased users; users with improper name (suppressable, or obviously suggest a LTA or vandal) without constructive edits? Yes: globally lock them - local wikis should not opt out.
  2. Are they vandalism or spam only users, or user with no significant constructive edits? Yes: Indefinitely globally block them (though I am not against a global lock).
  3. Are they sockpuppets (note this point does NOT apply to master accounts)? Yes:
  4. Are they currently making disruption (after appropriate local blocks, if there is not an emergency), and currently or previously causing issues in multiple wikis (for sockpuppeter, we only consider activity of master account - i.e. how master account is abusive - in this point, since we have the previous point to handle socks; however, for abusers with no obvious main account, we can treat all accounts as socks and apply #3 to them)? Yes:
    • 4a: Did we exhausted short-term global blocks (up to one year), or there are apparently long-term abusive pattern? Yes: Indefinitely global block them, though a global ban may be considered.
    • 4b: No: Issue a short-term global block.
  5. If none of #1-#4 meet, then it is not a good case of global block or lock. Let local community handle the issue. (Note currently global locks are used in #1-#4 as well as cases meeting none of them, which in my opinion neither global lock nor global block is appropriate.)

(in a nutshell: we need global block of named users and this describes its use cases)

Thanks for the comments.

Based on these comments, I will proceed with making it possible to disable global account blocks on a local wiki. If this is something that is rejected by the community, then a configuration to disable this ability can be added.

One way is disabling this ability by configuration like $wgAllowDisablingGlobalAccountBlock, another way is to introduce a new user right (i.e. split the current globalblock-whitelist to two rights) that may be granted to nobody.

Also this task allows globally blocking accounts and temporary accounts. Would it be useful to add configuration to control whether global blocks can be placed on registered users? My thinking is that this would make it possible to enforce the first option on WMF wikis if the community rejects the idea of global blocks for registered/named accounts.

Note: Global blocks on named users is the original purpose of this task since when this task is filed in 2008 temporary account is far from exists. Also in 2017 there is a community discussion: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Admins_and_stewards/Extend_global_blocks_to_named_accounts

Tgr updated Other Assignee, added: Dreamy_Jazz; removed: Tgr.Feb 9 2024, 11:16 PM
In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

This is the point :P

The reason I/we want global blocks is for the relatively few cases where a user is engaging in cross-wiki abuse, yet there are projects where they contribute constructively without issue (and where the project would like that to continue). I don't expect this to replace global locks, just allow more options for handling cross-project conduct moderation.

My proposed simple guide...

I do not believe your proposed process for global conduct moderation is relevant to this ticket, and it can create some confusion for the people working on this about the ask (from stewards) for global blocks.

Blocks of expired temporary accounts make no sense (but admins may tend to use indefinite block for VOA) and they will inflate the database and confuse users. So some proposed ideas:

  • Prevent blocks of temporary accounts for more than the lifetime (one year in Wikimedia wikis)
  • Prevent blocks of already expired temporary accounts
  • Automatically purge blocks of temporary accounts upon expiration

Blocks of expired temporary accounts make no sense (but admins may tend to use indefinite block for VOA) and they will inflate the database and confuse users. So some proposed ideas:

  • Prevent blocks of temporary accounts for more than the lifetime (one year in Wikimedia wikis)
  • Prevent blocks of already expired temporary accounts
  • Automatically purge blocks of temporary accounts upon expiration

Admins that block expired accounts should get an message saying that the block will not have any effect and they should use an IP ban instead. Non-technical admins probably will not know what to do with expired temporary accounts. There is of course the point that the block might not be necessary, due to the high risk of the blocking user not being active, but the admin should decide that, not the software.

Blocks of expired temporary accounts make no sense (but admins may tend to use indefinite block for VOA) and they will inflate the database and confuse users. So some proposed ideas:

I personally don't see a need to expire blocks. However, I'm also probably not the final decision maker on this. My points below are from a technical feasibility point of view.

  • Prevent blocks of temporary accounts for more than the lifetime (one year in Wikimedia wikis)

The expiry may decrease and/or increase, so limiting the length of blocks could cause these temporary accounts to be unblocked before they are expired.

  • Prevent blocks of already expired temporary accounts

This may be possible. However, the expiration of temporary accounts does not apply immediately after the account becomes older than X days because the expireTemporaryAccounts.php maintenance script is used to expire temporary accounts. This means that on WMF wikis the expiration will likely not occur until at least a few hours after expiration is expected by the config. This makes it difficult for the software to determine for sure whether a temporary account has expired.

  • Automatically purge blocks of temporary accounts upon expiration

This is possible by extending the existing expireTemporaryAccounts.php maintenance script to provide a way for GlobalBlocking extension to perform custom actions related to temporary accounts. However, I would argue that at this point there isn't much need to expire blocks and this could cause confusion as:

  • Removing the global block would mean it no longer appears to be blocked and currently there isn't a message indicating that a temporary account has expired which would replace this
  • Blocks that are on the local wiki do not expire like this.

This makes it difficult for the software to determine for sure whether a temporary account has expired.

We expire a temporary account by removing its session token, so we can check whether the account is expired by checking whether they has a valid token.

This makes it difficult for the software to determine for sure whether a temporary account has expired.

We expire a temporary account by removing its session token, so we can check whether the account is expired by checking whether they has a valid token.

I can't see an easy way to check that the CentralAuth auth token has been changed, considering that it isn't unset and instead set to a new random token in CentralAuthUser::resetAuthToken by the script that expires the temporary accounts.

Source: https://gerrit.wikimedia.org/g/mediawiki/extensions/CentralAuth/+/c8a607f3ced7990131dbc358f07d83c9d8a6d81b/includes/User/CentralAuthUser.php#2962

So a potential solution is to introduce a CentralAuthUser::removeAuthToken that removes the token completely (we did something similar for system users).

So a potential solution is to introduce a CentralAuthUser::removeAuthToken that removes the token completely (we did something similar for system users).

I agree that is a potential solution.

So a potential solution is to introduce a CentralAuthUser::removeAuthToken that removes the token completely (we did something similar for system users).

cf T352823: Split user table to multiple tables which proposes:

  • Introduce seperate tables for local user password, email and token
  • Remove all local password, email and tokens (and prevent inserting new ones) in favor of CentralAuth
  • Introduce table for user password, email and token in CentralAuth

So to remove/reset a token we only need to remove one row. (For regular users, logging in with password will generate a new token, but it would be impossible for temporary accounts).

The blocking thing seems to me like a solution in search of a problem, but it might be useful to indicate that a temporary account has expired (this could apply to plenty of other situations like someone trying to edit the talk page).

In fact maybe we could make the script block the temporary account when it expires, that's a state already understood by all kinds of tooling (and e.g. a warning is already implemented when trying to message the user). It also works regardless of what authentication extension you use, while checking if the session has been invalidated would have to be implemented separately for all authentication extensions.

Why I want to say so are:

  • For the database perspective moot blocks may clutter the database, though I am not sure how large the problem is (there may be more locked spambots than blocked temporary accounts).
  • For user perspective they may also clutter block list. Also I am not sure whether it is a big problem.
  • Admins may try to block already expired temporary accounts, so we should let admin know that such block will have no effect.

So I only present an idea we can discuss and consider, not fully support it.

In my opinion it may be a problem when other users try to communiate to expired temporary accounts, since they will notice nobody. This should be another task (and MediaWiki currently does not have a native way to denote user should not receive talk page message, which can be used by Twinkle and other 3rd party tools. On the other hand, other users or even the user itself may stalk (i.e. watch) the talk page of former temporary account, though I do not know how often this will happen.

In fact maybe we could make the script block the temporary account when it expires, that's a state already understood by all kinds of tooling (and e.g. a warning is already implemented when trying to message the user).

Note: Blocking does not complete revoke access of one account, nor is it permanent (where expiring temporary accounts would be).

In T17294#9560358, @Tgr wrote:

In fact maybe we could make the script block the temporary account when it expires

Or rather just apply a system block based on registration date.

In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

This is the point :P

The reason I/we want global blocks is for the relatively few cases where a user is engaging in cross-wiki abuse, yet there are projects where they contribute constructively without issue (and where the project would like that to continue). I don't expect this to replace global locks, just allow more options for handling cross-project conduct moderation.

One wonders how that interacts with WMF global bans or other situations where we really do not want local projects to opt out of a global b/lock

In T17294#9563885, @JEumerus wrote: (...)

One wonders how that interacts with WMF global bans or other situations where we really do not want local projects to opt out of a global b/lock

Global bans are enforced per global lock which does not offer an opt out option. This is won't change with the proposed feature. Global blocks offer an opt out option via Special:GlobalBlockWhitelist but are currently only available for IPs. If global blocking of accounts becomes available it won't be used for globally banned users.

In T17294#9563885, @JEumerus wrote: (...)

One wonders how that interacts with WMF global bans or other situations where we really do not want local projects to opt out of a global b/lock

Global bans are enforced per global lock which does not offer an opt out option. This is won't change with the proposed feature. Global blocks offer an opt out option via Special:GlobalBlockWhitelist but are currently only available for IPs. If global blocking of accounts becomes available it won't be used for globally banned users.

Yes this is what I proposed (global locks are kept as-is), though Tgr suggest to eliminate global locks completely (replacing with global blocks), and in such case we need both T222281: Add a way to prevent user from log in and disable a users session when blocking and T355385: Allow marking global blocks not disablable by local wiki.

Trust and Safety Product Team are taking this on as part of the Temporary accounts work. The main goal is T355286, which requires updating GlobalBlocking to block temporary accounts, which is most sensibly done by allowing blocking all registered accounts (it's no extra work and it's desired).

We'll scope this particular task to doing bringing global blocks for registered/temp users on a par with global blocks for IP addresses.

Adding @Madalina as the product manager on this.

Other useful ideas have been shared in the discussion above, and these should be filed and discussed as separate tasks:

  • global autoblocks (T355286)
  • figuring out how blocks/global blocks work with expired temp accounts
  • making account creation block configurable
  • making email block configurable

Change 1006886 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[integration/config@master] Enable 'extension-codehealth' for GlobalBlocking

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

Change 1006886 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/GlobalBlocking] Enable 'extension-codehealth'

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

In T17294#9560358, @Tgr wrote:

In fact maybe we could make the script block the temporary account when it expires, that's a state already understood by all kinds of tooling (and e.g. a warning is already implemented when trying to message the user). It also works regardless of what authentication extension you use, while checking if the session has been invalidated would have to be implemented separately for all authentication extensions.

In T17294#9561677, @Tgr wrote:

Or rather just apply a system block based on registration date.

Filed as T359064: Represent temporary account expiry with system blocks.