Currently, WMF subscriptions for IP information are GeoIP2 and Spur.us's Anon+Res feed.

Potentially also via the API.

What would a reasonable rate limit look like? If we are using the same mechanism as IP Info for logging, we'd want to be careful to not flood the logs with API generated lookups. OTOH, I'm not sure if there's a strong need to log access to such an API / web UI in Special:Log.

I will ask Trust & Safety Product folks to discuss this with Legal at the office hours next week.

Btw, T357753: Build next iteration of IPoid using OpenSearch/ElasticSearch as backend might be interesting to make available with those who'd have elevated rights. With an OpenSearch/ElasticSearch backend, it's possible to easily find e.g. all IPs known to be associated with a given proxy provider.

For webui, this would be on-demand and certainly could be restricted to privileged users (suggest reusing some existing permission related to ipinfo) so I wouldn't expect the rate limit to be much of an issue, likely could use existing general webui rate limiter. API - would need more discussion, and starting with webui only would solve the initial user story of looking for a replacement for other deprecated gui tools.

See also T371627: IPInfo allows retrieving IP data for IPs that have never edited on the wiki

That other tasks suggests there are triggers that will let this work already, perhaps they can be repurposed?

In T374718#10152773, @Xaosflux wrote:

That other tasks suggests there are triggers that will let this work already, perhaps they can be repurposed?

Sure, the mechanism for implementation shouldn't be an issue; the blocker here is getting confirmation from Legal that this is OK from a data sharing, privacy, safety etc review. We should know more later this week.

xref T380221: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions (and especially T380221#10333285, where i suggest allowing queries for any IP)

@Xaosflux we (Trust and Safety Product Team) had a brief discussion with Legal last week about this.

Could you please elaborate on the use cases and benefits for you and others of this feature? Some hypothetical examples would be useful.

Permissions for such could reuse the existing permsision model for ip information tools.

Would it be possible to start with something more restrictive, like for CheckUsers only? I can see how, for example, a CheckUser might identify a problematic IP address or range and then want to look up more information about the IPs in Spur.

What are some non-CheckUser use cases of how this would be used?

Personally, if I'm considering placing a global block it would be useful to be able to query this information in one place (such as from metawiki) instead of having to go to local projects to do it, or going to external sources such as spur.us to do it. There isn't private info involved here, but putting a guardrail of administrator could be OK (as administrator is the level that would be reacting and placing blocks).

In T374718#10354951, @Xaosflux wrote:

Personally, if I'm considering placing a global block it would be useful to be able to query this information in one place (such as from metawiki) instead of having to go to local projects to do it, or going to external sources such as spur.us to do it. There isn't private info involved here, but putting a guardrail of administrator could be OK (as administrator is the level that would be reacting and placing blocks).

Got it, thanks. So, this is then similar to what was proposed in FY2024-25 WE4.2.9 Contextual information on Special:Block and T369643: [EPIC] Provide contextual information about IP addresses on Special:Block. One of the ideas there was to load IPInfo and gather data we have from Spur/MaxMind/etc on Special:Block (and we could add global block) for users who have permissions to submit the form.

Sort of, however this is to allow on-demand loading of information we may not have already loaded anywhere. Perhaps 10.1.1.2 contributed somewhere and we have info on that, but we want to get the info for 10.1.1.0/24 or 10.1.1.2 -- that isn't being captured today because it hasn't been seen yet, even though an action such as a block may be more appropriate on the range. The workflow on that is to go find local projects where this may have been gathered, and or go back to leaving our sites and using external services directly.

In T374718#10355122, @Xaosflux wrote:

Sort of, however this is to allow on-demand loading of information we may not have already loaded anywhere. Perhaps 10.1.1.2 contributed somewhere and we have info on that, but we want to get the info for 10.1.1.0/24 or 10.1.1.2 -- that isn't being captured today because it hasn't been seen yet, even though an action such as a block may be more appropriate on the range. The workflow on that is to go find local projects where this may have been gathered, and or go back to leaving our sites and using external services directly.

Ack, thanks for the clarification.

I've tentatively tagged WE4.2 as this work would potentially fit under that initiative.

This would be useful in the following cases:

• querying information for historical data from notes at eg. checkuser wiki, where we no longer have the information in our main database (so we cannot verify the queried IP was abusive in the past),
• preparing for making blocks (eg. range blocks, as @Xaosflux mentions),
• verifying whether a block based on the No open proxies policy is legitimate,
• etc

It should be fine to require a reason for the lookup, where the authorised user would clarify why the IP is necessary. This can be used to verify the data is not queried without the need for it.

We discussed this task in the TSP-Legal office hours and I said it was ok to proceed for privileged users (admins, CUs, etc.). Noting here for documentation.

Moving to our generic sprint board, as a reminder to schedule this work.

For an initial version, would it work to have an API endpoint that returns the JSON we get from IPoid service? That would be the quickest way to achieve the goal in this task.

@MMoss_WMF Do we need to require a reason when inputting the IP or range, as mentioned in T374718#10489092?

@Niharika this task proposes to use the existing IPInfo permissions to allow this access, while @MMoss_WMF's comment says it's OK for privileged users. Is it OK to use IPInfo permissions for gating access? If we want to restrict this further, then we need a list of user groups that should have access.

What type of logging do we need? Should we log all usages of the endpoint?

@MMoss_WMF Do we need to require a reason when inputting the IP or range, as mentioned in T374718#10489092?

Following-up from an internal discussion with Legal it sounds like we need to have a reason field for this lookup to ensure we are complying with Spur and MaxMind's license restrictions.

@Niharika this task proposes to use the existing IPInfo permissions to allow this access, while @MMoss_WMF's comment says it's OK for privileged users. Is it OK to use IPInfo permissions for gating access? If we want to restrict this further, then we need a list of user groups that should have access.

IP Info permissions are possibly going to change. We are talking about them actively in the IP reveal thresholds conversations and in T388320. I would recommend we hold off on deciding access until the dust has settled around that conversation.

IP Info and IP reveal are big differences. the IP Info isn't related to temporary accounts. Getting this working, even if it starts with just 'sysop' as a role shouldn't be held up by that, as most of the work is getting it to work - permissions can be revisited after.

Adding relevant comments from T380221: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions:

In T380221#10872233, @Izno wrote:

The user story:

1. I check a named user at Special:Checkuser.
2. A list of IPs display. They have contributions links.
3. One of the contributions links leads to an IP with contributions directly from that IP.
   1. I use IP info to get a quick view of whether this is a good or bad IP.
   2. Fin.
4. One of the contributions links leads to an IP without contributions directly from that IP.
   1. I get a "no contributions from this IP".
   2. Sad.

I routinely judge whether getting the IP actions are appropriate before continuing, but an alternative sequence might be:

1. I check a named user at Special:Checkuser.
2. I check the users for one of the IPs (for brevity, the IP itself doesn't have contributions). Results display.
3. I navigate to the IP's contribs.
   1. I get a "no contributions from this IP".
   2. Sad.

There is a third story:

1. I review the CU log for arbitrary IP or user.
2. I click on contributions for the IP.
   1. Familiar sobbing here.

In T380221#10884873, @Izno wrote:

In T380221#10883327, @Niharika wrote:

@Izno Thanks for elaborating on that. Does T374718: Allow Special:IPInfo to return IP information of arbitrary addresses for users with the correct permissions cover what you are suggesting?

In the same way as I commented on at T380221#10334217, sure. It would be a pain if it could not be prefilled as with e.g. the links from IP contribs in Special:CU pointing me straight to such a thing, or having this not integrated with Special:Contribs, since I want to minimize the number of screens I need to open from Special:CU (CheckUsers regularly have 10s of tabs open for a single investigation but also I want to get my info in one place, not N). As in the original story, today I need to open a couple tabs at external websites (a couple on toolforge, a couple not) to get details on an IP identified in a check.

Change #1240971 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Fix tunnelOperators data key casing

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

Change #1240972 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Refactor to extract reusable helpers

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

Change #1240973 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Add arbitrary IP address lookup

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

Change #1240971 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Fix tunnelOperators data key casing

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

Change #1240972 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Refactor to extract reusable helpers

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

Change #1240973 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] SpecialIPInfo: Add arbitrary IP address lookup

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

Change #1242424 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] IPInfo: Grant ipinfo-view-arbitrary-ip to checkuser group

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

Change #1242424 merged by jenkins-bot:

[operations/mediawiki-config@master] IPInfo: Grant ipinfo-view-arbitrary-ip to checkuser group

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

Mentioned in SAL (#wikimedia-operations) [2026-02-24T08:58:58Z] <kharlan@deploy2002> Started scap sync-world: Backport for [[gerrit:1242424|IPInfo: Grant ipinfo-view-arbitrary-ip to checkuser group (T374718)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-24T09:01:12Z] <kharlan@deploy2002> kharlan: Backport for [[gerrit:1242424|IPInfo: Grant ipinfo-view-arbitrary-ip to checkuser group (T374718)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-24T09:08:27Z] <kharlan@deploy2002> Finished scap sync-world: Backport for [[gerrit:1242424|IPInfo: Grant ipinfo-view-arbitrary-ip to checkuser group (T374718)]] (duration: 09m 29s)

• There should be a new permission to allow viewing IPInfo for IPs that aren't associated with on-wiki events.

On my local wiki, I tried accessing Special:IPInfo as various users. I didn't find a case where a user without ipinfo-view-arbitrary-ip could see IP info for an IP.

I also notice that the amount of data you see depends on whether you have the ipinfo-basic or ipinfo-full right. For example, the former do not see Location, ASN or Organisation.

• Users should be able to easily view and copy the JSON output from the IPInfo backend

We don't appear to have made any specific accommodation for easy copying of data. Copying and pasting the table into VE seemed to work OK.

The table we are using to show the information does not seem like a component we use elsewhere. I am not sure why we decided on it specifically.

I didn't do much in the way of accessibility or i18n testing.

• A rate limit needs to be enforced due to licensing terms with Spur. Initially we can set this at 100 lookups per user per day and adjust as needed.

The rate limit appeared to work. However, I notice that, at least on enwiki, both the sysop and stewards groups have the noratelimit rights, so the rate limit will not be applied to them.

• No "reason" field needs to be provided for lookups, as long as a rate limit is enforced

I could not find access being logged anywhere.

Change #1247057 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] IPInfo: Set log level to "info"

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

Change #1247057 merged by jenkins-bot:

[operations/mediawiki-config@master] IPInfo: Set log level to "info"

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

Mentioned in SAL (#wikimedia-operations) [2026-03-02T14:32:50Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1247057|IPInfo: Set log level to "info" (T374718)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-02T14:34:48Z] <lucaswerkmeister-wmde@deploy2002> kharlan, lucaswerkmeister-wmde: Backport for [[gerrit:1247057|IPInfo: Set log level to "info" (T374718)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-03-02T14:40:51Z] <lucaswerkmeister-wmde@deploy2002> Finished scap sync-world: Backport for [[gerrit:1247057|IPInfo: Set log level to "info" (T374718)]] (duration: 08m 01s)

I've updated the global group permissions of stewards, global sysops, global temporary account IP viewers (=CU & OS), ombuds, U4C and staff to include ipinfo-view-arbitrary-ip, given that the right has been added to the local groups sysop, steward and checkuser.
https://meta.wikimedia.org/w/index.php?title=Special:Log/Johannnes89&type=&user=Johannnes89&dir=prev&offset=20260308172509%7C65114615&limit=6

In T374718#11688670, @Johannnes89 wrote:

I've updated the global group permissions of stewards, global sysops, global temporary account IP viewers (=CU & OS), ombuds, U4C and staff to include ipinfo-view-arbitrary-ip, given that the right has been added to the local groups sysop, steward and checkuser.
https://meta.wikimedia.org/w/index.php?title=Special:Log/Johannnes89&type=&user=Johannnes89&dir=prev&offset=20260308172509%7C65114615&limit=6

Thanks for doing that, and for letting us know

The extension shouldn't be adding ipinfo-view-arbitrary-ip to the local steward user group. That should be left to the global group.

Why is the extension granting sysop ipinfo-view-arbitrary-ip but not any of the other available rights?

In T374718#11688835, @JJMC89 wrote:

The extension shouldn't be adding ipinfo-view-arbitrary-ip to the local steward user group. That should be left to the global group.

Ack. Should we undo that code change, then?

Why is the extension granting sysop ipinfo-view-arbitrary-ip but not any of the other available rights?

That seemed out of scope for this particular change.

In T374718#11688880, @kostajh wrote:

In T374718#11688835, @JJMC89 wrote:

The extension shouldn't be adding ipinfo-view-arbitrary-ip to the local steward user group. That should be left to the global group.

Ack. Should we undo that code change, then?

Yes. MW core (and this extension) does not have such a user group defined.

Change #1249358 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/IPInfo@master] IPInfo: Remove steward from GroupPermissions

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

Change #1249358 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] IPInfo: Remove steward from GroupPermissions

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

I think something that ought to be clarified here is how flexible the gating currently is. Is this new ipinfo-view-arbitrary-ip right able to be assigned to other privileged groups that a local community might define, or is it more of a hard-set of admins and functionaries only? Asked this question more informally and was told it might be best to toss this in as a comment.

In T374718#11700683, @EggRoll97 wrote:

I think something that ought to be clarified here is how flexible the gating currently is. Is this new ipinfo-view-arbitrary-ip right able to be assigned to other privileged groups that a local community might define, or is it more of a hard-set of admins and functionaries only? Asked this question more informally and was told it might be best to toss this in as a comment.

We have approval only for sysop, checkuser, and steward. Which groups do you have in mind?

I was about to ask a similar question. I've assigned the permissions to those global groups mentioned in https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy#Global_access which are (at least) sysop- / CU-level, which leaves global rollback and abuse filter helper/maintainer . Not sure if there's a strong need for them to check arbitrary IP addresses but it might be useful?

Unless I'm woefully missing something, ipinfo-view-arbitrary-ip has no specific user privacy issues - it is allowing the use of this tool to query our external service provider - and doesn't include wikimedia-specific information in the output. We do appear to be limited with the provider as to the volume of requests that we may generate, necessitating not having this be massively available.

Tool output:
{F72815440}

In T374718#11700758, @kostajh wrote:

In T374718#11700683, @EggRoll97 wrote:

I think something that ought to be clarified here is how flexible the gating currently is. Is this new ipinfo-view-arbitrary-ip right able to be assigned to other privileged groups that a local community might define, or is it more of a hard-set of admins and functionaries only? Asked this question more informally and was told it might be best to toss this in as a comment.

We have approval only for sysop, checkuser, and steward. Which groups do you have in mind?

I echo what Johannnes said about global rollback and abuse filter helper/maintainer. Those two groups have been assigned the admin-level rights before, see for example ipinfo-view-full and the autoreveal right. I also don't see a privacy issue here so much as a licensing one, and in that case, the number of distinct people with GR/GAFH/GAFM combined is still less than the amount of those with global TAIV (every CU/OS on any project), so I'm not sure it would really be an issue here.