Content-Length: 456884 | pFad | https://phabricator.wikimedia.org/T17294

s ⚓ T17294 Allow globally blocking of accounts
Page MenuHomePhabricator

Allow globally blocking of accounts
Closed, ResolvedPublicFeature

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

Accounts cannot currently be blocked globally, 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

This is also useful for the Temporary accounts project, as locking a temporary account would mean that the user will just create a new temporary account on their next edit. By globally blocking them, it prevents edits without logging them out.

Related Objects

StatusSubtypeAssignedTask
Resolvedkostajh
DeclinedNone
In ProgressNiharika
OpenNone
OpenDreamy_Jazz
OpenDreamy_Jazz
DeclinedNone
DuplicateNone
ResolvedFeatureDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedBUG REPORTDreamy_Jazz
ResolvedDreamy_Jazz
Resolved Tchanders
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
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
ResolvedUrbanecm
ResolvedBUG REPORTDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedBUG REPORTDreamy_Jazz
ResolvedDreamy_Jazz
OpenDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
OpenNone
ResolvedJayprakash12345
ResolvedFeatureDreamy_Jazz

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
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: Decide if we want to 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

Dreamy_Jazz added a project: User-notice.
Dreamy_Jazz updated Other Assignee, added: Skizzerz; removed: Dreamy_Jazz.
Dreamy_Jazz changed the subtype of this task from "Task" to "Feature Request".
Dreamy_Jazz added a subscriber: Skizzerz.
Dreamy_Jazz renamed this task from Allow blocking of global accounts to Allow globally blocking of accounts.Jun 28 2024, 9:46 AM
Dreamy_Jazz updated the task description. (Show Details)

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

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.

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

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.

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.

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.

@Dreamy_Jazz is there anything else to do for this task?

@Dreamy_Jazz is there anything else to do for this task?

Yes, the remaining subtask T358979. However, most of that task is done including the link to actually globally block the account.

As such, I think this can be marked as resolved.









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://phabricator.wikimedia.org/T17294

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy