Fingerprinting v3: Accept-Language

[pes10k]

This is a sub-issue of the larger fingerprint defense reorganization issue: #11770

Currently Brave (like most browsers) will in some configurations report fine-grained information about language preferences in the request Accept-Language header.

For example, setting the system language preference to "French (Switzerland)" sends Accept-Language: fr-FR,fr;q=0.9; setting it to "French (Canadian)" sends Accept-Language: fr-CA,fr;q=0.9. The fr-<WHATEVER> bit ends up being a useful distinguishing bit for fingerprinters.

This issue is to address this fingerprinting concern as follows:

default protection:

• Drop any non-alphabet related variants So, both of the above examples would become fr;q=0.9 (we'd drop fr-FR and fr-CA). Do not drop alphabet variants though (e.g., sr-Latn).
• When there is only one weight (i.e., the q), farble it and report a randomly determined value between 0.5 and 0.9.

max protection:

• always report Accept-Language: en-US,en;q=X.X
• farble the weight / q with a randomly determined value between 0.5 and 0.9.

[pes10k]

@fmarier pointed out that this is likely not a great idea, and that there are cases where the variants are useful. So, more planning is needed for the default protections category. Possibilities include:

1. manually constructing equivalence classes to farble between
2. only reporting the preferred language (and so stripping out 2nd, 3rd etc preferences)

Im going to brain some more on this, see what other browsers are doing, and revise the default protection approach. But farbling the weight, and reporting a fixed value in the max protection category seem like good options never the less 🤞

[fmarier]

For reference, here's how my laptop is set:

LANG=fr_CA.UTF-8
LANGUAGE=
LC_CTYPE="fr_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
LC_COLLATE="fr_CA.UTF-8"
LC_MONETARY=en_CA.UTF-8
LC_MESSAGES="fr_CA.UTF-8"
LC_PAPER=en_CA.UTF-8
LC_NAME=en_CA.UTF-8
LC_ADDRESS=en_CA.UTF-8
LC_TELEPHONE=en_CA.UTF-8
LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION=en_CA.UTF-8
LC_ALL=

and that ends up with the following odd request header:

accept-language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7

navigator.languages is even weirder:

$ navigator.languages
['en_US', 'en', 'fr_CA']

[pes10k]

Additional data:

• I wasn't able to find any information about Firefox reducing the granularity of accept-language. Not sure where i got that idea, maybe i was conflating with Tor (or enabling non-default features in Firefox)
• Safari seems to only, by design, report the most preferred language, as an intentional anti-fingerprinting strategy: https://bugs.webkit.org/show_bug.cgi?id=3510#c27

Safari doing so makes me think this is likely to have acceptable WebComapt implications. We could also create a flag or system preference for this (and possibly align it with font fingerprinting protections) so that users have a global escape valve if needed

[ShivanKaul]

I'm guessing the plan is for it to be opt-out via a setting in brave://settings?

[pes10k]

yep yep!