search

uBlockOrigin / uBlock-issues

This is the community-maintained issue tracker for uBlock Origin
https://github.com/gorhill/uBlock
916 stars 78 forks source link

Allow removing `Accept-CH` response headers #3230

Open cyyynthia opened 3 months ago

cyyynthia commented 3 months ago

Prerequisites

I tried to reproduce the issue when...

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:

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 commented 3 months ago

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

garry-ut99 commented 3 months ago

Since the discussion mentions fingerprinting, worth to know: https://github.com/uBlockOrigin/uBlock-issues/wiki/Does-uBO-protect-against-fingerprinting%3F

gwarser commented 3 months ago

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

Thorin-Oakenpants commented 3 months ago

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

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 commented 3 months ago

@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 commented 3 months ago

@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

uBlock-user commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 🤔