1746815 - RFP: return deterministic (default) languages in header and navigator

Status: NEW

(Firefox :: Settings UI, enhancement)

Description

[Thorin [:thorin]]

Steps to reproduce:

The Issue

When a user has multiple languages, such as adding additional ones and where order matters, this adds entropy to the fingerprint in both the Accept-Language header and in navigator.languages.

RFP currently only caters for asking users if they would like to spoof as English when they are not already en* and when accepted, it sets languages to en-US,en (and flips another pref to preserve en-US locale for formatting) - this is not perfect either, see Bug 1671850 (spoof_english misses some languages, it should check for en-US,en) and Bug 1746668 (why only protect en-US locale for formatting)

Actual results:

Proposed

Example: multiple languages set such as en-US, en, fr-FR

Only return the first language when RFP is enabled in

• navigator.languages
  • return en-US [this is what android returns]
  • instead of en-US,en,fr-FR
• Accept-Language
  • return en-US [this is what android returns]
  • instead of en-US,en;q=0.7,fr-FR;q=0.3
  • Note: the q-factor weighting becomes obsolete

Note: Bug 1653338 where android returns en-US but desktop returns en-US,en

Doesn't cover

Users changing the order from say en-US,en to en,en-US
Users removing en-US and only leaving en?

I consider this out of scope of this ticket unless it would lead to breakage, or could be easily factored in

Risk

None. Gated behind non-facing RFP pref

Expected results:

Extra

[1] https://github.com/brave/brave-browser/issues/20096#issuecomment-994155928

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. [snip]

Comment 1

[Thorin [:thorin]]

title: Who Touched My Browser Fingerprint?: A Large-scale Measurement Study and Classification of Fingerprint Dynamics
url: https://dl.acm.org/doi/10.1145/3419394.3423614
pdf: https://yinzhicao.org/fpmeasurement/imc20.pdf

Table 1, page 5: static values' distinct groups

• font list 115k
• user agent 41k
• plugins 16k (not a FF issue)
• language header 14k
• canvas 14k
• GPU renderer 5.7k
• GPU type 5k
• pixel ratio 2k
• language list 1.2k
• audio 114

Comment 2

[Negritas Sergiu, Desktop QA]

Hello! Thank you for submitting this issue. I will mark this issue as NEW in order for our developers to look more into it and take this issue into consideration on further firefox releases.

Have a nice day!

Comment 3

[Thorin [:thorin]]

some updates

• https://github.com/explainers-by-googlers/reduce-accept-language
• https://github.com/brave/brave-browser/issues/47025 - it's in chrome 138 and brave might flip it on
• https://github.com/mozilla/standards-positions/issues/1014

my initial proposal 4 years ago for FF RFP users was to return just the first language (and obviously q=1 and match in navigator), and we would want to return the first variant i.e en-US, not en - but I also know from other/previous bugzillas that at least in the case of english, without the second language as fallback, some sites break (I think this came up in android) - i.e en-US, en works better.

• i.e I think a single language is not going to work - AFAIK every default app lang setup has the 2or3 char language code and the variant,a dn if not english, at least en in the fallbacks

That said, Firefox has a UI that allows users to change the order of, and add/remove preferred web-content languages. In Tor Browser we removed the UI as it is problematic, and enforced the default (in intl.accept_languages) for each app language supported and for spoof_english

So currently Tor Browser doesn't need anything, but FPP could do something: i.e restrict the language which in turn dictates the locale (to match).

going to ping/cc tom, and fkilic who did some locale work recently to close (or hijack) this issue .. also Eemeli FYI (hi)

Comment 4

[Fatih Kilic [:fkilic]]

The original bug sounds very similar to the work in bug 1976220.

This is just my opinion but with reduce-accept-language, negotiating languages is a bit weird, and I feel like it can still be exploited with multiple page visits. I love the idea of Avail-Languages header though. If the websites told the browser the languages the content is available in, then the browser could just show a prompt asking if the user wants to switch languages, and it will be more involved cutting the potential for learning locales over multiple page visits and the weird language negotiation mechanism, but again, this is just my opinion, others can probably asses this proposal better than me.