For patrollers, this is tricky. We're meant to pre-reveal any temp user / IP pairs that they have already seen. Here's an example of why that's tricky:

1. patroller visits log page and clicks "reveal IP" for temp user *1234
2. the most recent IP is revealed - ::1
3. temp user *1234 now makes another edit to SomeArticle using a new IP address ::2
4. patroller visits the history page for SomeArticle
5. patroller knows ::1, but:

• can't send ::1 in a URL (same reason why we can't use GET on Special:CheckUser)
• can't send a revision ID, because log didn't have a revision ID
• can't ask for most recent IP because ::1 is no longer the most recent
• API can't send all the IP addresses, because patroller shouldn't be able to get them all

See also: T327947#8736059

Change 904197 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CheckUser@master] WIP Rough sketch of persisting IP reveal for trusted users

https://gerrit.wikimedia.org/r/904197

In T333367#8735706, @Tchanders wrote:

• can't send a revision ID, because log didn't have a revision ID

After T324907 it should be possible to send a log ID, but the point still stands for situations such as T331021.

@Niharika There's a discussion happening on the task that's raising some product questions. Broadly, there's a problem related to logging a user's activity when they simply visit a page, as opposed to clicking on a button.

Summary of the patroller workflow

Is this all correct?

1. Show a button to look up a temp user's IPs (if they haven't been looked up recently - see below)
2. If the patroller clicks it, log that they looked up that information
3. If the patroller navigates to another page that lists the same temp user, show the IPs automatically, so the user doesn't have to click again (this task)
4. If we show the data automatically, don't log that the patroller looked up this information, because they may not have meant to perform a lookup

Do we need to log the page?

(3) and (4) together mean that we'll only ever log the page where they clicked the button, and not subsequent pages that they look at during their investigation. This seems odd and I just wanted to check whether it's correct.

If we need to log subsequent pages where a patroller saw a temporary user's IP address, then we'd need to add a log entry whenever they visited a page where the IP address was automatically visible due to being persisted. But then a patroller could unintentionally trigger a log of their activity just by browsing around our site, which seems concerning from a privacy perspective.

If it's not important to log subsequent pages, then do we need to log the first page (when they clicked the button)? The first page could be something as nonspecific as Special:BlockList, Special:Contributions, etc, not necessarily an article, and they could visit many more relevant pages subsequently.

Possible approaches

Would either of these make sense?

• Log every page where a patroller sees IP addresses, but don't persist reveal across pages. That means they'll need to click more, but they'll only be logged if they perform an action, not just by visiting a page. Related task: T325658
• Persist revealed IP addresses across pages, and don't log when a patroller visits a page with the IP addresses already revealed. Since we're not logging most of the pages, don't log the first one either. (If we don't really need that information then are we collecting more data than necessary by logging it the first time?)

Based on {T325658#8805061}, we can move forward with this and treat the cache mismatch as an edge case. I've captured that work in T335404: Make sure IP masking's local cache expiry doesn't outlast server's expiry

Testing notes:

• This can be tested locally
• After clicking on a "Show IP" button, the IP address should stay revealed for that temp user on any page where those buttons appear (except Special:Block)
• The amount of time the IPs stay revealed for is set by the config wgCheckUserTemporaryAccountMaxAge, in seconds
• After that time has elapsed, the buttons should reappear, instead of the revealed IPs

Change 904197 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Persist IP reveal for trusted users

https://gerrit.wikimedia.org/r/904197

@STran & @Tchanders I created ticket T336307: IP Masking: Refresh brings it back to Show IP even when $wgCheckUserTemporaryAccountMaxAge is configured Locally regarding the Refresh button issue.

Also, no matter what time I put in the config wgCheckUserTemporaryAccountMaxAge, if I click on reveal on a temp user (ex. *Unregistered 26) in the History page, it shows the IP address. If I click on the temp user (ex. *Unregistered 26) right away, it brings me to Special:Contributions with the revealed IP address still. Now if I wait 10 seconds after revealing the IP address in the History and then click on the temp user, I now get a Show IP on the Special:Contributions page. It doesn't matter if I configure it for 10 or 200 seconds.

@GMikesell-WMF Could this mean that the problem is that persist-reveal isn't working on the history page, rather than not working on refresh?

@Tchanders Yeah that's what it seems like to me since it doesn't matter what time I put in the config.

@STran & @Tchanders I updated T336307: IP Masking: Refresh brings it back to Show IP even when $wgCheckUserTemporaryAccountMaxAge is configured Locally and will be moving this ticket to Done. Thanks!