1869821 - Consider clearing intl.accept_languages when changing app language with RFP

Status: NEW

(Firefox :: Settings UI, enhancement)

Description

[Pier Angelo Vendrame]

The settings UI has already a setting for spoofing English when RFP is enabled.
However, when RFP is enabled but spoof English is disabled, it might be a good idea also to reset intl.accept_languages to its default value when the user changes their app language, otherwise it will be possible to detect a difference between the accepted languages and the app language (e.g., through the formatting API).
Downstream for Tor Browser we are considering even stricter approaches, such as showing only the spoof English checkbox in the "Website Language Settings" modal and forcing intl.accept_languages to its default value when spoof English is disabled.

Comment 1

[Manuel Bucher [:manuel]]

Good analysis in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41930

Comment 2

[Tom Schuster (MoCo)]

I think we should change all users of the intl.accept_language pref to also respect the nsContentUtils::ShouldResistFingerprinting(RFPTarget::JSLocale) API instead. I don't think it's a good idea that privacy.spoof_english permanently changes the intl.accept_language pref.

If we do that we wouldn't need to clear the pref intl.accept_language at all, because it wouldn't have changed.

Comment 3

[Pier Angelo Vendrame]

(In reply to Tom Schuster (MoCo) from comment #2)

I think we should change all users of the intl.accept_language pref to also respect the nsContentUtils::ShouldResistFingerprinting(RFPTarget::JSLocale) API instead. I don't think it's a good idea that privacy.spoof_english permanently changes the intl.accept_language pref.

If we do that we wouldn't need to clear the pref intl.accept_language at all, because it wouldn't have changed.

That's a great idea!
In addition to the problem I reported, there's also a race condition between RFPHelper's pref observer and the UI, which would also be resolved in this way.