We've had some legal advice for GlobalUser Contributions that seems to be contradicting whether we can use this approach. Will update further once I've clarified the details.

In T354542#9463548, @Tchanders wrote:

For Global User Contributions, we've been advised by Legal that only to allow users with the checkuser right should be able to enter a temp user name and see the IP addresses they have used.

This is different to what we need here though, right? We need IP -> Temp account rather than the other way around. Not sure if that substantially changes anything but it doesn't reveal _more_ personal information than the user already had.

I think this means we'd need to restrict the new API to checkuser, if it was going to return IP addresses, meaning a sysop couldn't use it from Nuke. (Is it correct that sysops have the nuke right?)

Yes it looks like nuke is the user right, which on enwiki is given to sysop.

A different approach would be to provide an API that takes a temp account name and returns all the pages edited/created by temp accounts from IPs used by that temp account. That could be used by Nuke and by GUC.

On our call we said that CU probably only needed to go from IP to Username and Nuke could do Username->Pages, but if GUC also just needs to go the whole way then that would presumably work for us too.

In T354542#9463556, @Samwalton9-WMF wrote:

In T354542#9463548, @Tchanders wrote:

For Global User Contributions, we've been advised by Legal that only to allow users with the checkuser right should be able to enter a temp user name and see the IP addresses they have used.

This is different to what we need here though, right? We need IP -> Temp account rather than the other way around. Not sure if that substantially changes anything but it doesn't reveal _more_ personal information than the user already had.

You're absolutely right - I've been staring at my screen for too long.

The contradiction I've found is that, if we can't input a temp account and get back all the IPs, then T324602: SpecialBlock: Once a temporary account is selected, below the username field display IP addresses associated with the account should be restricted to the checkuser right. Doesn't affect this API or this task.

A different approach would be to provide an API that takes a temp account name and returns all the pages edited/created by temp accounts from IPs used by that temp account. That could be used by Nuke and by GUC.

On our call we said that CU probably only needed to go from IP to Username and Nuke could do Username->Pages, but if GUC also just needs to go the whole way then that would presumably work for us too.

It might be worth doing it this way, legal question aside. It will be easier to know once we know more about what GUC needs to do.

• Pro: all this page finding logic is in one place
• Con: the page finding logic probably shouldn't belong in CheckUser
• Con: the number of pages found would usually be larger than the number of IPs, perhaps too much to return in one go

The legal question might affect the scenario of entering a temp account name into Nuke and deleting all pages from all temp accounts that have used the same IPs. We briefly discussed on the call but it isn't in scope for T342785: Enable mass deletion of pages created by all temporary accounts which were used by an IP address, but just noting it here for future reference.

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

[mediawiki/extensions/CheckUser@master] [WIP] Add endpoint to get temporary accounts used by an IP

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

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

[mediawiki/extensions/CheckUser@master] Abstract parameter validation from AbstractTemporaryAccountHandler

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

Change #1054880 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Abstract parameter validation from AbstractTemporaryAccountHandler

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

Change #1053694 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Add endpoint to get temporary accounts used by an IP

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

@STran How should we be handling normalising IPs? I find the IP I pass to the endpoint needs to match the exact format and capitalisation of the cuc_ip column.

If all a temporary user's edits for an IP have been hidden (but the temp account is not hidden) should they still be listed for the IP (if the admin is not a suppressor)? For comparison, the same admin does not see the edits for that temporary account on Special:IPContributions/<ip>.

@dom_walden

How should we be handling normalising IPs? I find the IP I pass to the endpoint needs to match the exact format and capitalisation of the cuc_ip column.

I guess we'd better normalize to whatever cuc_ip is then. I'll make a follow-up patch.

If all a temporary user's edits for an IP have been hidden (but the temp account is not hidden) should they still be listed for the IP (if the admin is not a suppressor)? For comparison, the same admin does not see the edits for that temporary account on Special:IPContributions/<ip>.

I'm a bit confused. Is the API endpoint not working as expected? It shouldn't return any accounts the user can't see but the endpoint isn't returning any revision data.

In T354542#10069678, @STran wrote:

I'm a bit confused. Is the API endpoint not working as expected? It shouldn't return any accounts the user can't see but the endpoint isn't returning any revision data.

1. Temp user edits on <ip> (and they haven't made any other edits from that IP).
2. I change the visibility of the edit to hide the editor's username.
3. As a different user, I go to Special:IPContributions/<ip>. I don't see the edit from step 1.
4. I call /checkuser/v0/temporaryaccount/ip/<ip> as the user from step 3 and see the temporary user from step 1.

It feels to me like this is a potential leak of IP information.

Moving back to "In progress" for these two items:

In T354542#10069678, @STran wrote:

How should we be handling normalising IPs? I find the IP I pass to the endpoint needs to match the exact format and capitalisation of the cuc_ip column.

I guess we'd better normalize to whatever cuc_ip is then. I'll make a follow-up patch.

In T354542#10072404, @dom_walden wrote:

1. Temp user edits on <ip> (and they haven't made any other edits from that IP).
2. I change the visibility of the edit to hide the editor's username.
3. As a different user, I go to Special:IPContributions/<ip>. I don't see the edit from step 1.
4. I call /checkuser/v0/temporaryaccount/ip/<ip> as the user from step 3 and see the temporary user from step 1.

It feels to me like this is a potential leak of IP information.

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

[mediawiki/extensions/CheckUser@master] Normalize IP used in temporary accounts IP endpoint

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

Change #1068785 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Normalize IP used in temporary accounts IP endpoint

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

I guess we'd better normalize to whatever cuc_ip is then. I'll make a follow-up patch.

Done

It feels to me like this is a potential leak of IP information.

We discussed this + asked Legal and work to resolve this will be captured by T373599: The endpoint `/checkuser/v0/temporaryaccount/ip/{ip}` should respect suppress view rights.

We seem to be normalising IPv6 addresses now.

I compared the temporary accounts returned by the new rest.php/checkuser/v0/temporaryaccount/ip/<ip> endpoint with those returned by action=query&list=checkuser&curequest=ipusers&cutarget=<ip>.

The only discrepancies I saw were because the new endpoint only queries cu_changes. The checkuser API queries cu_changes, cu_log_event and cu_private_event. I guess this is deliberate. @STran?

I disabled temporary users (but set $wgAutoCreateTempUser['known'] = true;) and the new endpoint still returned temporary accounts. I guess this is desirable.

If temporary users are disabled but $wgAutoCreateTempUser['known'] = false;, the new endpoint returned the below internal server error. I don't know if such a setting would happen in production.

{'message': 'Error: exception of type BadMethodCallException: MediaWiki\\User\\TempUser\\RealTempUserConfig::getMatchCondition is disabled', ...

In T354542#10113003, @dom_walden wrote:

If temporary users are disabled but $wgAutoCreateTempUser['known'] = false;, the new endpoint returned the below internal server error. I don't know if such a setting would happen in production.

{'message': 'Error: exception of type BadMethodCallException: MediaWiki\\User\\TempUser\\RealTempUserConfig::getMatchCondition is disabled', ...

Perhaps we should check if the temporary accounts are known, and if not return a 404?

In T354542#10113032, @Dreamy_Jazz wrote:

In T354542#10113003, @dom_walden wrote:

If temporary users are disabled but $wgAutoCreateTempUser['known'] = false;, the new endpoint returned the below internal server error. I don't know if such a setting would happen in production.

{'message': 'Error: exception of type BadMethodCallException: MediaWiki\\User\\TempUser\\RealTempUserConfig::getMatchCondition is disabled', ...

Perhaps we should check if the temporary accounts are known, and if not return a 404?

Filed as T373891: Return a 404 if temporary accounts are not known

In T354542#10113003, @dom_walden wrote:

We seem to be normalising IPv6 addresses now.

I compared the temporary accounts returned by the new rest.php/checkuser/v0/temporaryaccount/ip/<ip> endpoint with those returned by action=query&list=checkuser&curequest=ipusers&cutarget=<ip>.

The only discrepancies I saw were because the new endpoint only queries cu_changes. The checkuser API queries cu_changes, cu_log_event and cu_private_event. I guess this is deliberate. @STran?

Leaving open pending a response from @STran, then we can close this.

In T354542#10116251, @kostajh wrote:

Leaving open pending a response from @STran, then we can close this.

I think I can answer these for @STran, but let me know if you disagree with my answers.

In T354542#10113003, @dom_walden wrote:

The only discrepancies I saw were because the new endpoint only queries cu_changes. The checkuser API queries cu_changes, cu_log_event and cu_private_event. I guess this is deliberate. @STran?

This is expected. The endpoint was intended to return IPs only associated with edits.

I disabled temporary users (but set $wgAutoCreateTempUser['known'] = true;) and the new endpoint still returned temporary accounts. I guess this is desirable.

I would agree this is desirable.