I've gone through: https://wikitech.wikimedia.org/wiki/User-agent_client_hints and it looks like the CheckUser extensions is the one that provides this feature.

The feature is already enabled today in all wikis by default [1][2]: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/8f22ba82627048113e79d942cfa781586e6861b9/wmf-config/InitialiseSettings.php#6907 but since the auth domain is not a "real wiki", that means the configuration above doesn't apply there (I think?).

Does it mean we would have to apply this to the auth domain explicitly around: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/8f22ba82627048113e79d942cfa781586e6861b9/wmf-config/CommonSettings.php#558? Would that suffice?

[1] https://wikitech.wikimedia.org/wiki/Server_Admin_Log/Archive_70#2023-08-22
[2] https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/951431

Enabling there should be fine from a Trust and Safety Product Team point of view, however, http-client-hints can be collected via a JS API on specific pages. Specifically:

• Login - Collects via either HTTP headers or JS API
• Logout - Collects via HTTP headers
• Password reset - Collects via JS API
• Creating an account - Collects via HTTP headers

This is controlled through the $wgCheckUserClientHintsSpecialPages config, but changing that won't necessarily work because support would need to also be built for that method for each special page.

CheckUser currently unsets the Client Hints HTTP header when it's not needed. Therefore, a blanket enable of this for auth.wikimedia.org would need some code changes to CheckUser to support.

In T395185#10863556, @Dreamy_Jazz wrote:

Enabling there should be fine from a Trust and Safety Product Team point of view, however, http-client-hints can be collected via a JS API on specific pages. Specifically:

• Login - Collects via either HTTP headers or JS API
• Logout - Collects via HTTP headers
• Password reset - Collects via JS API
• Creating an account - Collects via HTTP headers

Ack!

This is controlled through the $wgCheckUserClientHintsSpecialPages config, but changing that won't necessarily work because support would need to also be built for that method for each special page.

So that means we need to know the list of special pages upfront so that those can be added to CheckUser. I can poke around come up with a list of pages needed for that but off the top of my head, I imagine: Special:CreateAccount (which is already supported), Special:Userlogin (which is already supported), Special:PasswordReset (which I think is already supported per your above message).

I also imagine maybe 2FA special pages are needed but I'll confirm that with Tgr if that is the case but I think the base cases are already supported by CU today so maybe nothing to do there? Or are the special pages domain bound, I suspect not.

In T395185#10863528, @DAlangi_WMF wrote:

The feature is already enabled today in all wikis by default [1][2]: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/8f22ba82627048113e79d942cfa781586e6861b9/wmf-config/InitialiseSettings.php#6907 but since the auth domain is not a "real wiki", that means the configuration above doesn't apply there (I think?).

The feature is enabled in MediaWiki, but the way that correlates with the actual functionality being enabled in the browser is complicated and apparently somewhat unreliable (client hints for login don't end up in the webrequest table, at the very least).

In T395185#10863556, @Dreamy_Jazz wrote:

http-client-hints can be collected via a JS API on specific pages. Specifically:
[...]
This is controlled through the $wgCheckUserClientHintsSpecialPages config, but changing that won't necessarily work because support would need to also be built for that method for each special page.

Which seems very complex and fragile compared to just emitting Accept-CH headers unconditionally from Apache or some generic hook like BeforePageDisplay.

In T395185#10864185, @Tgr wrote:

Which seems very complex and fragile compared to just emitting Accept-CH headers unconditionally from Apache or some generic hook like BeforePageDisplay.

We use the JS API because there are places where we cannot just use the Accept-CH headers. For example, editing a page doesn't necessarily involve a request before it to request the headers to be included in the next request.

Furthermore, we unset the Accept-CH header because we wanted to avoid a situation where the browser is asking for permission to give the data in a context where we are not using it. For example, https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Client_hints#high_entropy_hints says that "The decision might be based on user preferences, a permission request, or the permission policy". Therefore, in theory a browser might implement a permission popup when we ask for the Client Hints even if they are just reading the site.

Sure, but there isn't any context on auth.wikimedia.org where we are not using the hints.

Agreed. We can therefore add a config to CheckUser to always send the header and set it to true for authwiki?

Yeah, that's probably the best way to do it. No need to directly involve CentralAuth then, we already have a bunch of configuration overrides for the auth domain in mediawiki-config.

Just to be clear, is this work that MediaWiki-Platform-Team will do or is something you want Trust and Safety Product Team to do?

In T395185#10867121, @Dreamy_Jazz wrote:

Just to be clear, is this work that MediaWiki-Platform-Team will do or is something you want Trust and Safety Product Team to do?

This is something we can take on since it's SUL3 related and I'll be taking it Dreamy. So once the patch is up, you can chime in with expertise on CU side of things. Hope that is helpful?

In T395185#10867135, @DAlangi_WMF wrote:

In T395185#10867121, @Dreamy_Jazz wrote:

Just to be clear, is this work that MediaWiki-Platform-Team will do or is something you want Trust and Safety Product Team to do?

This is something we can take on since it's SUL3 related and I'll be taking it Dreamy. So once the patch is up, you can chime in with expertise on CU side of things. Hope that is helpful?

Sure. I can help with that. Thanks.

In T395185#10865018, @Dreamy_Jazz wrote:

Agreed. We can therefore add a config to CheckUser to always send the header and set it to true for authwiki?

I was thinking we could just reuse the $wgCheckUserClientHintsEnabled and set it to true here: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/5553a0788e94b2001cffbfdc0dec86cfb714c1f7/wmf-config/CommonSettings.php#558 because that is where we determine if a given domain matches the auth domain.

I'll make a patch to the config repo.

Change #1152064 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[operations/mediawiki-config@master] SUL3: Enable client hints data on the auth shared domain

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

In T395185#10867539, @DAlangi_WMF wrote:

I was thinking we could just reuse the $wgCheckUserClientHintsEnabled and set it to true here: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/5553a0788e94b2001cffbfdc0dec86cfb714c1f7/wmf-config/CommonSettings.php#558 because that is where we determine if a given domain matches the auth domain.

No, because that config just enables the feature. It does not unconditionally set the Accept-CH header. Instead it would just produce the same behaviour as used on all real wikis.

Change #1152650 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/extensions/CheckUser@master] Introduce `CheckUserClientHintsEnabledOnAuthDomain` setting

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

Change #1152813 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/extensions/CheckUser@master] SUL3: Always set client hint headers on auth shared domain

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

Change #1152650 abandoned by D3r1ck01:

[mediawiki/extensions/CheckUser@master] Introduce `CheckUserClientHintsEnabledOnAuthDomain` setting

Reason:

In favor of: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1152813

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

Adding our sprint tag to capture that Trust and Safety Product Team have been providing some review.

Change #1152813 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] SUL3: Always set client hint headers on auth shared domain

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

Our part is done, so moving to 'Done' on our workboard.

In T395185#10879181, @Dreamy_Jazz wrote:

Adding our sprint tag to capture that Trust and Safety Product Team have been providing some review.

Ack! Thanks for tracking this Dreamy!

In T395185#10883072, @Dreamy_Jazz wrote:

Our part is done, so moving to 'Done' on our workboard.

I highly appreciate your guidance on this. You're a rare gem! :-]

In T395185#10883380, @DAlangi_WMF wrote:

In T395185#10883072, @Dreamy_Jazz wrote:

Our part is done, so moving to 'Done' on our workboard.

I highly appreciate your guidance on this. You're a rare gem! :-]

Thanks!

That means the /checkuser/v0/useragent-clienthints API requests are not made anymore on the auth domain and we can undo the change from T381223: useragent-clienthints API does not work on the SUL3 authentication domain, right?

In T395185#10887134, @Tgr wrote:

That means the /checkuser/v0/useragent-clienthints API requests are not made anymore on the auth domain and we can undo the change from T381223: useragent-clienthints API does not work on the SUL3 authentication domain, right?

No. Just enabling the Client Hint HTTP headers doesn't mean that the data is collected for methods that only accept the JS API (specifically resetting a password and successful login).

Change #1152064 merged by jenkins-bot:

[operations/mediawiki-config@master] SUL3: Enable client hints data on the auth shared domain

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

Mentioned in SAL (#wikimedia-operations) [2025-06-11T13:03:04Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1152064|SUL3: Enable client hints data on the auth shared domain (T395185)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-11T13:05:12Z] <lucaswerkmeister-wmde@deploy1003> d3r1ck01, lucaswerkmeister-wmde: Backport for [[gerrit:1152064|SUL3: Enable client hints data on the auth shared domain (T395185)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-06-11T13:14:14Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1152064|SUL3: Enable client hints data on the auth shared domain (T395185)]] (duration: 11m 09s)

@DAlangi_WMF thanks for picking up the task! I think what's left is double-checking that it works:

• login and signup should show up in the checkuser logs, with client hints
• the webrequest table in Hive should have client hints for auth.wikimedia.org requests

I can confirm that the Accept-Ch header gets set, and the browser does send the various Sec-Ch-* headers in the request. Also the checkuser UI still shows client hints for login.

The webrequest table still doesn't record any of the hints; I suppose something must be broken on the analytics side. Filed as T397464: Client hints not recorded in the webrequest table.