Page MenuHomePhabricator

Make non-CUs linking users and IPs when CUs use block forms in CheckUser harder
Open, MediumPublicFeature


Feature summary (what you would like to be able to do and where):
Special:InvestigateBlock and Special:CheckUser in 'Get users' mode should be able to allow CUs to more easily separate the IPs and accounts they block. Currently the same reason, talk page content and user page content is used in blocking IPs and accounts. This means that a non-CU can look at the block log / contributions page of a CU and see that these IP / account blocks were made at the same time with the same reason and content for the user talk / user page which makes it clear that the users / IPs are related.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Currently blocking both IPs and accounts at the same time in Special:InvestigateBlock and Special:CheckUser is not really possible without risking violating the disclosure agreements. This is especially the case if the reason or content added to the user talk / user page mentions a user or case, as this would directly link an IP to account(s).

With this a CheckUser could block IPs and accounts using the same form but through a variety of methods the connection could be made less clear.

Benefits (why should this be implemented?):
It would make blocking accounts and IPs easier as this could be done using the same form by the CU without connecting an IP and account.

Lets say CU X wants to block account Y and IP Z because they are socks of A. They want to use a reason that says the account is a sock of A and tag the user page of the user as a sock of A (as shown below). However, doing so would also use the same reason and notice for the IP. Instead CUs have to use the form twice, once for the accounts and another time for the IPs:

image.png (815×958 px, 70 KB)

Event Timeline

Dreamy_Jazz renamed this task from Seperate out the reason and tagging for IPs and users in CheckUser to Make non-CUs linking users and IPs when CUs use block forms in CheckUser harder.Jul 20 2022, 9:55 PM

On enwiki, it's common for CUs to ask (typically on IRC), "Can somebody block this IP for me?" in order to obfuscate the connection between accounts and IPs blocked from the same case. Or, you just make yourself a note to execute the IP block later in the day. Either way, somebody perusing the public block logs won't see an obvious connection between the account(s) and the IP(s).

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

When you block an IP in CU, you get an option to either block it immediately, or to queue it for somebody else to block. If you select the later, it goes onto a queue which is only visible to other CUs. Then it could be part of the job of other CUs to watch that queue and perform the blocks. Or, maybe when you put the IP on the queue, you've got an option to select either "Automatically execute this block in my name after N hours" or "Queue this for quick attention by another CU". For most IP blocks, a delay of a few hours isn't going to be a problem, so I would expect setting up a delay would be the most common option.

As a related item, when CUs block IPs, they intentionally don't identify the related SPI case in the block comment. The problem with this is that another CU looking at the block log in the future will have no idea what the block was for. To solve that, I've taken to commenting CU IP blocks with an obfuscated link to the cuwiki page, i.e. The queue idea could incorporate that. When the IP block is finally executed (either by another CU or after a delay), it could automatically include a link to the CU-only-visible queue entry, which in turn would indicate what case it was related to.

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

This may work on larger projects, but...not most of them. And the difficulty of setting up such a queue is a far larger scope than this ticket, and would likely require CU discussion and significant back-end work to get something like that functional. Email/IRC is much more efficient.