Allow removing Accept-CH response headers

[cyyynthia]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

Client Hints are a draft standard allowing servers to request specific client information, through the Accept-CH and sometimes Critical-CH headers. The spec, written by Google, claims they are here to help avoid passive fingerprinting via User-Agents.

However, all websites operated by Google request through Client Hints information that is completely unnecessary to their operations, namely:

• CPU Architecture
• Bitness (64bit vs 32bit)
• Full browser version
• OS name and version
• Phone model name (e.g. Pixel 7)
• Whether you're using a 32bit browser on 64bit Windows (WOW64)

A very easy fix to prevent Google (and possibly others ill-intentioned websites) to gather this data is to drop the Accept-CH and Critical-CH headers from responses. Additional steps can be taken, such as dropping Sec-CH-* headers on outgoing requests, and appending Clear-Site-Data: "clientHints" to responses to tell the browser to immediately cease to send Client Hints.

Currently, uBO doesn't allow doing this, as the response header filtering capability is limited to only 4 headers, excluding the 2 headers mentioned above.

A specific URL where the issue occurs.

Everywhere

Steps to Reproduce

1. Go to a Google-owned website
2. Observe the network traffic
3. See the Accept-CH response headers, and the Sec-CH-* headers on subsequent requests

Expected behavior

The following rule to prevent the Accept-CH to be received and handled

example.com##^responseheader(accept-ch)

Actual behavior

The rule is invalid, the header is not trimmed and client hints are sent to the server.

uBO version

1.57.0

Browser name and version

Chromium 124.0.6367.91 (Official Build)

Operating System and version

Arch Linux 6.8.7-arch1-2

[Thorin-Oakenpants]

Please do not add fingerprinting protections into uBO. As it is, we already include uBO in Mullvad Browser, it's used in Tor Browser in Tails, and the consensus is (Tor Project apps team, whom I work with; not employed by) that we want to do the same in Tor Browser (and tighten things up) - because uBO is a general content blocker (not a FPing extension) that can reduce requests/attack-surface and improve general browsing and the network .. etc

Please leave FPing to upstream/experts and built in solutions. Removing features or breaking expected web standards, per domain but god forbid you use it globally, is just going to make you an outlier and probably cause breakage - for example, they can be used for security checks

Of course this wouldn't impact gecko .. yet, but becomes a footgun, IMO and you'd still need to protect other methods at least in gecko - see 1750143 <- and you will fail, see below

FYI: IIRC, uBO did this once before by trying to control userAgents (and failed miserably because extensions lack the ability in this case to fully cover all methods such as service workers - that and it's impossible to hide your engine or version or OS because of feature detection - I have working PoCs going back to FF52) - in the end it was removed

[gwarser]

What you propose if I would not like to share this data and don't want to use anti-fingerprinting browser?

[Thorin-Oakenpants]

FYI: IIRC ...

looking at that link from garry-ut99 maybe what I was thinking of was plugins - but still the same case, where extensions cannot fully protect the real value

What you propose ...

What you've always been doing. Extensions are not the place for JS fingerprinting protection - and you're not going to fully protect e.g. navigator.userAgentData (at least in gecko - maybe blink has some extra webext stuff). gorhill will be inundated with issues about how it leaks ... just like the last time .. not to mention breakage and weird side effects

There are a plethora of extensions available already to modify headers if you want to go that route (and I strongly recommend not to). To be fair I was mainly only talking about the userAgent ones, but there are a lot more

• https://browserleaks.com/client-hints
• you ultimately can't hide bitness, WOW64, DPR, all the prefers css items (psuedo, matchMedia, actual css which can be exfiltrated), lang, viewport .. among others (RTT come to think of it is also in navigator.connection) ...

I honestly see no reason to fiddle with any of these .. it will only end in tears and is counterproductive - you will leak, break, and be an outlier

[uBlock-user]

@Thorin-Oakenpants Ability to remove a header through a filter !== "Please do not add fingerprinting protections into uBO"

Your concern is un-warranted.

[Thorin-Oakenpants]

@uBlock-user I'm not saying you can't remove a header, what I'm saying is that almost all those client hints ones are going to be non-effective when JS is enabled, and some even without JS, and it's all going to simply lead to issues, tears, breakage and weird side effects [exhibit 1: see plugins in the past or whatever it was, could have sworn userAgent used to be in uBO]. If you can't protect the real value, which is the whole purpose of fingerprinting, then you're wasting your time. The title of the issue is about exactly those headers - client hints. So that's what I'm addressing

As a fingerprinting expert my concerns are warranted - and would likely facilitate uBO being dropped at Tor Project/Mullvad if we can't rely on lists to not include them (when/if gecko adds them) - it's a footgun.

If you want to add them then go ahead - I'm not telling anyone what to do - at the end of the day it's up to gorhill. At the very least put these types of filters behind a flag.

relevant gorhill comments

• Disable media device fingerprinting gorhill/uBlock#2378 (comment)
• Suggestion: Prevent AudioContext fingerprinting gorhill/uBlock#1647 (comment)
• Add plugin fingerprinting protection gorhill/uBlock#1037 (comment)

[uBlock-user]

and would likely facilitate uBO being dropped at Tor Project/Mullvad if we can't rely on lists to not include them (when/if gecko adds them)

Decisions are not made here based on whether we should piss off someone or not. If adding something is needed to provide user-agency and choice then the cause will be furthered.

and it's all going to simply lead to issues, tears, breakage and weird side effects

gorhill is capable of dealing with those, no need for you to worry about him.

[Thorin-Oakenpants]

What are you talking about? Who said anything about pissing people off? And of course gorhill will decide if it's worth it for both users and devs/list-maintainers. I am simply explaining, with examples, that that this is ineffective and breaking for end users, and just plain bad from a fingerprinting perspective. I've said my bit, unsubscribing. If you have anything relevant to say, @ me

[uBlock-user]

What are you talking about? Who said anything about pissing people off?

Read the line I quote from your last reply. It's self explanatory.

[cyyynthia]

I totally understand the point being made that these sorts of filters are something mostly user-specific and that it may do more harm than good. uBO being described as "an efficient blocker for network requests and DOM elements" does seem to make this issue off-limits of uBO's scope indeed.

I initially opened this issue seeing that it is possible to block headers, but only a subset - and that as a result it could be a good candidate for being part of uBO - which doesn't seem to be the case due to, as pointed out, the scope of uBO. The impact on third-party lists is also something I overlooked, I was mostly thinking about its use on a per-user basis (which is something the spec itself mentions; the negociation of Client Hints allow the browser to react "based on a user’s device, conditions and preferences"). I think the argument that it should be a separate extension holds true here.

That is consistent with the headers that uBO allows to filter out: the headers all instruct the browser one way or another to perform network requests (as part of a reporting protocol, or through redirects) - except maybe Set-Cookie? -- Side note, which should probably be another issue but if Report-To can be filtered, then Reporting-Endpoints should be too maybe?

I think unless someone strongly objects it's actually in fact something uBO would want to have, this issue can be closed 🤔