Fingerprinting Protections v3

[pes10k]

This issue tracks additional ideas for how the farbling and webcompat protections achieved with #8787 can be built on.

For now this is a mix of 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.

• enumerateDevices (deviceIDs and labels): Fingerprinting 3.0: enumerateDevices #8666
• WebXR: Fingerprinting 3.0: WebXR #9193
• Simplified Timezones: Fingerprinting 3.0: Simplified timezones #8574
• Fonts: Fingerprinting v3: Font Fingerprinting #816
• Window dimensions: Fingerprinting v3: Window size #720
• Dark mode detection: Fingerprinting v3: Dark Mode detection #15265
• WebGL Extensions: Fingerprinting 3.0: WebGL Debugging Followups #15882
• WebGL Extension farbling: Fingerprinting 3.0: Farble getSupportedExtensions and WebGL #15904
• Speech Synthesis: Fingerprinting 3.0: SpeechSynthesis API #18062
• Accept Language: Fingerprinting v3: Accept-Language #20096

[Snaxeko]

What about getClientRects randomization ? It would be nice if it had the same behavior than for canvas fingerprinting, ie randomizing only after ending a browsing session (once browser is closed). Bromite is the only one chromium browser that does it to my knowledge, and I didn't notice any particular bug.

[pes10k]

@Snaxeko we discussed initially but ended up not including it for several reasons, the main one being that the API is mainly used for fingerprinting (that I know if) is for font enumeration, but there are other ways of determining the same information w/o getClientRects (the most common way is to just check the width of the styled element, for example).

So, modifying this API seemed like all webcompat risk, with no benefit. The new approach we're going to go with (after landing the ephemeral storage work) will be #816

BTW, if you are involved in the Bromite project, it'd be great to work on this together. There are some important benefits from how Brave does randomization here (mainly having to do with the scope and lifetime of the randomization, to discourage statistical attacks), but I (and we!) appreciate their work, and this could be a promising area for collaboration

[pachainti]

Hi,
do you have any update about this?

[pes10k]

@pachainti this is a tracking issue that tracks several sub issues. We've recently added randomization based protections against the Speech Synthesis based fingerprinting (#18062) and are now working on protections for Accept-Language and Fonts, which we hope/expect to ship this quarter

[aocorporation]

What are the status update on the work to bring font fingerprint protection to Linux? I believe Bromite has already patched this for Android (which is Linux I guess) Their patch code can be found here uazo/bromite-buildtools#52 (comment) @pes10k
I realize there may be some web compatibiltiy breakage but Bromite has addressed this by adding it as a flag for power users,

[pes10k]

@aocorporation font-fingerprinting protections are already live in and in stable for Android (and have been for a long time now).

We do not have any plans for font fingerprinting protections for desktop linux though, bc (to the best of my knowledge) there isn't a consistant enough set of fonts all desktop linux distributions ship with (each disto does things a little bit different) so we can't meaningfully distinguish a "OS provided font" from a "user or application installed font".

If there i. is such a list though on the web, that maps linux distros to included fonts, and ii. those lists have enough overlap that there is a compat-friendly intersection of fonts between them, that would be very interesting. but again my understanding is that is not the case

[jeroenev]

What about just bundling a fixed preset of fonts with brave and only listing those? Is that not an option?
Would increase the bundle of brave a bit, but would solve the fingerprinting issue.
Though I would understand if they chose not to bundle fonts with a browser.

[pes10k]

We considered this, but there were a couple of issues:
i. increased binary size
ii. legal issues with fonts (particularly for some regions)

[akovia]

So are there no recommended remedies for Linux users? It seems that every browser extension or other fixes I have found have been abandoned, and I'm left with an unacceptable fingerprint metric that I can not find a reliable way around. The irony here is thick in that the most privacy friendly OS is not a candidate for protections against font fingerprinting.

@pes10k

We considered this, but there were a couple of issues:
i. increased binary size
ii. legal issues with fonts (particularly for some regions)

Please excuse my ignorance if this is not possible, but what if you left the collection of the suggested fonts up to the end user to collect and configure so that Brave could use them as an "additional hardening option"? This would address both issues that you pointed out.

Thanks for your consideration.

[pes10k]

Please excuse my ignorance if this is not possible, but what if you left the collection of the suggested fonts up to the end user to collect and configure so that Brave could use them as an "additional hardening option"? This would address both issues that you pointed out.

I just want to make sure I understnad the suggestion. Is the proposal to (something like) let users select which fonts are visible and which are hidden? Like basically a list of all the fonts chromium knows of, and a check box next to each?

If thats the propsal, its an interesting idea, but i think its not likely something we'd dedicate resources too in the medium term, for a couple of reasons:

• competing priorities and limited time (a boring no fun answer, but the truth)
• I'm generally very skeptical of these kinds of "give the user very fine grained controls" approaches to privacy protections, not out of a principal or anything, but bc of the practical issue of that users that make a lot of specific configurations to their browsers to improve their privacy almost inevitably end up making themselves more identifiable (and the users that are experienced and expert enough to do so correctly are usually already well served by extensions)

[akovia]

Is the proposal to (something like) let users select which fonts are visible and which are hidden? Like basically a list of all the fonts chromium knows of, and a check box next to each?

I honestly hadn't thought it that far through, but that is interesting indeed.

In my limited knowledge of reading the previous comments, I was thinking something a bit different.

What about just bundling a fixed preset of fonts with brave and only listing those?

i. increased binary size
ii. legal issues with fonts (particularly for some regions)

My thought is that you propose a good working set of fonts that you would have bundled if not for the points you brought up, and the end user could acquire these fonts and point Brave to the folder containing them. (Could you even emulate a default Windows configuration? https://wiki.archlinux.org/title/Microsoft_fonts)

This is probably an over simplified response to what I read, but it would address the two points you mentioned.

In the end, I'm just looking for a reliable solution that I still don't know how to fix, be it an extension or otherwise. I figured the most reliable solution would come from the browser developer itself, and is unlikely to disappear like an extension dev.

Whatever happens, thank you for at least playing it out. I still haven't found a solution, but will keep looking.
Cheers!

[pes10k]

The only other thing I'd add is that Brave's randomization approach to fingerprinting protections is designed (in part) to address situations like this. Some users will unavoidably having something thats very unique about their situation (relative to the others visiting the websites they do), and in some cases that unique attribute can't easily be removed (for compatibility reasons). Brave randomizes a large number of values fingerprinting scripts use to try and identify users, and if a fingerprinting script consumes any of those values when generating their identifier, than the user will be protected (because of the details on how the vast majority of fingerprinting scripts work).

So, TL;DR;, even if this one, specific fingerprinting protection doesn't currently run on desktop linux in Brave, the many other randomization protections Brave uses do run on desktop-linux-Brave, and so you will be generally very very well protected

[pachainti]

The next release of firefox v119 will have:
The visibility of fonts to websites has been restricted to system fonts and language pack fonts in ETP strict mode to mitigate font fingerprinting.
Firefox allows a granular setting against font fingerprinting.
Can Brave follow a similar approach on GNU/Linux?
Thank you

[pes10k]

hi @pachainti , I appreciate the nudge here. I dont think we want to mirror Firefox here (I am confident that Brave's randomization approach provides better protections from fingerprinters for users), but we can do better than what we have currently, both by being more narrow about the set of fonts that we randomize from, and by seeing if we can at least apply some font protections on popular linux distros.

I know @arthuredelstein has been working on changes here. I expect we'll have something in nightly soon. Thanks again for the nudge and keeping our feet to the flame

[alex-bacart]

In the Brave support article there's a list of arguments we can use and there's one I find pretty usable for fonts fingerprinting protection. It's --register-font-files.

Registers additional font files on Windows (for fonts outside the usual %WINDIR%\Fonts location). Multiple files can be used by separating them with a semicolon (;).

What if Brave will let us specify this files on any system not only on Windows? In my opinion it will allow to specify any font on startup and there will be no legal issues and binary size won't increase.