Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

[Epic] Implement global autoblocks from global user blocks
Closed, ResolvedPublic

Description

Background

See also the parent task: T355286: [Epic] Globally blocking a temporary account should prevent further account creations

Problem

Once a temporary account is globally blocked, the user could just make another edit, causing another temporary account to be autocreated.

Solution
An autoblock (an automatically created block against the user's IP address) would prevent the user making subsequent edits once logged out of their temporary account. See more documentation about autoblocks.

Autoblocks can currently only be made for local blocks. This task is for implementing autoblocks for global blocks. Since autoblocks only work against user accounts, this task must be completed first: T17294: Allow globally blocking of accounts.

How would they work

Global autoblocks could work similarly to local autoblocks:

  • The last IP address used by the blocked user is blocked automatically for 24 hours (this duration is controlled by a sitewide configuration option)
  • Any IP address the user tries to edit from subsequently is also autoblocked
  • If the original block is removed or updated to block different things, the autoblock is similarly removed or updated
Technical notes

Notes about how autoblocks work locally:

  • Local blocks are stored in the block table
  • Any block that is an autoblock has block.bl_parent_block_id set to the ID of the original block against the user account
  • Any block against a user account that causes autoblocks to be made have block.bl_enable_autoblock true
  • Some IPs are exempt from autoblocks (defined in the message block-autoblock-exemptionlist)
  • The maximum duration is controlled by the config AutoblockExpiry
  • An autoblock is made when the original block is inserted via DatabaseBlockStore::insertBlock calling ::doRetroactiveAutoblock
  • If CheckUser is enabled, the block is made by CheckUser handling the PerformRetroactiveAutoblock hook, since CheckUser can look up IP addresses. (Otherwise core can do it, but that's not the case on WMF production: T356430#9940748)
  • Subsequent autoblocks are made via User::spreadAnyEditBlock (callers here)
  • Autoblocks are updated via DatabaseBlockStore::updateBlock

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
OpenDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedFeatureDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedFeatureDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedBTullis
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
OpenNone
OpenNone

Event Timeline

Note: autoblocks only last for one day, though there are proposal to extend it: T43479: [Spam/vandalism] Raise $wgAutoblockExpiry noticeably - Note if I read the task correctly, the current blocker of increasing $wgAutoblockExpiry is not a technical one, but a social one, namely we need to measure how increasing it is effective.

Dreamy_Jazz renamed this task from Implement global autoblocks from global user blocks to [Epic] Implement global autoblocks from global user blocks.Sep 16 2024, 10:28 AM

I think we can call this resolved. The remaining clean-up work is depending on a WMF steward updating their code and may be a few more weeks.