Page MenuHomePhabricator

Investigate: Adding Reveal IP button to Special:GlobalContributions
Closed, ResolvedPublic

Description

Motivation

When doing xwiki patrolling, one needs to go through the IP to see what other Temporary accounts are active on the same IP(s). Special:GlobalContributions doesn't currently include the Show IP button, which means a xwiki patroller needs to go through all the wikis and do Show IP there.
Johannnes89 has described a user story for this work in T396919#10975393

Open questions
  • Assuming we want to add support for 'Show IP' and 'Auto reveal' to results on Special:GlobalContributions...
    • What are the technical limitations for adding support for these features on this page?
    • What are the performance concerns for adding support for these features on this page?
    • Is it feasible for temp account-IPs revealed on this page persist as revealed across other wikis?
    • Is it feasible to persist temp accounts-IPs revealed on other pages to appear as revealed on this page?
Acceptance criteria
  • Answer the above open questions to help identify product direction
  • Outline a technical approach for this work

Event Timeline

Some thoughts about this:

  • It would be needed for temporary account targets, similarly to Special:Contributions:

image.png (968×422 px, 96 KB)

  • Clicking on a button would need to make a request to a the correct wiki (currently the the local wiki is assumed)
  • If this is more expensive than requests to the local wiki, then we may not want auto-reveal to work on Special:GlobalContributions
  • If an IP is revealed for a temporary user for a revision made at an external wiki, the user would not be automatically revealed on the other wiki (because the revealed status is stored in localStorage, which is not shared between sites

If the Show IP buttons do work differently on Special:GlobalContrbutions (e.g. no auto-reveal, no persist reveal), how should we communicate this to the user?

  • If this is more expensive than requests to the local wiki, then we may not want auto-reveal to work on Special:GlobalContributions

That would defeat the purpose of this task (at least partially). I've described in T396919#10975393 how tiresome xwiki patrolling of temp accounts using multiple IPs currently is. Showing IP reveal on Special:GlobalContributions but requiring stewards to potentially click the button dozens of times (if a temp account made a lot of edits across many different projects with different IPs) wouldn't be much of an improvement.

If this is more expensive than requests to the local wiki, then we may not want auto-reveal to work on Special:GlobalContributions

Assuming that we can work out the communication aspect, what if we did an in-between: instead of auto-reveal revealing all IPs on the page, we did it in smaller batches which keeps the performance manageable?

Niharika triaged this task as Medium priority.Nov 13 2025, 9:41 AM
Niharika updated the task description. (Show Details)
Niharika renamed this task from Add Reveal IP button to Special:GlobalContributions to Investigate: Adding Reveal IP button to Special:GlobalContributions.Nov 20 2025, 12:25 PM
Niharika updated the task description. (Show Details)

On average, a temporary account exists on 3.06 wikis (there are 1.415M global temp. accounts and 4.330M local temp. accounts). 95% of temporary accounts are attached to 4 wikis or less, which in practice means we'll usually need to perform up to 2 requests to reveal the IPs (no account is excepted to have edits on loginwiki and very few edited on metawiki).

A similar anaylsis could be done for IPs – 96.8% of IPs, from which anonymous edits have been done, edited just a single wiki, and 2.6% two wikis. While the distribution may differ for IP ranges, I don't expect that typical usage of GlobalContributions will require many requests to reveal the IPs.

Therefore, I think that we can support both the "manual reveal" and auto reveal mode. For the latter, the batches could be ordered by the number of actions from a given wiki, so that users won't have to wait for a long time to see majority of the IPs, even if more requests are needed. If we're still concerned about the number of requests, maybe a cap on number of automatic requests could be implemented (e.g., auto-reveal shows IP from up to 10 wikis with the most activity)?

What are the technical limitations for adding support for these features on this page?

  • I think this is answered through the other questions...
  • Overall though, the IP reveal buttons would need to know which wiki to query, and perform a batch query for all the buttons for that wiki on the page.

What are the performance concerns for adding support for these features on this page?

  • Permissions lookups - not a concern as these are already done when looking up the revisions.
  • API calls to external wikis - we should limit the number of these that are spawned, as there could in theory be one per revision, i.e. hundreds. T404718#11436237 finds that it should be rare to have more than a few, so adding a limit should not usually impact user experience.

Is it feasible for temp account-IPs revealed on this page persist as revealed across other wikis?

  • Persisting revealed IPs is for manual reveal only, and this would not happen across wikis by default, since it is stored in localStorage, which is partitioned per origin.
  • However, for auto-reveal, the on/off state is a global preference which is remembered between sites, so they would stay revealed if auto-reveal is on.

Is it feasible to persist temp accounts-IPs revealed on other pages to appear as revealed on this page?

  • On the local wiki yes, this should happen by default if IP reveal buttons were just added to GlobalContributions with no extra support.

Can we also accomplish T410511: Support cross-wiki IP reveals from the global AbuseLog while we work on this? Or is that a very different set of work?

We should track it in that task - there is overlap, but it will also need a separate fix in AbuseFilter.

  • Outline a technical approach for this work

Making external API calls:

  • We can update performBatchRevealRequestInternal to take a URL to an external wiki, and use mw.ForeignApi is this is provided
  • Since we batch the requests anyway, we'd make one request per wiki

Getting the external wiki URL:

  • If we did this in JS, we'd need to do something like processing the string from the link to the external site's main page (present in the revision line), but this assumes the API URL is formatted the same as the page URL
  • It seems safer to get it in PHP using Site::getPath(MediaWikiSite::PATH_FILE) and have GlobalContributionsPager add this as a data attribute to the temp user links
  • Either way, we'd substitute rest.php and api.php on the end

Multi-reveal:

  • This is the feature where clicking on one temp user link reveals all the IPs for that temp user
  • Each button stores the revision IDs for all the other buttons for the same user. These would need to be only for other buttons of the same user AND the same wiki

Pre-reveal:

  • This is the feature where a temp user, once revealed, stays revealed as the performer navigates between pages. (Only used when the performer is NOT using auto-reveal.)
  • Each revealed user is flagged as revealed by an object stored in localStorage
  • We could store a separate object for each user/wiki combination...
  • However, if navigating to another wiki, the user would not stay revealed, as there would be a separate localStorage store for the other wiki
  • I'd recommend keeping pre-reveal scoped only to the local wiki for now

Auto-reveal:

  • This is the feature where all Show IP buttons are revealed, for any temp user, if the performer has this mode switched on
  • As above, we'd need to partition the request by wiki. Instead of just making one request, we'd need to find all the wikis and make a request for each

Revision IDs: