Brave-browser: Fingerprinting Protections v2: Farbling and cross-origin

[pes10k]

Current Approach
Brave’s current fingerprinting protections currently key off first-party / third-party distinctions, which is a mismatch with what's really being described: protections with a high risk of breaking websites, vs protections with a low risk.

This has two problems:

1. It requires us to under apply useful protections that have low webcompat risk (since they’re tied to the high risk ones)
2. It prevents us from deploying high confidence, high risk protections, since that will drive users further away from the low-risk ones (since they’re currently all or nothing, w/in party context).

New Approach
Brave should replace the existing fingerprinting protections options (“off”, “third-party”, “first and third party”) with the following options:

1. Off: Don’t apply any fingerprinting protections
2. Default: A useful set of protections that may not fundamentally prevent fingerprinting attacks, but re practical against real world fingerprinting attacks. Carries a small but non-zero chance of breaking sites.
3. Maximum: The strongest set of protections, that disables or otherwise modifies page functionality to prevent sites from accessing or learning the underlying data needed for fingerprinting attacks. Carries larger, non-trivial web-compat risks.

Users would then be able to select which of the three sets of defense to apply to pages through the shields dialog, just as with other shields settings. As with other shields settings, user configuration is determined by the top / eTLD+1 origin, but applied to all third parties on the page.

This is a tracking issue. The per api-work is described in the issues below:

• [x] Canvas: https://github.com/brave/brave-browser/issues/9186
• [x] enumerateDevices (randomize order): https://github.com/brave/brave-browser/issues/11271
• [x] Web Audio: https://github.com/brave/brave-browser/issues/9187
• [x] WebGL: https://github.com/brave/brave-browser/issues/9188
• [ ] WebGL2: https://github.com/brave/brave-browser/issues/9189
• [x] User Agent: https://github.com/brave/brave-browser/issues/9190
• [x] Plugins: https://github.com/brave/brave-browser/issues/9435, https://github.com/brave/brave-browser/issues/10597
• [x] Hardware Concurrency: https://github.com/brave/brave-browser/issues/10808
• [x] Front end work: https://github.com/brave/brave-browser/issues/9194
• [x] Workers: https://github.com/brave/brave-browser/issues/11368

[felschr]

Can I suggest setting the new Maximum level as the default for private windows?
Perhaps similarly to the DuckDuckGo option that can quickly be toggled on the new tab page.
And I guess in Tor mode it should be on Maximum by default.

[pes10k]

@FelschR I think thats a great idea. I dont believe we currently have any shield settings that are specifically set for private windows, but I think we could definitely make the case for Tor private windows. In general, my (unofficial) feeling is that we should avoid privacy divisions between windows and private windows beyond private windows always starting with their own profile.

But, all this is a good idea. I'll discuss internally and see what folks think. Thanks!

[RuthlessRuler]

Also, Please make the Private + TOR Mode use Default TOR User Agent String instead of Brave's UA. Cause using custom User Agent String with TOR makes website be able to identify users more Uniquely.

[pes10k]

@RuthlessRuler I appreciate the suggestion, but I don't think we will go in that direction. Its already easy to distinguish Brave (in Tor) and Tor Browser Bundle, since Blink and Gecko are different in many many ways. Advertising a Gecko UA in Blink will break some sites (even if only those out in the tails) without any corresponding privacy benefit.

[RuthlessRuler]

@pes10k then how about having a common String for TOR window across all platforms (Linux, Mac, Windows)?

[pes10k]

@RuthlessRuler I don't think this would have the intended effect, as you will wind up in a smaller anonymity set again in many (most?) situations. If you name on platform (say, windows) on a device with a non-windows like set of capabilities (say, Apple hardware screen sizes, concurrency and touch points) you'll be more identifiable, not less. And if you have some new UA that doesn't mention the platform at all, then you're in the smallest possible anonymity set possible.

The best option, privacy wise here, is to just keep the Brave (and, Chrome) UA in Tor and not Tor mode, to maximize anonymity

[pes10k]

Note that several of these have been moved to https://github.com/brave/brave-browser/issues/11770, for the reasons mentioned in that issue:

features that are waiting on the standard to settle down, or which we're not sure about the web compat implications of, or other stuff we're still thinking through