@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#9528943, @Dreamy_Jazz wrote:

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:
   • 3a: Are they socks of globally blocked or locked users? Yes: we assume bad faith in 3b. (Note in my opinion this should not always mean to block/lock, see https://en.wikipedia.org/wiki/User:Worm_That_Turned/Quiet_return plus https://en.wikipedia.org/wiki/User:Tamzin/Adverse_possession_unblock)
   • 3b: Are they disruptive, or there are reason to believe disruption will continue? Yes: Indefinitely globally block them. (though I am not against a global lock).
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)

In T17294#9529162, @Dreamy_Jazz wrote:

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

In T17294#9528943, @Dreamy_Jazz wrote:

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.

In T17294#9529206, @Bugreporter wrote:

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

In T17294#9556621, @Bugreporter wrote:

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.

In T17294#9556621, @Bugreporter wrote:

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.

In T17294#9558424, @Bugreporter wrote:

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

In T17294#9558482, @Bugreporter wrote:

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.

In T17294#9558482, @Bugreporter wrote:

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#9547674, @Vermont wrote:

In T17294#9528943, @Dreamy_Jazz wrote:

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#9564494, @Johannnes89 wrote:

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.

Change #791800 abandoned by Dreamy Jazz:

[mediawiki/extensions/GlobalBlocking@master] Allow blocking global accounts

Reason:

Has been split into separate patches large scale refactors, so this patch is no longer necessary.

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

I propose that this be added to User-notice because this will have a large impact for the Wikimedia Stewards and will affect how users request that accounts be prevented from editing globally.

The exact deployment date of this feature to Wikimedia wikis is not decided at the moment. However, it will likely be at least a few weeks away.

Deployment date to WMF wikis will be 18th of July.

I would like for this to be in Tech news for the week of the 22nd of July.

The documentation is a bit light onwiki still, perhaps a bit more attention would be useful. For example, if global account blocks are or are not bypassable with the local GlobalBlockWhitelist

In T17294#9968450, @Xaosflux wrote:

The documentation is a bit light onwiki still, perhaps a bit more attention would be useful. For example, if global account blocks are or are not bypassable with the local GlobalBlockWhitelist

Yes they are. Is this not covered by https://meta.wikimedia.org/wiki/Global_blocks#Local_unblocking? I updated it to remove the mention of "IP", so that it reads for any global block.

Also if there are any other documentation pages than https://www.mediawiki.org/wiki/Extension:GlobalBlocking, https://meta.wikimedia.org/wiki/Global_blocks, https://meta.wikimedia.org/wiki/Global_locks, and https://meta.wikimedia.org/wiki/Global_blocks/FAQ that need updating, if you could detail these that would be useful. Thanks.

https://meta.wikimedia.org/wiki/Global_blocks
A global ban should be discussed in its own RFC and mentioned widely on meta, and on all communities where the user is active in the local language. Notice should be given, at a minimum, wherever local bans are discussed – or on the village pump if no local process exists

Global bans should still be enforced via locks, since we do not expect local communities to override them.

As I said at T17294#9529206, cases that locks should still be used once global blocks are available are:

• WMF or community global banned users and socks
• compromised users
• deceased users
• users with improper name (suppressable, or obviously suggest a LTA or vandal) without constructive edits

In T17294#9968510, @Bugreporter wrote:

https://meta.wikimedia.org/wiki/Global_blocks
A global ban should be discussed in its own RFC and mentioned widely on meta, and on all communities where the user is active in the local language. Notice should be given, at a minimum, wherever local bans are discussed – or on the village pump if no local process exists

Global bans should still be enforced via locks, since we do not expect local communities to override them.

As I said at T17294#9529206, cases that locks should still be used once global blocks are available are:

• WMF or community global banned users and socks
• compromised users
• deceased users
• users with improper name (suppressable, or obviously suggest a LTA or vandal) without constructive edits

Just noting that the section was there before my edits. I will edit that section now.

I would also note that it is planned to move global locking into the GlobalBlocking extension in T359116, and as part of this it may be decided to replace all existing global locks with global blocks that disable login and cannot be disabled locally.

In T17294#9968294, @Dreamy_Jazz wrote:

I would like for this to be in Tech news for the week of the 22nd of July.

Sounds good! Please let us know (before the 18th) if you have any suggested draft wording and which links need to (or could also) be included. Thanks.

In T17294#9974853, @Quiddity wrote:

In T17294#9968294, @Dreamy_Jazz wrote:

I would like for this to be in Tech news for the week of the 22nd of July.

Sounds good! Please let us know (before the 18th) if you have any suggested draft wording and which links need to (or could also) be included. Thanks.

Thanks. I've added some suggested wording to https://meta.wikimedia.org/wiki/Tech/News/2024/30. Feel free to modify.