1303579 - Expose navigator.locales and add onlocaleschange event

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

In multiple places[0] we need to generate a list of languages with added extension keys for user-selected settings that affect localization, like:

 - hour12/hour24
 - calendar system
 - currency
 - etc. [1]

A proposal in ECMA 402 [2] is to add a counterpart to navigator.languages in form of `navigator.locales`.

`navigator.locales` would have the same list of language codes but would add extension keys based on user preferences defined in the host environment.

For example, if `navigator.languages == ["fr", "en-US"];` and the user defined hour12 parameter in their US, navigator.locales would return `navigator.locales == ["fr-u-hc-h12", "en-US-u-hc-h12"];`.

This list can be directly fed into Intl APIs to produce the correct date time format, collation, or number taking into account user defined preferences.

`onlocaleschange` would be fired whenever language fallback chain changes, or one of the affected settings changes.


[0] bug 1069609 comment 55
[1] Full list available here: http://www.unicode.org/reports/tr35/#Locale_Extension_Key_and_Type_Data
[2] https://github.com/tc39/ecma402/issues/68

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Initially the API would be chrome-only, but I'd put it on the WHATWG+ECMA402 standardization path and use our internal use as a method to refine the proposal.

Comment 2

[Henri Sivonen (:hsivonen)]

Has this undergone privacy review? It may not be obvious to users that customizing 12/24 clock and such, especially on the OS level, would make them more fingerprintable on the Web.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

There is a conversation about fingerprinting consequences in ECMA402 issue: https://github.com/tc39/ecma402/issues/68

I also emailed :fmarier, :huseby and :tanvi and got a tentative "go ahead".

I'll draft more specific proposal for how would it work and NI people to get their approval here as well.

To your point:

At the same time, the very same users would expect that if they set hour12/hour24 manually overriding their locale default, apps they use will follow. (same goes for date format, timezone etc.)

As :littledan quoted:

> Believes that, because combatting fingerprinting is difficult, new Web specifications should take reasonable measures to avoid adding unneeded fingerprinting surface area. However, added surface area should not be a primary factor in determining whether to add a new feature.

Comment 4

[Arthur Edelstein [:arthur]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #3)
> There is a conversation about fingerprinting consequences in ECMA402 issue:
> https://github.com/tc39/ecma402/issues/68
> 
> I also emailed :fmarier, :huseby and :tanvi and got a tentative "go ahead".
> 
> I'll draft more specific proposal for how would it work and NI people to get
> their approval here as well.
> 
> To your point:
> 
> At the same time, the very same users would expect that if they set
> hour12/hour24 manually overriding their locale default, apps they use will
> follow. (same goes for date format, timezone etc.)
> 
> As :littledan quoted:
> 
> > Believes that, because combatting fingerprinting is difficult, new Web specifications should take reasonable measures to avoid adding unneeded fingerprinting surface area. However, added surface area should not be a primary factor in determining whether to add a new feature.

I would like to suggest that this feature be disabled or otherwise sanitized for privacy when the "privacy.resistFingerprinting" pref is set to true. Examples of other such sanitized features are here:
https://dxr.mozilla.org/mozilla-central/search?q=nsContentUtils%3A%3AShouldResistFingerprinting&redirect=false

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

> I would like to suggest that this feature be disabled or otherwise sanitized for privacy when the "privacy.resistFingerprinting" pref is set to true

Sounds perfectly reasonable.

My idea was to also add a separate flag that can be turned off. Maybe even preferences option like "Expose system preferences to web authors".

If the preference/flag is set to "true" (default), we will expose hour12, custom date format, calendar selection etc. If the flag is set to false, we would only expose it in chrome content, and hide in web content.

What I like about this approach is that the way we're designing the API makes it indistinguishable between "user did not set a preference" and "browser did not expose the preference".

Comment 6

[Arthur Edelstein [:arthur]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #5)
> > I would like to suggest that this feature be disabled or otherwise sanitized for privacy when the "privacy.resistFingerprinting" pref is set to true
> 
> Sounds perfectly reasonable.
> 
> My idea was to also add a separate flag that can be turned off. Maybe even
> preferences option like "Expose system preferences to web authors".

I think that matches the intention of "privacy.resistFingerprinting", which is "When true, don't expose system attributes to content." Of course it's fine (and better) to continue exposing such APIs to chrome.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Oh, cool!

I expected "resistFingerprinting" to be broader than user preferences, but maybe we just don't need a more specific pref and we can use this one.

The more I think about it the more I like the idea of adding a preference checkbox for this pref. :)

Comment 8

[Arthur Edelstein [:arthur]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7)
> Oh, cool!
> 
> I expected "resistFingerprinting" to be broader than user preferences, but
> maybe we just don't need a more specific pref and we can use this one.
> 
> The more I think about it the more I like the idea of adding a preference
> checkbox for this pref. :)

I do too! I've just written a patch to add one in Tor Browser (in about:preferences#privacy), so maybe it can be uplifted to Firefox.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Please, file a bug and attach the patch and let's get UX people on it.

Comment 10

[Arthur Edelstein [:arthur]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #9)
> Please, file a bug and attach the patch and let's get UX people on it.

Here it is: bug 1308340.