[Sm-v124-r2] : BROKEN "ClientHints API Removal" implementation

[Vangelis66]

Background

Literature: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/client_hints/README.md https://www.chromium.org/updates/ua-ch/ https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#client_hints https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API https://developer.chrome.com/docs/privacy-security/user-agent-client-hints ... and concerns :wink: : A Privacy Measure Turned Upside Down? Investigating the Use of HTTP Client Hints on the Web Client hints or client lies?

The feature was first rolled out in M85 (UA-CH in M89), fully "matured" in M93; in early Chrome versions (e.g. M86, M87), the (tracking) feature was behind the not-revealing-much chrome://flag called Experimental Web Platform features (#enable-experimental-web-platform-features), which wasn't enabled by default; in later Chrome versions, it was decoupled from said flag and to manually disable it the following applies: https://issues.chromium.org/issues/40156450#comment2 which, for non-enterprise users, boils down to issuing the cmdline switch: --disable-features=UserAgentClientHint (note: singular for Hint)

That switch continued to work until (and including) M121, because in M122 the supporting code was excised :disappointed: : https://chromium-review.googlesource.com/c/chromium/src/+/5200952 https://source.chromium.org/chromium/chromium/src/+/7cb768195fc3a89fa618fec85e2d1b0dbd4e3c42

For the purposes of this report, I have rebuilt my Sm-v121-r2 profile to document/demonstrate (to Sm author and the rest) how that switch used to work; for testing, I've used below dedicated sites: https://browserleaks.com/client-hints (both JS API and HTTP headers) https://user-agent-client-hints.glitch.me/ (JS API) https://user-agent-client-hints.glitch.me/headers (HTTP headers)

Below I'm attaching screengrabs, ALL taken while using Sm-v121 without the switch:

... And now, with the --disable-features=UserAgentClientHint cmdline switch in place:

As I hope you can see, NOTHING is actually sent to servers with that switch in place; and do note that the BL page reports the API as UNSUPPORTED ...

Describe the bug

From Sm-v124-r2's Release Notes:

It is also possible to disable UACH outright using the flag --remove-client-hints or associated feature as done in older Chromium versions.

First, a documentation of what the browser sends out by default:

To Reproduce

Steps to reproduce the behaviour:

1. Launch Sm-v124-r2 with the suggested cmdline switch, i.e. --remove-client-hints, like below:

2. Load the CH test sites, take screengrabs.

Expected behavior

Sending out of CH should have been disabled, both via JS API and HTTP-Headers

Result

The suggested cmdline switch HAS NO EFFECT WHATSOEVER, CH are sent normally as without that switch :-1: ; I have reproduced and verified, too, in a fresh browser profile, with default settings and flags (even using the --no-experiments cmdline switch) and with only a minimum number of cmdline arguments, including the switch in question...

Screenshots See the ones just above (default case, without the cmdline flag)

FWIW, I specifically asked here whether the "old and trusted" cmdline switch --disable-features=UserAgentClientHint would continue to work in the Sm-v124-r2 implementation and was, in fact, reassured of that; guess what? When the browser is being launched with that old cmdline flag, like below:

it, again, HAS NO EFFECT :sob: ...

What works (only partially):

1. Launching the browser with the --enable-features=RemoveClientHints (plural in Hints) cmdline switch; you have to double-check, though, that the cmdline arguments you finally pass to chrome.exe (includes the rest of switches + modified chrome://flags) don't exceed the character limit on Windows (in my heavily modified "dirty" profile, the switch wouldn't come through initially, only after I reset a number of custom flags :wink: ) ...
2. Setting chrome://flags/#remove-client-hints to Enabled and relaunching.

However, I call this implementation a "buggy" one, because:

... and

... but:

i.e. the BL test page reports the CH-API as SUPPORTED and the Glitch test page can still receive CH Headers...

Additional context

Let's just call this "collateral damage", but when the flag #remove-client-hints has been enabled in Sm-v124-r2, my userscript manager of choice for many years, the open-sourced Violentmonkey, ceases to function as expected in the browser :rage: : applicable (to a page) userscripts don't get injected, the VM toolbar icon remains grey and when clicked it reports that "the tab must be reloaded"; reloading the tab, though, brings no change to the extension's broken functionality :cry: ; both the stable and beta versions are broken under this scenario: https://chrome.google.com/webstore/detail/violentmonkey/jinjaccalgkegednnccohejagnlnfdag/ https://chrome.google.com/webstore/detail/violentmonkey-beta/opokoaglpekkimldnlggpoagmjegichg/

Both VM latest versions work OK when that flag is reset; FWIW, VM works flawlessly in Sm-v121-r2 with or without the --disable-features=UserAgentClientHint cmdline flag (which, itself, works fully as intended there) ...

Some months ago, VM started taking into account the ClientHints requests made by pages (to be injected by userscripts), my own search in their repo suggests the current conflict with "your" implementation might be due to: https://github.com/violentmonkey/violentmonkey/commit/d2dda25d91e3718e5b20ba4648e82baf730e6178

Lastly, I realise your "Remove-Client-Hints" implementation in Sm-v124-r2 is largely based on Ungoogled Chromium's one below:

https://github.com/ungoogled-software/ungoogled-chromium/pull/2902/commits/f29e4deaa9277ca50f9072171279185867947a17#diff-c163d5582e5ca02bd3d7921ed6362720b2355f312c45eea3bda1bd348e65ffed

so I can only infer (can't run this browser in my OS) that their fork also suffers from the same shortcomings I listed above...

Desktop:

OS: Windows Vista SP2 32-bit, en-US locale, updated through to EoL, plus select WS2008SP2 updates manually installed. Browser (with the issues): Supermium v124-r2, 32-bit release (my daily driver now being Sm-v122-r6, where I wrote this issue report :smile: )

Apologies for the length of this report, I can only hope it can be acted upon in due course :smile: ...

Many thanks for this wonderful browser, a life-saver for my 32-bit OS :1st_place_medal: ... Kindest regards.

[Vangelis66]

... As for disabling ClientHints in Supermium-v122+, I can only wholeheartedly recommend BrowserNative's extension below:

https://chrome.google.com/webstore/detail/user-agent-switcher/jkafdamincoabdjebhjmbiflploojgjf

This is my configuration to that goal:

Being an extension, it can't really disable the CH JS API (and BrowserLeaks test page can "see" that the API is supported) but, other than that, no CH whatsoever is being sent to servers, either probed via JS or Headers... Added bonus: It happily coexists with Violentmonkey :tada: ...

[win32ss]

I can remove all the UACH information sent via JavaScript but it's very difficult to outright disable it (so a similar state to what the extension above offers). All the code, even on the renderer end seems to be focused on disabling it from sending in HTTP headers but not JS, so it's possible that change was made at a different time.

[Vangelis66]

... Thank you very much for this reply :+1: :heart: ; let me just tell you I absolutely don't want to come off as an entitled and difficult-to-please ungrateful user :wink: ; having used other open-source software for close to two decades now, I highly appreciate ALL the efforts put into releasing and maintaining them, especially in the case of Supermium, where the developers' "team" is "understaffed" :smile: ...

Have you acknowledged/verified yourself the points I raised above?

1. --disable-features=UserAgentClientHint and --remove-client-hints don't function at ALL in Sm-v124-r2 ?
2. With the GUI flag chrome://flags/#remove-client-hints Enabled (or the equivalent cmdline switch) 2a. the Glitch test site can still receive both Low and High Entropy CHs from the browser via HTTP Headers (i.e. NOT JS API)? 2b. the popular and open-source userscript manager Violentmonkey becomes broken?

... and after reloading the tab, VM still non-functional :sob: :

Since this thread has auto-linked to it, I became aware of 1f58540 (to arrive in Sm-v126) ; as I wrote previously, I'm not a coder, so that source code isn't fully comprehensible by me :blush: ; has it been tested against the issues I pointed out?

I can remove all the UACH information sent via JavaScript but it's very difficult to outright disable it

This is a non-coder's logic/question, but couldn't the implementation extant in M121 be reinstated in its entirety back in M124+ ?

1. Dissect the source changelog M121...M122
2. Locate what exactly got axed by Google :rage: wrt CHs in M122, assuming it was not just 7cb7681
3. Merge back the portions of code that would again restore the status quo ante in Sm-v121

... or is it that this code has now become (partially) incompatible with the M126 tree?

so a similar state to what the extension above offers

... Discovered via an online search :wink: ; used currently as a "palliative" in Sm-v122-r6 (no native anti-CH implementation) and in Sm-v124-r2 (with a bugged implementation, as per this issue); Sm-v121 is less stable in my system than either v122/124; I read elsewhere that evil Google have removed the sane "older" browser GUI in M126+ for the abomination that is CR23, so I (and possibly others on "legacy" OSes) would opt to stay with Sm-v122/124 for somewhat longer :stuck_out_tongue_winking_eye: ...

As ever. many thanks for your precious time :heart: ...