Open Bug 1746668 Opened 3 years ago Updated 1 month ago

Use web exposed locales instead of regional locales where appropriate

Categories

(Firefox :: Settings UI, enhancement)

Product:
Firefox
Component:
Settings UI
Version:
Firefox 97
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: thorin, Assigned: pierov)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

example-diff.png
90.94 KB, image/png
Details
Attached image example-diff.png —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Notes

  • Bug 1635561 (FF85) changed from AppLocale to RegionalPrefLocales
  • javascript.use_us_english_locale only caters for english users (specifically en-US, see Bug 1671850)
  • Bug 1039069 (privacy.spoof_english) is used to help flip javascript.use_us_english_locale

Actual results:

Insufficient FP protection

  • RFP only caters for setting en-US, en as language
  • RFP allows RegionalPrefLocales to be applied (except when spoof_english is triggered and turned on)
  • this is fingerprintable
    • e.g. without flipping javascript.use_us_english_locale manually, formatting leaks entropy
  • example
    • intl.regional_prefs.use_os_locales is default false
    • en-US build on english (but not en-US) OS in english (but not en-US) region
    • see pic

Expected results:

Proposed

when RFP is enabled

  • ignore intl.regional_prefs.use_os_locales
  • Intl. should use AppLocale
  • this will then make all users the same per language = equivalency
  • we still keep spoof_english (to encourage users to use the most common result in Firefox AFAICK from usage stats) but remove the need to flip javascript.use_us_english_locale

This should be easy to hook up given unified Intl changes (but IANAE)

Component: Untriaged → Preferences

ugh example pic right hand side is RFP + javascript.use_us_english_locale

Status: UNCONFIRMED → NEW
Ever confirmed: true

I think this might as simple as fixing resolvedOptions - only Collator seems to follow nav language, the others don't

(In reply to Simon Mainey from comment #2)

I think this might as simple as fixing resolvedOptions - only Collator seems to follow nav language, the others don't

only Collator seems to follow nav language sorry, typo in my array slice ... they're all the same: i.e regional

I think this might be as "simple" as replacing [1] https://searchfox.org/mozilla-central/source/js/xpconnect/src/XPCLocale.cpp#131-133 with a RFP check to return JS_SetDefaultLocale(rt, navigator.language);

  • and update/add tests
  • and remove javascript.use_us_english_locale flipping in RFP's spoof_english
  • and make sure intl.regional_prefs.use_os_locales is ignored

Test: https://arkenfox.github.io/TZP/tests/formatting.html

control test

  • de build on my-real-locale system
  • about:support
    • Application Settings > Regional Preferences = ["de","en-US"]
    • ^ Anwendungseinstellungen > Region-Einstellungen
  • test shows no diffs

change language test

  • en-US build on my-real-locale system
  • about:support
    • Application Settings > Regional Preferences = ["my-real-locale"] (it is not de)
  • add de to first preferred language
  • test shows diffs

IDK if Application Settings > Regional Preferences ever changes, but the change proposed should always ensure that the correct formatting is always used

Flags: needinfo?(andrebargull)

JS_SetDefaultLocale(rt, navigator.language);

I don't think you should use navigator.language as a source. You may want to use Services.locale.appLocales vs regionalPrefsLocales depending on RFP.

we should also make sure other spoof_english patches are covered for all locales, such as Bug 1492587

is andre the wrong person? Would be nice to have this in time for ESR102

Flags: needinfo?(andrebargull)

(In reply to Simon Mainey from comment #7)

What Tor Project did

Hello!

I have changed Tor Browser's patch to use the RFP preference (https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/293) and I am willing to upstream it.

The code seems okay, but could you please tell me how you created the attached image?

I would like to test that the patch still works as intended also in the use case you found before asking to upstream it (and compare it with what Firefox does).

Thanks!

Flags: needinfo?(simon.mainey)

pier, you can get the same results using https://arkenfox.github.io/TZP/tests/formatting.html

Flags: needinfo?(simon.mainey)

ugh .. original data was taken from https://arkenfox.github.io/TZP/tzp.html#language (expand details) and then all I did was diff compare

Avoid regional OS locales if the pref
intl.regional_prefs.use_os_locales is false but RFP is enabled.

The patch actually is ready.
I have set it as WIP because I need a reviewer for it...

Assignee: nobody → pierov
Status: NEW → ASSIGNED
Attachment #9277279 - Attachment description: WIP: Bug 1746668: Avoid using regional OS locales → Bug 1746668: Avoid using regional OS locales r=jfkthame

(In reply to Simon Mainey from comment #7)

What Tor Project did

As noted by Jonathan in their patch review, the patch I proposed checks for intl.regional_prefs.use_os_locales first, and for RFP only later, which is not what you proposed in comment 0.

I think that the reason was either giving users the possibility to keep using that feature, if they really wanted to (the pref is disabled by default), or limiting the changes the patch did to the code for maintenance purpose.
So, I have updated the patch to use RFP, but otherwise kept this behavior as the people who worked on Tor Browser before me did.

Could you please tell me what would be the reasons to give precedence to resist fingerprinting, or to keep it to intl.regional_prefs.use_os_locales?
I can speculatively think:

  • RFP should have/usually has the highest priority preference, to protect users from possible misconfigurations (but I do not know what the usual choices are)
  • intl.regional_prefs.use_os_locales is false by default, so a user enabling both it and RFP should be an advanced user who knows what they do

but I do not have any preference, and both would work for me.

Thanks!

Flags: needinfo?(simon.mainey)

so a user enabling both it and RFP should be an advanced user who knows what they do

Not in my book :) RFP users (Firefox, not Tor Browser so much) constantly want to be able to override prefers-color-scheme, zoom being reset, timezone returned as UTC0 (I get this one though, it can be a pain, which is where tom's fine grain cuts and exceptions will come in), and more. RFP users are not FPing experts. This is also exposed in the UI, no advanced users required to screw it up : General > Language > Use your OS system settings for <your language> to format dates, times, numbers and measurements

I would prefer RFP lock it down (and we should do that in more instances where RFP it is used IMO as well)

Flags: needinfo?(simon.mainey)

Okay, thanks for clarifying that for me ☺️!
I will update the patch later.

When resist fingerprinting is enabled, enforce the use of the
application's locale, to avoid potential fingerprinting based on
JavaScript formatting APIs.

Attachment #9277279 - Attachment is obsolete: true
Attachment #9277793 - Attachment description: Bug 1746668: Avoid using regional OS locales r=jfkthame → Bug 1746668: Avoid using regional OS locales when resist-fingerprinting is enabled. r=jfkthame

I am not super certain if I remember the attribute division fully, but it feels weird. Regional Prefs Locales is a attribute used primarily for Firefox UI, not for websites. For web content (which is where fingerprinting is a concern) the webExposedLocales should be used - https://firefox-source-docs.mozilla.org/intl/locale.html#web-exposed-locales

So this PR seems to be introducing a change to how Firefox UI is rendered for resist fingerpriting users. If I'm correct that it seems like a wrong solution.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #18)

I am not super certain if I remember the attribute division fully, but it feels weird. Regional Prefs Locales is a attribute used primarily for Firefox UI, not for websites. For web content (which is where fingerprinting is a concern) the webExposedLocales should be used - https://firefox-source-docs.mozilla.org/intl/locale.html#web-exposed-locales

So this PR seems to be introducing a change to how Firefox UI is rendered for resist fingerpriting users. If I'm correct that it seems like a wrong solution.

What you say makes sense.
Also, the class that calls GetRegionalPrefsLocales for formatting has been renamed to AppDateTimeFormat (Bug 1715892).

privacy.spoof_english works as expected, therefore I suppose there is a better place to address this bug.
I will look for it and propose a better patch.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:pierov, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Flags: needinfo?(pierov)
Flags: needinfo?(jfkthame)

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Assignee: nobody → pierov
Status: NEW → ASSIGNED
Flags: needinfo?(jaws) → needinfo?(pierov)

I am working on bug 1846224 and I am planning to implement the new language spoofing feature in a way that makes is possible to not just spoof en-US, but any locale string.

Like Zibi I don't think we need to change GetRegionalPrefsLocales, while it's currently used for the JavaScript locale, we can either switch that caller to webExposedLocales or just always use the newly introduced locale spoofing.

Depends on: 1846224

    I believe the JavaScript locale should be just derived from "intl.accept_languages":
    |*| Taking the first value of the Accept-Language value list.
    |*| In case of parsing failure: assert "en".

    This should work perfectly for every practical use case: 0 unwanted effect, typically.

(In reply to Master ? [:masterquestionable] from comment #25)

    I believe the JavaScript locale should be just derived from "intl.accept_languages":

This bug is not about default Firefox behavior. This is about a behavior with privacy.resistFingerprinting enabled, i.e. Tor Browser. They are unlikely to depend on intl.accept_languages because it is very fingerprintable.

    My comment is specifically about the spoofing behavior.
    See [ https://bugzilla.mozilla.org/show_bug.cgi?id=1870172 ] for further details.

    Fingerprintable or not, the remote sites get it anyway.
    Effectively rendering the later spoofing pointless.

Hello again!
For Tor Browser we've recently checked the developments between ESR 115 and ESR 128.

Bug 1846224 removed the javascript.use_us_english_locale setting mentioned in this Bug's description, and introduced RFPTarget::JSLocale which is equivalent to privacy.spoof_english == 2.
However, I think there should be another target to limit locale fingerprintability also when spoof English is off.
In particular, we think any regional variation in use in the OS should be ignored by the browser (e.g., if the OS is in es-AR and the browser is in es-ES, if spoof English is off, the Intl API should use es-ES, not es-AR).
There are ways to get the app language (e.g., by checking the form validation messages or XML errors).

Comment 18 suggested to use web exposed languages instead of GetRegionalPrefsLocales.
I think it's a good idea and that we could repurpose this Bug for this (and drop my current patch), but currently this method used only for the date picker.
I found these possible places where we could add a call, after checking ShouldResistFingerprinting with a new RFPTarget or with a parameter that specifies if the languages are needed for web content:

Also, I think the current JSLocale target should be renamed while doing so, to explain it's actually about spoof English.

I could provide some patches for this, but I'd like to hear what is the general consensus about this proposal first.
Should I NI someone in particular?

Flags: needinfo?(pierov)
Flags: needinfo?(jfkthame)
Attachment #9277793 - Attachment is obsolete: true
Summary: replace javascript.use_us_english_locale with RFP for all locales → Use web exposed locales instead of regional locales where appropriate

This sounds good to me. I'm ping Zibi to start, he's probably the main person but if he suggests anyone else we can add them.

Flags: needinfo?(zibi)

How about you use just a language in that case? I'm slightly concerned about ignoring OS locales since it is not set by default - so if a user intentionally set "follow OS locales" and then "protect me from fingerprinting" using es-ES instead of es-AR seems wrong.

If we instead said if prevent fingerprinting is on we will only communicate language then we reduce the fingerprinting.

The practical impact is that an Australian user en-AU with RFP will get en.

Flags: needinfo?(zibi)

    I believe the interface language and content language shall be 2 separate things.
    As in: https://ar.wikipedia.org/?uselang=en

    Warn whomsoever tries to reveal their content language preference.
    As for interface one, shouldn't matter at all. (only locally used)

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #30)

How about you use just a language in that case? I'm slightly concerned about ignoring OS locales since it is not set by default - so if a user intentionally set "follow OS locales" and then "protect me from fingerprinting" using es-ES instead of es-AR seems wrong.

If we instead said if prevent fingerprinting is on we will only communicate language then we reduce the fingerprinting.

The practical impact is that an Australian user en-AU with RFP will get en.

That would work for me, but for some cases the regional information matters a lot, and two languages should be considered completely different if they have different regions.
That should be the case for Chinese (if I understand correctly).
If we had a list of regions that should be exposed the OS region problem might remain.

As for the UI, I think usually it's more or less expected that RFP might override some values.
What if we forced the value for OS locales to be off (like privacy.spoof_engliish equal to 2 changes the value of intl.accepted_languages) and disable it when RFP is on?
Or, could that checkbox control also the RFPTarget we'd use for this kind of protection with FPP (even though I'm especially interested about the RFP case)?

OK, so there were a number of things here (ignore spoof english)

  • first: the language(s)
    • TB controls the app language options and has listeners etc for setting languages (intl.accept_languages)
    • TB removed the UI so users can't change the order or add/remove languages
  • note: TB restricts the language list to basically one of each: i.e one english (en-US), one spanish (es-ES), etc
    • that said, exposing more is not an issue: e.g. pt-PT is divergent enough from pt-BR to warrant it's own option
  • based on the language we set the locale to match
    • we also hide the option to "use OS locale/formatting" from the UI - but would like to make this ignored in code (see Bug 1823580)
    • controlling the locale sets all resolvedOptions which is always the same for all Intl APIs (there's an issue open about this)
    • we also control the timezone name
    • this make languages (including lang headers), locale, and all Intl. and datetimes and formatting (and to*String) deterministic and reduces entropy to equivalency of language (language being tightly controlled)

This means (desktop)

  • all english users are en-US, en with en-US locale
  • all hebrew users are he, he-IL, en-US, en with he locale
  • etc: the default languages and their order per app language are all hardcoded somewhere
  • android seems to do it's own thing

So absolutely, IMO, decisions should stem from the set language. How you work that into FF with more languages including regional as options, and a UI for changing it all as well, and marry that with RFPTargets is messy, to say the least

Also, not resetting intl.accept_languages when spoof english is changed from 2, caused a years long regression in TB - That needs uplifting somewhere. And no an issue for TB, but spoof_english doesn't prompt on all non-en-US, because it only checks for en*, not specifically for en-US.

    Accept-Language is a mere string...
    Why over-complexity?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: