Community Tech/Blocking tools

This page documents Community Tech's work on "Improve blocking tools", #29 on the 2015 wishlist. (Wishlist proposal)

See Community health initiative/Blocking tools and improvements for updates after 2017.

January 30, 2017

The "send a cookie with each block" project is still going; we're currently taking care of some follow-up tasks. See phab:T5233. Once all of the open issues are resolved, we plan to enable and test cookie blocking on English Wikipedia: phab:T152076.

Work on Special:RangeContributions as described below is underway -- see phab:T145912 for details.

Nov 3, Nov 17

Current Special:Contributions options

IP range calculator on Special:CheckUser

Notes on adding IP range support to Special:Contribs. (T147664)

It'll be an extension on a new Special page, probably Special:RangeContribs.

It will include an IP range calculator (as seen on Spec:CheckUser), and it'll be limited to the last 30 days (for performance and architecture reasons).

The IP calculator can be on top, collapses when you don't need it. It runs automatically as you enter IP addresses, like the one on Checkuser. There's a button next to that which adds it directly to the input field. (You can also copy/paste.)

Functions to include: Namespace, Tag filter, 4 checkboxes. It won't need the date picker.

Workflow:

• User spots similar vandalism happening on closely related IPs.
• User opens Special:RangeContribs, copies IP addresses into the IP range calculator. Range calculator produces a common CIDR that can be used for range search, and adds that calculated range into the "Search for contributions" box.
• User sets namespace/tag filter as necessary, and clicks Search. Page generates a contributions list for that range.

Helpful links:

• Special:CheckUser currently has a "Find common range for a list of IP addresses" function.
• Xtools Range Contributions tool
• Mediawiki.org's Help:Range blocks
• Enwiki's Special:Block page has a link to a simple range calculator

Nov 2

Current blocking tools status:

• Send a cookie with each block (T5233) -- currently in progress
• Add ability to search by user agent from CheckUser interface (T146837) -- there's a spec and wireframe on the ticket. A first step (adding an index) in the backlog. (T147894)
• Investigation: How to add IP range support to Special:Contributions (T147664) -- currently in discussion, starting to put together a spec
• Investigation: Adding a check for the block cookie to the account creation process (T149330) -- in the backlog, we'll be looking into extending the "Send a cookie with each block" solution to apply to account creation as well.

Oct 11

Team meeting to discuss blocking tickets.

Throttle account creation and email sending per browser as well as IP address (T106930) -- decided to drop this, after feedback from Tgr and James A. In its place, we'll use the block cookie for account creation attempts -- (T149330)

We discussed whether this will be a problem for editathons; it's probably not. Program coordinators often have account-creation right, which lets them create as many accounts as they like. Most programs, people create accounts on their own computers.

The ticket says "when those counds exceed some number" -- that should be the same number as the IP limit, whatever that is.

• risk: low
• impact: medium (not a magic bullet but should deter some casual vandals/socks)
• feasibility: high
• support: high (came from community wishlist survey and endorsed by Support & Safety)

Add IP range support to Special:Contributions (T147664, T145912)

This would affect core MW code and core DB tables. It may need an ArchCom meeting, maybe at the Dev Summit?

• risk: medium
• impact: high
• feasibility: medium
• support: medium

Recursive checkuser feature (T11858) -- ticket was closed as declined, see ticket for info

A good example of the problem, from 2007: Artaxiad

We need to talk to checkusers to find out how common this is. How often does it happen? What's the output you'd like to see? Are there reasonable limits (x levels deep, only show branches that have x names)?

• risk: high (could have performance issues, need to get the UI right, not sure if this request is in line with current CheckUser policies)
• impact: ? (need to discuss with CheckUser users)
• feasibility: medium (UI challenges)
• support: high (came from Community Wishlist Survey)

Add ability to search by user agent from CheckUser interface (T146837)

This would require an index of the existing column -- a schema change to the database that we'd need the DBAs to implement. This could slow things down quite a bit, depending on the DBAs' workload. We should start that process soon, so it can get on Jaime's queue. Ticket: Create index for user agents in cu_changes table (T147894) -- estimated as 3, in backlog

Before we start digging into this, we should run a test to see if this will actually give useful data to the CheckUsers, or if user agents are so common that we would drown in false positives. We'll run queries on some sample user agents, to see what kind of data we get back. It's okay if these queries take a day or longer to run on the unindexed table. (T147895) -- estimated as 1, in backlog

• risk: high
• impact: ? (depends on the results of the test queries)
• feasibility: medium
• support: medium

Create a bot to automatically block the IP addresses of proxies (for any wiki)

Procsee on enwiki blocks about 20/min, mostly for 60 days. It doesn't block proxies that make edits -- is it just searching for proxies and pre-emptively banning? Is this something we should make global? The bot is run by User:Slakr -- the source code isn't public (bc security) but Slakr will probably share it with us. Could possibly build something based on the TorBlock extension.

• risk: high
• impact: medium/high
• feasibility: ?
• support: medium

Sept 30

Tickets to discuss with team:

• Add ability to search by user agent from CheckUser interface T146837
• Throttle account creation and email sending per browser as well as IP address (T106930)
• Recursive checkuser feature (T11858)
• Enable automatic proxy checks
• Add IP range support to Special:Contributions (T147664, T145912)

Sept 27, 2016

James's recommendations:

• Add ability to search by user agent from CheckUser interface T146837

Sept 20

Estimation meeting.

T5233: Set a cookie with each block. This is a first step in our work on blocking tools. Trigger condition is when the blocked user tries to edit; we need to check against the block and set/update the cookie. Make sure it's not in the varnish cache. As a first step, it's kind of like closing the door when the zombie horde is approaching, which won't be enough to stop them but it's just embarrassing to have the door open. 8 points, in the backlog.

T146230: EventLogging for the block cookie. This helps us to make sure the cookie is working at all, and a signal if we're blocking too many. 3 points, in the backlog.

T145912: Add IP range support to Special:Contributions. This is Leon's idea, another step in blocking tools. It will help to reassure admins that it's okay to block based on a range, because they'll be able to see that there aren't any innocent editors caught in the block. Leon is talking to NeilN on enwp about this -- Neil is going to start an on-wiki conversation. See User talk conversation.

Sept 19, 2016

Tickets in original proposal:

• Send a cookie with each block (T5233)
• Allow User agent (UA)-based IP Blocks (T100070)
• Throttle account creation and email sending per browser as well as IP address (T106930)
• Recursive checkuser feature needed (T11858)

• Mark accounts that hit limit of account creation in one IP for functionaries (T107651) -- this is basically profiling. we'd give functionaries a list of 5 accounts, before they've made edits. what do they do with that information, sit on it and wait until one of them vandalizes something? the only trigger for this being useful is the normal checkuser process anyway. Also: this is guaranteed to pick up false positives from editathons and classes. (Danny)

• Checkuser watchlist feature (T21796) -- This would be tricky to implement (especially allowing a way to compile and share the data while keeping it private). The impact would also be relatively low. (Kaldari)

• Block by device ID (needs check with WMF Legal first)
• If an account with a registered email address is blocked with account creation blocked, prevent creation of any new accounts with that email address. (Optional, because we don't require email on registration.)

Wishlist from Stewards' Visit in October 2015: (report)

The technical tasks:

1. Global CheckUser & Global CheckUser log
2. GlobalUserMerge completion
3. Enable automatic proxy checks
4. Modernization of design & workflow of Admin/Steward tools
5. Ability for global lock/multi lock through CU (done in May, T128605)
6. A new global block tool instead of global lock (T133583 closed as duplicate of T47094?)
7. Match options for IPv6 blocks with the options for IPv6 checkuser (done in April? T132893)
8. Abuse filter re-write
9. Email abuse reporting

Stewards and global tools Workboard: Phab board

Conversation with Leon:

Process: check the talk page, verify the edits are disruptive. Do a WHOIS check. For a shared IP, a more friendly block template. For static IP, standard block template.

There's no tool to check contributions from IP version 6, need to be able to get a range. Leon's ticket: Add IP range support to Special:Contributions T145912

AbuseFilter can be used when there's a persistent vandal. Also Blacklist an external link.

Example: regular attack pages about User:Junior5a, using variations like 0 for O. Back and forth with the abuse filter.

CheckUsers can check IPs, and find "sleepers" -- new accounts by the same person, created in advance.

Another ex: User A was hounding User B, following and reverting all of B's edits. A was in an IP range, but there were good contributors in that range. Had to use AbuseFilter scheme -- IP from this range, reverting an edit from B. This worked, stopped completely after a week.

Links: Edit filter noticeboard, Edit filter requests

Leon's recommendations:

• Add IP range support to Special:Contributions T145912

• AbuseFilter: Add features to make it more comprehensive

• IPv6 range contributions tool. Put in a list of IPs, calculate the range, and show contributions from that range -- make sure there aren't good editors in there. Admins would be more likely to use a range block if they had this tool.

• Enable automatic proxy checks. There's a policy against editing from a proxy. ProcseeBot uses an algorithm to check for proxy. This could be global.