Page MenuHomePhabricator

Patrollers reveal all instances of a single IP address on a page by clicking on button
Closed, DeclinedPublic5 Estimated Story Points


T326415 adds buttons next to temporary account user names for requesting IP addresses used by the temporary account. Currently one IP address is revealed per click, either the latest IP address or the IP address used for the related revision (if there is one).

However, for a better patroller experience, T325238 asks for multiple reveals with a single click:

How are IPs revealed?

Two ways:

  1. Temp user reveal: On all other pages admins and checkusers will be able to reveal all IPs for a given temp account. In other words, revealing a temp account will unveil all instances of that temp account on that page irrespective of the IP address.
  2. Pair (temp user-IP) reveal: patrollers will only be able to reveal a single "temp account - IP address" pair at a time. In other words, revealing a temp account will unveil all other temp account instances on that page that are from the same IP address.

This task is for the second one: Pair (temp user-IP) reveal.


This should be done after T327946: Admins and checkusers unveil all IPs on the page for a temp account by clicking one button, since it will likely use the same mechanism but filter out IPs before returning them

Event Timeline

Tchanders renamed this task from WIP Patrollers reveal all instances of a single IP address on a page by clicking on button to Patrollers reveal all instances of a single IP address on a page by clicking on button.Feb 10 2023, 3:40 PM
Tchanders updated the task description. (Show Details)
Tchanders set the point value for this task to 3.
Tchanders changed the point value for this task from 3 to 5.Mar 21 2023, 7:04 PM

Increasing the estimate after a discussion with @STran - we may need either a new API endpoint, or to alter an existing one a fair bit.

Blocking this on T333299: Stop API from returning excess IPs on user request, which should do some refactoring that enables this task to be done with fewer workarounds around existing architecture.

Revealing (temp user, IP) pairs is tricky, for a few different reasons.

Revealing these pairs is more complicated than revealing all the IP addresses, because we need to do the work required to find all the IP addresses, and a filtering step, to only return the data for the original IP address (and also send information about which was the originally asked-for IP address).

It is more difficult to cache these requests.

Imagine a Special:Contributions page for a temporary user. For admins and checkusers, who can see all the IP addresses at once, each "show IP" button on the page sends all the revision IDs on the page, and fetches all the relevant IPs. In other words they are all asking for the same information, so all use the same query. After the first button is clicked on, any subsequent button clicks will hit the cache from the first click.

For patrollers, clicking on one button should only reveal instances of the IP address associated with the revision from that line. This means the query needs to identify what the clicked-on revision ID was. So every button has a different query (even if they return the same results), so clicking on a different button won't hit the cache.

Persisting reveal between page loads
Admins and checkusers can store which temporary users they have revealed recently, and on a new page load can request data for those users up-front, with no need for user interaction (clicking). Patrollers must store which (temp user, IP) pairs they know about, but they can't send their known IPs to the server (at least via the URL), because this is sensitive data. However, the server can't send the client all the IPs and ask the client to filter out only the known ones, because that would mean revealing IPs that the patroller doesn't already know. This could be solved e.g. by making a POST request (like Special:CheckUser) or encrypting the IPs (like Special:Investigate), but this is awkward and also makes caching more difficult.

Could we look into doing something different for patrollers? Some suggestions (after discussing with Niharika):

  • IP reveal for patrollers works the same as for admins/checkusers
  • Patrollers can just reveal one IP at a time by clicking on each button, and the reveal is not persisted between page loads
  • Patrollers only have access to IP reveal on Special:Contributions (and it reveals all at once, and persists)
  • Something else?

Change 904749 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/CheckUser@master] Allow for overrides in the ip reveal pub sub system

Thalia has outlined the issues with this workflow and since I just pushed up a patch that implements what's requested here, I thought I'd also pop by to confirm what she's mentioned:

  1. Complexity - can be done (was done) but it added some patroller/not-checkuser specific code to the API. My implementation made it so that patrollers can no longer bulk access rev ids. This is fragile logic since there are now multiple states of permissions that might need to be managed (autoconfirmed, patroller, patroller + checkuser, etc). It could be argued that this needs to be done anyway, as no one besides checkusers should be able to bulk access rev ids no matter what.
  1. Caching/Performance - in what I implemented, the caching we're able to do is reduced since the order in which the rev ids are passed to the API now matters (the first is the 'seed' rev id used to get the ip to filter against for non-checkuser users). Each click would represent a new call since that seed will change if the patroller is clicking to reveal multiple ips. Additionally, I had to do some technical rearranging which may have re-introduced a breaking performance bug noted by @dom_walden. I personally can't reproduce it but considering it crashed Chrome for Dom, I'm calling it out as a potential blocker to the current technical implementation.

Change 904749 abandoned by STran:

[mediawiki/extensions/CheckUser@master] Allow for overrides in the ip reveal pub sub system


Product requirements have changed

Per changing product specs, patrollers no longer have a unique access state