Moving to 'Needs Review' for the decision record.

Change #1153612 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] Add $wgCheckUserDisableCheckUserAPI

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

In T396010#10883471, @Dreamy_Jazz wrote:

Moving to 'Needs Review' for the decision record.

This looks good to me.

Change #1153612 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Add $wgCheckUserDisableCheckUserAPI

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

When Chinese Wikipedia had CheckUsers (all CUs are suspended in 2018), it is a practice to regularly mass check all IPBEs using this API. This practice is no longer recommended per https://meta.wikimedia.org/wiki/Wikimedia_Foundation/Legal/Statement_regarding_IP_block_exemptions.

Change #1153646 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[operations/mediawiki-config@master] Set wgCheckUserDisableCheckUserAPI to false on loginwiki

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

Change #1153646 merged by jenkins-bot:

[operations/mediawiki-config@master] Set wgCheckUserDisableCheckUserAPI to false on loginwiki

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

Mentioned in SAL (#wikimedia-operations) [2025-06-04T15:14:49Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1153646|Set wgCheckUserDisableCheckUserAPI to false on loginwiki (T396010)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-04T15:16:59Z] <dreamyjazz@deploy1003> dreamyjazz: Backport for [[gerrit:1153646|Set wgCheckUserDisableCheckUserAPI to false on loginwiki (T396010)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-06-04T15:24:52Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1153646|Set wgCheckUserDisableCheckUserAPI to false on loginwiki (T396010)]] (duration: 10m 03s)

Change #1153653 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] Follow-up: Add $wgCheckUserDisableCheckUserAPI

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

Thank you to Dreamy and everyone for your work on this.

The only thing I'd ask is a precommitment from the Foundation that if CUs from a project (a) requests that the API be reenabled on the project and (b) presents a reasonable semi-automated tool or script that involves running logged checks using the API as directed by the user, the request will be granted (without additional bureaucratic requirements like an explicit showing of community consensus).

I ask because this step appears to be a protective measure and isn't actually intended to prevent the development of such a human-driven API-reliant tool. Our current CU tools involve, e.g., screen-scraping CU results to generate comparison tables. This works fine right now, but it's a kludge that ought to be improved if a CU wants to invest the time to develop a better tool for assisting in CU work using the API.

It seems appropriate to waive the requirement of community consensus given this change isn't being made at the request of the community and is mainly a preventative precaution.

Change #1153653 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Follow-up: Add $wgCheckUserDisableCheckUserAPI

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

Attempting to use action=query&list=checkuser now returns:

{
    "error": {
        "code": "disabled",
        "info": "The 'checkuser' query API has been disabled by the site administrators.",
...

Test environment: local docker CheckUser 2.5 (a46a1bf) 21:10, 10 June 2025.

Thanks for everyone's work on this.

I'd like to renew the below request for consideration before the change gets deployed on the train, if possible. Please let me know if there's anything I can do to facilitate its consideration.

In T396010#10885310, @L235 wrote:

Thank you to Dreamy and everyone for your work on this.

The only thing I'd ask is a precommitment from the Foundation that if CUs from a project (a) requests that the API be reenabled on the project and (b) presents a reasonable semi-automated tool or script that involves running logged checks using the API as directed by the user, the request will be granted (without additional bureaucratic requirements like an explicit showing of community consensus).

I ask because this step appears to be a protective measure and isn't actually intended to prevent the development of such a human-driven API-reliant tool. Our current CU tools involve, e.g., screen-scraping CU results to generate comparison tables. This works fine right now, but it's a kludge that ought to be improved if a CU wants to invest the time to develop a better tool for assisting in CU work using the API.

It seems appropriate to waive the requirement of community consensus given this change isn't being made at the request of the community and is mainly a preventative precaution.

As a dewiki CU with a technical background I have been quite frustrated with the limitations of Special:Investigate (limited no. of accounts / ips), no adding accounts manually, no widening of IPv6 ranges, no advanced filtering, etc. and have been thinking about writing a better tool for some time. So just like @L235 I would like to have the ability to use the API on dewiki to develop such a tool.

In T396010#10911096, @L235 wrote:

Thanks for everyone's work on this.

I'd like to renew the below request for consideration before the change gets deployed on the train, if possible. Please let me know if there's anything I can do to facilitate its consideration.

In T396010#10885310, @L235 wrote:

Thank you to Dreamy and everyone for your work on this.

The only thing I'd ask is a precommitment from the Foundation that if CUs from a project (a) requests that the API be reenabled on the project and (b) presents a reasonable semi-automated tool or script that involves running logged checks using the API as directed by the user, the request will be granted (without additional bureaucratic requirements like an explicit showing of community consensus).

I ask because this step appears to be a protective measure and isn't actually intended to prevent the development of such a human-driven API-reliant tool. Our current CU tools involve, e.g., screen-scraping CU results to generate comparison tables. This works fine right now, but it's a kludge that ought to be improved if a CU wants to invest the time to develop a better tool for assisting in CU work using the API.

It seems appropriate to waive the requirement of community consensus given this change isn't being made at the request of the community and is mainly a preventative precaution.

I think it's difficult to give a pre-commitment like that. I'm not saying "no", just that a lot would depend on the details of what is being requested. So, if/when a use case arises, please bring it up and we'll discuss.

In T396010#10911973, @Count_Count wrote:

As a dewiki CU with a technical background I have been quite frustrated with the limitations of Special:Investigate (limited no. of accounts / ips), no adding accounts manually, no widening of IPv6 ranges, no advanced filtering, etc. and have been thinking about writing a better tool for some time. So just like @L235 I would like to have the ability to use the API on dewiki to develop such a tool.

From my point of view, these are the types of things that can and should be improved/fixed in Special:Investigate. Do tasks exist for these requests? If so, we can review them and prioritize them.

In general, because of the sensitivity of the functionality involved, I think we would prefer to do everything possible to make the UIs in the extension do everything that CUs need it to do, as opposed to providing an API that is then consumed by third party scripts.