1823580 - Act as though intl.regional_prefs.use_os_locales is false when RFP is enabled

Status: NEW

(Core :: DOM: Security, enhancement)

Description

[Tom Ritter [:tjr]]

It was pointed out that intl.regional_prefs.use_os_locales can be set to True to ask the OS to format things (dates, not sure what else.)

When RFP is enabled, we shouldn't be asking the OS to do anything, and we should be behaving deterministically. I'm not sure if locking this pref to false is sufficient, or if we need to dig a layer deeper (the docs imply that just because the pref is false doesn't mean that we won't use OS formatting, only that if it is true we definitely will.)

Comment 1

[Pier Angelo Vendrame]

(In reply to Tom Ritter [:tjr] from comment #0)

It was pointed out that intl.regional_prefs.use_os_locales can be set to True to ask the OS to format things (dates, not sure what else.)

When RFP is enabled, we shouldn't be asking the OS to do anything, and we should be behaving deterministically. I'm not sure if locking this pref to false is sufficient

I can answer this.
In Tor Browser 14.0a1 our patch to absolutely not leak regional locales from the OS broke.
The result was that my English GB VM reported en-GB in the resolved Intl options with an en-US browser even when intl.regional_prefs.use_os_locales was set to false.
In general, the Intl API automatically matches the OS region when the language part is the same. I tested also with browser the browser set in it (which is it-IT) in an it-CH OS. Intl reported it-CH. Same for various es-....
Bug 1746668 is about a very similar topic.

Comment 2

[Thorin [:thorin]]

pier - see https://bugzilla.mozilla.org/show_bug.cgi?id=1739712#c5

Soo, we devised this slightly sophisticated system where if the language portion of your OS locale matches langauge portion of Firefox locale (for example "en-US" and "en-GB"), then we will use the region portfion of your OS locale in Firefox.

FF setting the locale based on the app lang + OS's locale is a different thing

• e.g. installing en-US on my en-GB system gives me en-GB locale because of en is the shared language portion

This issue is about not using the OS locale's formatting, which could be customized or differ from the bundled ICU

Comment 3

[Fatih Kilic [:fkilic]]

Doesn't Tor use privacy.spoof_english = 2? That fixes the problem no?

Comment 4

[Fatih Kilic [:fkilic]]

Attachment: WIP: Bug 1823580: Disable matching locale subtags

Comment 5

[Fatih Kilic [:fkilic]]

I just submitted a patch (marked as WIP) disabling matching subtags, and checked Tor's prefs, and it seems privacy.spoof_english is set 0. Why is it set that way?

edit: Apparently non-english users see a prompt about switching it. So privacy.spoof_english is set to 2 only when needed (non en-subtag locale) it seems.

Comment 6

[Pier Angelo Vendrame]

Yes, we let users expose their actual language if they wish to do so.
It possibly creates a lot of buckets, but we (well, someone in the past before my time, but it's likely the right choice) decided that enforcing spoof English was too bad for the UX.

Regarding the patch, we have a similar patch, and I tried to upstream it in Bug 1746668.
However, it hasn't been landed because that will affect also the chrome.
So, I thought it could be a good idea to use the web exposed locales more (please, see my comments in the other Bug).

Comment 7

[Tom Ritter [:tjr]]

If I understand correctly, Tor doesn't need this patch (because they do something different) and it won't be relevant for FPP, so we can keep it around for potential future use/reference but don't need to try and land it now.

Comment 8

[Pier Angelo Vendrame]

(In reply to Tom Ritter [:tjr] from comment #7)

If I understand correctly, Tor doesn't need this patch (because they do something different) and it won't be relevant for FPP, so we can keep it around for potential future use/reference but don't need to try and land it now.

We have a patch to forcefully skip that pref: https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/f286bd088cfae53ac20475a1f081125f959acd54
I tried to uplift it as a solution to Bug 1746668, but the problem is that it doesn't have a context, so chrome isn't exempted from it (same for the other RFP/FFP exemptions).
I amended the original Bug to propose a fix that might work both for Firefox and for us downstream, but I didn't have any time to prepare a patch for that.