In T380221#10333285, @Urbanecm wrote:

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited. This might seem unnecessary, but IPs often make an action that is rejected prior to saving (by an AbuseFilter, spam filter or the like). When looking at those events, IP Info data can be useful, but cannot be generated natively. This is even more visible in the Temporary accounts world – there is always some reason for a Temporary account creation, and that reason always is "the user attempted to make a write action". Sometimes, that attempt is not successful, but that can be a valid reason to want to see IP Info data. Given this and the other is very similar to each other, I'm not filling a separate task for "allow data to be queried for any actor", but I do see a lot of usecases where that would be helpful.

I would agree with this broader request as well as this ticket.

I think it makes sense to scale what IP info provides relative to the permissions held for these qualities.

The other thing that might be valuable is to add an integration somewhere in the Special:CU interface directly for actions which aren't visible on Special:Contribs or Special:Log/filtered, namely logins/outs.

I think this is a duplicate of T374718

In T380221#10333824, @Xaosflux wrote:

I think this is a duplicate of T374718

I don't think so. That task asks for a new Special:IPInfo special page, which would run queries on any IP. This task asks for the (already existing) popup in Special:Contributions to work irrespective of edits made. I agree both seek to solve similar problems, but in very different ways. I could see either one or both getting implemented.

Thanks, looks like a lot of back-end may be usable for both if someone takes this up!

I think it just needed a title change, but wasn't sure since the original filing wasn't totally clear on the distinction.

I think having a form as in the other task is about as valuable as auto-displaying. There may be a desire to keep external data draw down, though I'd guess that's a wash between the two options ("query anything" vice casual use of IP info even if you don't need/want that part of the info).

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited.

@Niharika Do you know if there was a legal or contractual restriction with being allowed to show data for IPs that hadn't necessarily used our site?

If so, maybe we could check if the IP either exists in the CheckUser or AbuseFilter tables, or has contributions. That would mean we couldn't look up data for IPs who had contributed more than 3 months ago, unless they have contributions. Would that be acceptable?

In T380221#10335445, @Tchanders wrote:

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited.

@Niharika Do you know if there was a legal or contractual restriction with being allowed to show data for IPs that hadn't necessarily used our site?

If so, maybe we could check if the IP either exists in the CheckUser or AbuseFilter tables, or has contributions. That would mean we couldn't look up data for IPs who had contributed more than 3 months ago, unless they have contributions. Would that be acceptable?

I'm not sure what Spur's contract and ToS allows. I'll bring this to Legal's attention. In the meantime I would recommend removing this task from the current sprint and placing it in the backlog until we have clarity.

In T380221#10336709, @Niharika wrote:

In T380221#10335445, @Tchanders wrote:

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited.

@Niharika Do you know if there was a legal or contractual restriction with being allowed to show data for IPs that hadn't necessarily used our site?

If so, maybe we could check if the IP either exists in the CheckUser or AbuseFilter tables, or has contributions. That would mean we couldn't look up data for IPs who had contributed more than 3 months ago, unless they have contributions. Would that be acceptable?

I'm not sure what Spur's contract and ToS allows. I'll bring this to Legal's attention. In the meantime I would recommend removing this task from the current sprint and placing it in the backlog until we have clarity.

Just to note that this isn't in the current sprint, but is in the next sprint board.

Speaking with my volunteer CU hat on, I would personally advocate for this to be got to quickly as the Bullseye tool has stopped working and is making it more difficult for users of the CheckUser tools to see IP data on IPs used by only registered accounts.

If so, maybe we could check if the IP either exists in the CheckUser or AbuseFilter tables, or has contributions. That would mean we couldn't look up data for IPs who had contributed more than 3 months ago, unless they have contributions. Would that be acceptable?

@Niharika I believe this approach needn't depend on legal, as these users would have made contributions (just not non-deleted revisions). Could we go ahead with this?

In T380221#10337752, @Tchanders wrote:

If so, maybe we could check if the IP either exists in the CheckUser or AbuseFilter tables, or has contributions. That would mean we couldn't look up data for IPs who had contributed more than 3 months ago, unless they have contributions. Would that be acceptable?

@Niharika I believe this approach needn't depend on legal, as these users would have made contributions (just not non-deleted revisions). Could we go ahead with this?

Yes, I think this piece is fine. As long as we have the IP address we want to lookup we should be able to do that. We can go ahead with this. Thanks.

I will follow-up with Legal about the request to look up IP addresses we don't have recorded on our tables.

LGTM based on our conversation during the weekly TSP/Legal.
Will continue to discuss T374718 separately.

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

[mediawiki/extensions/IPInfo@master] [WIP] Add CU/AF-lookup endpoint for accounts with no revisions

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

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

[mediawiki/extensions/IPInfo@master] [WIP] Support IP lookups for IPs known to CheckUser/AbuseFilter

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

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

[mediawiki/extensions/IPInfo@master] Require ExtensionRegistry in handlers

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

Change #1117540 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Require ExtensionRegistry in rest handlers

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

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

[mediawiki/extensions/IPInfo@master] Always look up more recent rows in TempUserIPLookup->getMostRecentAddress queries

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

Change #1108439 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Add CheckUser/AbuseFilter-lookup endpoint for temp accounts with no revisions

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

Change #1114010 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Support IP lookups for IPs only known to CheckUser/AbuseFilter

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

This looks to be live now (at least for revisions known only to CUs after a check), but it seems to be much slower to display the data than when revisions are available for the IP itself.

I see on Special:Contributions if there are no revisions and on Special:DeletedContributions if there are no deleted revisions, IPInfo makes an API call to /norevision/<temp username>.

This performs a database query against the cu_changes, cu_log_event, cu_private_event and abuse_filter_log tables to get the most recent IP address. In the case where CheckUser is not installed but AbuseFilter is, it will just make a request to abuse_filter_log.

It does not appear to require that the user has CheckUser rights or the right to view AbuseFilter protected variables. I guess this is consistent with other IPInfo API endpoints which don't require CheckUser rights even though they access the CheckUser tables.

I notice that the request to the abuse_filter_log is slower than the other requests: about 300ms compared to 0.2ms (on my local docker). I guess this will be addressed in T390716.

Test environment: local docker IP Info 0.0.0 (c94f1ab) 12:21, 12 May 2025.

I can observe at least one IPv6 address which has 14 hits in the CU database which displays

Is "to get the most recent IP address" the problem as noted by Tchanders just above? In this case, the address is not the most recent, and if that limitation can't be removed we're still going to end up using external tools because IPv6 rotates practically daily even for the sane implementations......

Nope, it's not that, the most recent address for the user of interest also returns the red banner.

@Izno Is the screenshot from an infobox on a Special:Contributions page of one of the IP addresses?

I believe the current behaviour is that:

• the infobox on a temporary account's Special Contributions will display IP info for the last IP address used by the temporary account, even with no revisions
• the infobox on Special:Contributions for an IP address with no contributions will only display IP info if the anonymous IP user did something that was logged in the tables, not if a temporary account using that IP did

For a temporary account with no contributions, perhaps we should add the information about all their known IP addresses to Special:IPInfo

I'm guessing that Izno is looking at enwiki, so temporary accounts wouldn't be relevant here.

Indeed enwiki.

Is the screenshot from an infobox on a Special:Contributions page of one of the IP addresses?

Yes.

This query used to sometimes resolve I think? before T392976: CVE-2025-53481: Denial of service vector on ipinfo/v0/norevision happened. So I'd guess that was the cause, if the behavior has changed.

Are you looking up the IP of a registered user? As in, a registered user committed an action, CU logged the IP, and you searched for the IP via Special:Contributions? I don't think we've ever supported lookups for those.

This query used to sometimes resolve I think?

Would it be possible to provide a log id or revision id? The norevision endpoint was introduced as a fallback if there were no revisions found for the user and only supports IPs and temporary accounts.

@Dreamy_Jazz:
https://www.mediawiki.org/wiki/Extension:IPInfo says:

Information buttons are added next to IP addresses on history pages, the Special:Log page, the Special:RecentChanges page and the Special:Watchlist page.

I am not a temporary account IP viewer in it.wikipedia.org. But I activated IP Info in my preferences in it.wikipedia.org. And:
I see the information button, next to each IP address, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each IP address, in Special:AbuseLog.

I am not a temporary account IP viewer in test.wikipedia.org. But I activated IP Info in my preferences in test.wikipedia.org. And:
I see the information button, next to each temporary account, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each temporary account, in Special:AbuseLog.

Is it the expected behavior?

@NicoScribe It is correct that IPInfo does not display on Special:AbuseLog, and does display on those other pages listed.

In T380221#10859280, @NicoScribe wrote:

I am not a temporary account IP viewer in it.wikipedia.org. But I activated IP Info in my preferences in it.wikipedia.org. And:
I see the information button, next to each IP address, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each IP address, in Special:AbuseLog.

This is expected behaviour.

I am not a temporary account IP viewer in test.wikipedia.org. But I activated IP Info in my preferences in test.wikipedia.org. And:
I see the information button, next to each temporary account, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each temporary account, in Special:AbuseLog.

This should no longer be the case (as of very recently). It should no longer be possible to see IPInfo in test.wikipedia.org without a privileged account, but it should still be possible to see it on Italian Wikipedia. This is because wikis with temporary accounts enabled no longer allow users without privileges to see IPInfo, but wikis without temporary accounts are unchanged.

In T380221#10870096, @Tchanders wrote:

@NicoScribe It is correct that IPInfo does not display on Special:AbuseLog, and does display on those other pages listed.

In T380221#10859280, @NicoScribe wrote:

I am not a temporary account IP viewer in it.wikipedia.org. But I activated IP Info in my preferences in it.wikipedia.org. And:
I see the information button, next to each IP address, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each IP address, in Special:AbuseLog.

This is expected behaviour.

I am not a temporary account IP viewer in test.wikipedia.org. But I activated IP Info in my preferences in test.wikipedia.org. And:
I see the information button, next to each temporary account, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each temporary account, in Special:AbuseLog.

This should no longer be the case (as of very recently). It should no longer be possible to see IPInfo in test.wikipedia.org without a privileged account, but it should still be possible to see it on Italian Wikipedia. This is because wikis with temporary accounts enabled no longer allow users without privileges to see IPInfo, but wikis without temporary accounts are unchanged.

I should add, if there are any concerns with this behaviour, or requests that IPInfo should be visible from more places, let's discuss with @Niharika, the product manager. These decisions were made a while ago so could be revisited again. Perhaps we could discuss specific requests on a new task?

Thank you @Tchanders.
Well, this is not a big concern, this is a question, out of curiosity:
This task is called: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions
...and the task is closed. So why there is no information button, next to each IP address, in Special:AbuseLog?

I will be embarrassed if I open a new task and my questions are stupid. I have other questions about temporary accounts, out of curiosity: technical questions, policy questions... But I don't know the right place for them.
*@Niharika, I could use [[mw:User talk:NKohli (WMF)]] or [[m:User talk:NKohli (WMF)]] for all my questions?
*or I could use [[mw:Talk:Trust and Safety Product/Temporary Accounts]] for all my questions?
*or I could use [[mw:Talk:Trust and Safety Product/IP Info]] for my IP Info questions?
*and I could use [[foundation:Policy talk:Wikimedia Access to Temporary Account IP Addresses Policy]] for my policy questions?

In T380221#10871082, @NicoScribe wrote:

Thank you @Tchanders.
Well, this is not a big concern, this is a question, out of curiosity:
This task is called: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions
...and the task is closed. So why there is no information button, next to each IP address, in Special:AbuseLog?

Ah, I can see how that looks confusing.

It was previously the case that IP info could only be viewed if the IP address had made a revision (that had not been deleted), whereas users were interested in seeing IP info for users who had performed logged actions, not just revisions. The CheckUser and AbuseFilter tables are where we store information about these actions.

So this task is about which IPs to show information for, rather than where to show the information. It could be helpful to review where the information is shown separately though.

In T380221#10871082, @NicoScribe wrote:

I will be embarrassed if I open a new task and my questions are stupid.

Hey, your question is not only yours, but quite likely, someone else's honest learning! Maybe it will end up in the FAQ? There are no stupid questions. 🤗

I have other questions about temporary accounts, out of curiosity: technical questions, policy questions... But I don't know the right place for them.
*Niharika, I could use [[mw:User talk:NKohli (WMF)]] or [[m:User talk:NKohli (WMF)]] for all my questions?
*or I could use [[mw:Talk:Trust and Safety Product/Temporary Accounts]] for all my questions?
*or I could use [[mw:Talk:Trust and Safety Product/IP Info]] for my IP Info questions?
*and I could use [[foundation:Policy talk:Wikimedia Access to Temporary Account IP Addresses Policy]] for my policy questions?

I think it'd be best if you posted these questions on /Temporary Accounts - this is the central/main talk page about the project. Even if some questions are specifically about IP Info, let's assume that on the main talk page, anything works. And it's generally better to ask on a project talk page than a single person's talk page.

(I've turned the last talk page you listed into a redirect, to minimize potential confusion. Perhaps I should do the same with /IP Info ..)

In T380221#10825356, @STran wrote:

Are you looking up the IP of a registered user? As in, a registered user committed an action, CU logged the IP, and you searched for the IP via Special:Contributions? I don't think we've ever supported lookups for those.

Yes.

The point of this task in my opinion is to support that lookup.

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.

Would it be possible to provide a log id or revision id? The norevision endpoint was introduced as a fallback if there were no revisions found for the user and only supports IPs and temporary accounts.

I check a lot of people, so no, I couldn't provide an arbitrary ID (even a week ago when the query was posed). It's possible I may have been imagining this working. I know it doesn't work today. Either way, I don't think this task is done and supported and ready to go as-is.

(These use cases were incidentally half the point of the "authorized users" in the context of the task name. People viewing IP info should have access to the info they're 'cleared' for. A CU should be able to get the info in sequence 1 step 4 without leaking to someone without CU that a specific IP has been used.)

It may be infeasible for whatever reason to support all of the above stories, but my understanding is that every IP that hits a submit button is available (maybe not *the* table it needs to be?) so even the first story should be feasible.

Thanks for elaborating, @Izno.

@Niharika Do we need to have a conversation with Legal about this?

@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?
That task is on hold at the moment. I'll clarify the requirements with Legal and then we can schedule it for engineering work.

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.

@Izno Thanks. I think what you are suggesting should be feasible. The original goal for this task was around unregistered editors (temporary accounts). We can tackle what you suggest in T374718: Allow Special:IPInfo to return IP information of arbitrary addresses for users with the correct permissions. I added your comments there to make sure we can take those into account when we kick off that work.

Change #1120559 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Always look up more recent rows in TempUserIPLookup->getMostRecentAddress queries

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

My usual workflow is to click the IP link in Special:CheckUser when I want more info. As things stand now, when that fails with the dreaded "IP information for this address cannot be retrieved since no contributions have been made from it" message, then I need to manually flip over the Bullseye to get the information I seek, which is silly and inefficient.

If there are performance, legal, or vendor considerations which require limiting access in the general TAIV case, then switching based on whether the user is a CU (or perhaps other advanced rights?) would allow both use cases through the same interface and presumably add only a marginal increment to the amount of traffic.

Bullseye was a great tool in its day since it filled a pressing current need. IP Info now fills almost the same need, and if it could just be tweaked in this small way, there would be no need to continue to maintain Bullseye. Not that it's really being maintained any more these days anyway. And having an unmaintained piece of software which is used by people with advanced permissions is really sort of the poster child for "Unjustifiable attack surface exposure risk".