Allow CheckUser to provide IP addresses for logged in edits/actions
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	dbarratt
	Aug 29 2020, 5:33 PM

Description

Problem

The API endpoint created in T260603 only supports anon edits. This is because the IP addresses for logged in edits are not available in core.

Proposed Solution

Add a new hook to IP Info to pass a log/revision id, and the request context. Then another extension like CheckUser can listen for that and respond with the IP address.

If the popup should work on Special:Investigate pages. CheckUser should check to see if the request includes a query parameter of token. If it does it should validate the token and that the revision/log id is covered by the token. If so, it may return the IP address.
If the popup should work on Special:CheckUser pages. CheckUser should check to see if the request includes a query parameter of checkUserLogId. If it does it should validate that the log id is a valid log entry within the last 24 hours (?) and that the log entry covers the revision/log id being requested. If so, it may return the IP address.
If the popup should work anywhere user names are displayed (like Special:RecentChanges). Should the popup log the request? Should it ask for a log message? Or would it only work for IP reqeusts of users who have been logged already in CheckUser? If so, for how long? 90 days?

Regardless, requests for a revision/log id that belongs to a logged in user should not be publicly cached (it should include something like Cache-Control: private as a response header). But adding to the private cache is acceptable (I think?).

Alternative Solution

We could change the API to accept an IP address directly, rather than a revision/log id. However this raises some Privacy concerns as the IP address for a user could be revealed in the request logs on the server (which was the whole purpose of encrypting this data in the token on Special:Investigate). It also seems contrary to the IP Masking project.

Related Objects
Search...

Status	Subtype	Assigned	Task
Open		None	T261555 Allow CheckUser to provide IP addresses for logged in edits/actions
Resolved	Sep 22 2020	Tchanders	T260603 Create an API endpoint that accepts a log id or revision id and returns mock data about the IP address
Resolved		Tchanders	T260609 Create a basic extension.json file and a new wikipage for the IP Info extension
Resolved		dbarratt	T260611 Request a repository for the IP Info Extension

Event Timeline

dbarratt created this task.Aug 29 2020, 5:33 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 29 2020, 5:33 PM

dbarratt mentioned this in T260603: Create an API endpoint that accepts a log id or revision id and returns mock data about the IP address.Aug 29 2020, 5:34 PM

dbarratt added a subtask: T260603: Create an API endpoint that accepts a log id or revision id and returns mock data about the IP address.

DannyS712 subscribed.Aug 30 2020, 1:57 AM

dbarratt mentioned this in T260604: Display a popup with fixed mock data for an IP address on the specified page(s).Sep 2 2020, 3:04 PM

dbarratt mentioned this in T260821: Performance review of IP Info extension.Sep 11 2020, 5:09 PM

dom_walden mentioned this in T267230: Set Cache-Control header in API responses.Nov 26 2020, 10:48 AM

Tchanders closed subtask T260603: Create an API endpoint that accepts a log id or revision id and returns mock data about the IP address as Resolved.Dec 3 2020, 1:13 PM

dbarratt unsubscribed.Dec 3 2020, 1:29 PM

• Niharika moved this task from Backlog to Future / Maybe on the IP Info board.Sep 1 2021, 6:33 AM

Dreamy_Jazz added a project: CheckUser.Oct 1 2022, 12:01 AM

With regards to point 3, I'm not so sure about implementing that. Some points why I have concerns:

The current interface at Special:Investigate requires a reason, and for Special:CheckUser it is usually required. This means the interface will need to be able to accept a reason and have some kind of confirmation button (for mobile users using desktop view). This will take up a fair amount of space on pages like RecentChanges that are already crowded.
Because it only shows one IP, I'm unsure of how this would be used. Using Special:CheckUser / Investigate on the account would provide the IP and other IPs, including whether other users have used said IP. As I don't think this would be accessible by anyone other than checkusers, it doesn't seem to me to offer much over using Special:CheckUser / Investigate.

For 1 and 2, Special:CheckUser / Investigate already show the IP to the checkuser for registered users when a logged action or edit is shown. As such the API endpoint that takes an IP could be used instead of having a separate API endpoint.

The concern surrounding the information being in the GET parameters is something to consider, but I would note that the server logs are likely to contain the IP used to make the revision / log entry at the time that the action was made, and those with access to those logs are also likely to have access to the database tables that store this data too. Browser history is also a concern, but API requests wouldn't be usually logged in the browser history. If the concern still exists the server could generate an encrypted version of the IP that the client could use in a GET request as the API would only ever be called once a check (and a page load to get this info) was made.

Allow CheckUser to provide IP addresses for logged in edits/actionsOpen, Needs TriagePublicActions