1746815 - RFP: only return the first language in header and navigator.languages

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!