Page MenuHomePhabricator

[Epic] Globally blocking a temporary account should prevent further account creations
Open, Needs TriagePublic

Description

Background

Temporary users have global accounts, the same as fully registered users. Once T17294: Allow blocking of global accounts is complete, we should be able to globally block temporary accounts. However there is nothing stopping the user from creating a new temporary account on their next edit after they end their session (such as via clearing cookies or using a different browser).

Possible approach

This could involve solving T17294: Allow blocking of global accounts and allowing autoblocks - so a temporary account could be globally blocked with an autoblocking block. (See also T340275, but it will likely be merged into T17294 as they can be solved together.)

Additional questions about the block itself:

  • How long for?
  • Account creation only? (would allow already-created temp users to keep editing)

Related Objects

StatusSubtypeAssignedTask
In ProgressNiharika
OpenNone
OpenNone
OpenSkizzerz
OpenDreamy_Jazz
OpenNone
OpenNone
OpenNone
OpenNone
OpenDreamy_Jazz
OpenDreamy_Jazz
ResolvedDreamy_Jazz
OpenDreamy_Jazz
ResolvedDreamy_Jazz
OpenDreamy_Jazz
OpenDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedMarostegui
ResolvedMarostegui
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedTchanders
ResolvedDreamy_Jazz

Event Timeline

One way could be to apply a GlobalBlock to the IP address used when a temp account is locked.

@Dreamy_Jazz Thanks for this idea.

If we think of temp accounts as being like fully registered accounts, then it makes sense that globally locking should work.

If we think of temp accounts as being like IP users, then global locks don't currently work for IP users (the concept makes no sense) so are we losing anything by them not working for temp users? In other words:

  • If a temp user does something that would warrant a global lock, what would we do in the equivalent situation if an IP user did that same thing now?
  • Could we still take that same action for the temp user?

One way could be to apply a GlobalBlock to the IP address used when a temp account is locked.

See also: T340275: Allow GlobalBlocking to block temporary accounts

Thanks. We could keep them separate for now in case we go in a different direction or come up with additional measures for temporary accounts - but they may end up being duplicates if not.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

+1 to Xaosflux. Global locks are a necessary tool, though global blocks should also be an option.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

From what I understand of that implementation, it would not work. One of the main reasons we (stewards) want global blocking is because it would optimally allow individual projects to unblock a user while preventing editing on all other projects, and would not log them out. A global lock is a different tool for a different purpose and should not be replaced.

Note only Tgr propose to replace global lock with a "disable session and disable login" option of global block. I do not oppose keeping global lock feature as-is.

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

Note: Since T17272/326e4d86c4d7, core MediaWiki (not just CentralAuth) has a user-is-locked concept, and is checked in BotPassword (T194605), though it seems no core MediaWiki feature is setting it.

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

If it will be possible to configure a global block of an account to do exactly what a global lock does now, then I wouldn't have objections. It would need to log the user out on all projects, prevent log-in, and prevent local projects from unblocking the user.

For me, the main benefit of being able to globally block accounts is that individual projects can (I assume) unblock/exempt that user locally. The "lock" button in these future global block settings would also need to prevent that.

@Vermont I think that shouldn't be problematic. That said, being able to globally block registered users would be useful for the temporary account migration (because locks don't really work for temp users) and turning account locking into a block isn't directly relevant, so that's probably something for the longer term as preparing CentralAuth for temp users and for third-party cookie deprecation are much more urgent.

For now, do you agree T17294: Allow blocking of global accounts would cover this task (if it extends to temp users)?

(Just to clarify it's TSP which is Trust and Safety Product Team after the merger).

We should probably convert this task into allowing autoblocks for global blocks on accounts instead of declining, as T17294: Allow blocking of global accounts does not describe creating autoblocks for global blocks.

I hesitate support closing T19929: CentralAuth account locks should trigger global autoblocks because I wouldn't want to close that until global blocks can be made which have the same features as a lock (i.e. logging the user out immediately, preventing login, and not allowing local disabling). At that point I would be comfortable declining it as part of a broader moving locking to become global blocks effort.

Implementing the feature parity, especially logging out immediately and not allowing the user to log back in, isn't something that would be that would be useful for temporary accounts blocking (as you can't log into an existing temporary account as it has no password and logging the temporary account out when it is a major reason that global blocks are being used instead of locking for temporary accounts).

Disallowing local disables of the block may be something that is useful, but considering that the status quo for IPs is allowing individual projects to locally disable the blocks then I question how useful this would be for temporary accounts (considering that we treat them like IPs in some ways).

Dreamy_Jazz renamed this task from Globally locking a temporary account should prevent further account creations to Globally blocking a temporary account should prevent further account creations.Feb 19 2024, 10:59 PM
Dreamy_Jazz updated the task description. (Show Details)
Tchanders renamed this task from Globally blocking a temporary account should prevent further account creations to [Epic] Globally blocking a temporary account should prevent further account creations.Mar 1 2024, 11:04 AM