Jump to content

Community health initiative/Allow CheckUsers to set User agent-based IP Blocks

From Meta, a Wikimedia project coordination wiki

This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team may build. Development of this feature has not been decided or prioritized.

🗣   We invite you to join the discussion!
🛠   Track in Phabricator at T100070.

The WMF's Anti-Harassment Tools team has decided to not pursue User Agent blocks, as we have determined the effectiveness to be extremely low and the cost of implementation to be extremely high. Additional thoughts on improving blocks can be found at Community health initiative/Blocking tools and improvements.

Below is early project research:

Allow CheckUsers to set user agent-based IP Blocks

[edit]

Background information

[edit]

Blocks can be set against a username, IP address, or IP range. IP addresses can be easily spoofed or changed via proxies. The barrier to create a new account is very low and easily circumventable. CheckUsers can currently see user agent information in their work. While this can also be spoofed, it is a reliable piece of information we're already collecting.

The Wikimedia movement values openness and privacy, so we must balance walling off bad actors against keeping our platform accessible to good-faith newcomers.

Problem: Username or IP address blocks are easy to evade

[edit]

Blocks can be evaded by changing the IP address (intentionally or unwittingly) so IP range blocks are often used to stop block evasions. However, these can cause collateral damage by preventing good-faith innocent bystanders from editing. If an additional piece of data was used in addition to IP range, it could result in more (or wider) IP range blocks being set with less collateral damage.

Proposed solution

[edit]
Mockup of Checkuser interface with User-agent block

A possible solutions is to implement new blocking techniques that use different pieces of identification technology.

Allow IP addresses, particularly IP ranges, to be blocked via user agent in addition to the IP address/range. CheckUsers can currently see user agent information when checks are run. CheckUsers should be the only group to use this function.

Detailed requirements are documented at #Requirements below.

Pros and cons

[edit]

Pros

[edit]
  • It is a piece of information that we're already collecting.
  • CheckUsers already understand how to interpret the data.

Cons

[edit]
  • It changes somewhat frequently.
  • It can be spoofed.
[edit]

Requirements

[edit]
  • On Special:Block, introduce a new checkbox to allow blocking by User Agent in addition to IP
    • This option should only appear to CheckUsers (has the checkuser right, or may want to introduce a new right)
    • This option should only appear if an IP address or IP range is provided in the 'user' field
  • The default should be unchecked (off) with a disabled text input box next to it.
    • The text input box should become active if the checkbox is checked
    • Label for preference TBD
  • If a user is editing within the IP address or IP range of this type of block...
    • ...if their user agent matches, they should be blocked from editing, as current blocks work.
    • ...if their user agent does not match, they should be allowed to edit with no warnings or notices.
  • Visiting Special:Block on a currently blocked user:
    • If a CheckUser goes to Special:Block to update the block, they should see the UA in the text area and update it and re-save the block.
    • If an admin (or someone else with block permissions without UA block permissions) goes to Special:Block to update the block:
      • they should see there is a UA block but not be able to see the contents of or edit the UA text area.
      • they should be able to adjust the rest of the block parameters
  • Log entry
    • In the log entry (on Special:Log, Special:Block, etc.) the block should be marked as a filtered (or CU-filtered) block
    • e.g. 12:34, 23 March 2018 Foobar (talk | contribs | block) blocked 000.0.0.000 (talk | contribs) with an expiration time of N (anon. only, account creation blocked, filtered) (block reason) (unblock | change block)
Potential future improvements
[edit]
  • Data validation on save to ensure an effective block is being set
  • Support regex
  • URL parameter(s) to automatically check the box and fill in the text field

Discussion questions

[edit]

We would greatly appreciate user feedback on this proposed feature. Specifically around:

  1. Does this fit into the workflows of Wikimedians with CheckUser permissions, or is this cumbersome?
  2. Does the placement at the bottom of Special:Block make sense? Or should it be moved next to the username / IP address field? Or somewhere else?