User Locale Preferences

[romulocintra]

Introduction

"Find a reliable way to access user OS preferences to craft a better user experience, and improve accessibility over the web"

User preferences are often system-wide settings (such as in Android, macOS, or Windows). Operating systems allow the user to specify custom overrides for settings such as:

• Hour cycle (24-hour or 12-hour time)
• Calendar system
• Measurement unit preferences (metric or imperial)
• Date/time patterns
• Number separators (comma or period)

However, there’s currently no reliable way to access this information from the Web Platform to help craft better user experiences. Allowing web developers to access this information would allow them to improve the accessibility and usability of their websites, and bring the user experience of web applications closer to that of native applications.

• Read the complete Explainer.
• Slide Deck About User Locale Preferences

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.

[tomayac]

This sounds like a natural addition to User Preference Media Features Client Hints Headers, which is modeled after CSS' prefers-* (that is also queryable via JavaScript matchMedia('(prefers-*: *)').matches) and for what an eventing mechanism exists via EventTarget.addEventListener() to be notified of changes. I like it.

The privacy discussion will be interesting, since, as you note, there's currently no way for many of the proposed values to be detected via JS, but of course native apps have access, for example, to determine imperial or metric preference on iOS:

NSLocale *locale = [NSLocale currentLocale]; 
BOOL isMetric = [[locale objectForKey:NSLocaleUsesMetricSystem] boolValue];

[romulocintra]

@tomayac great feedback, thank you.

Following the existing proposals naming pattern [prefers-*](https://drafts.csswg.org/mediaqueries-5/#mf-user-preferences) the Client Hints for Locale Preferences would look like: Sec-CH-Locale-Preferences-calendar -> Sec-CH-Prefers-Calendar, which could align with current + future preferences not only Locale focused ones 👍👍👍.

The privacy part and data available for the end users would be delicate and I expect lots of iteration. So all contributions/ideas/feedback to #3 are welcome

[tomayac]

For inspiration, here's my (customized) "System Settings" from SAP Concur as a proof of user need for this. It annoys me every time I need to teach a US app (SAP is German, but, hey,…) that my week begins on Monday and that I prefer a 24h clock and metric units, despite my system language being en-US.

[romulocintra]

Discussion is open at https://discourse.wicg.io/t/proposal-user-locale-preferences/6133 cc @tomayac @sffc @ben-allen @ryzokuken

[marcoscaceres]

We'd have to be super careful here, as this could turn into a fingerprinting nightmare.

[romulocintra]

Hi @marcoscaceres

We've been socializing different points of view and ways of exposing the data to avoid ending in a fingerprinting nightmare, we are planning to use buckets that reproduce more or less the current OS preferences regarding Language & Region Date & Time and those would be under the "privacy gates" from each host. Do you see any different approach or strategy that might help?

[marcoscaceres]

Depends heavily on the use case: input types that defer to OS will already provide these out of the box (e.g., picking a date from a calendar, and displaying the calendar in the way the user likes it without exposing any private user preference information to the website).

I understand the desire the simply access (or request) this extremely useful information, but I don’t think it’s possible without significant risk to user privacy. If you look at the README, you can see it’s already super identifiable information: that person in London, who uses the such and such calendar, who prefers their emojis like so, etc. etc. basically pin pointing it down to a unique individual.

the buckets also don’t help: they make it even easier to group information. Nice for developers, but not so great for users.

I personally think the right solution might be better input types that mask user preferences from websites. At the same time, for certain class of applications, it may be the case that users will have to themselves volunteer some of this information. @tomayac SAP example, for instance.

That’s also not great because Site A can share those with Site B. However, it’s better than the browser sharing every user preference with every website via a JS API or Client Hint.

[sffc]

I'm all in favor of better input widgets.

However, the use case here is about driving a seamless experience that reflects the user's preferences beyond just language. This is about letting users select their preferred hour cycle (12/24) and then having all web sites (or at least the ones that use Intl.DateTimeFormat) use the correct hour cycle. This is about reflecting the user's preferred calendar and measurement system through web formatting APIs. This is about reducing the need for individual websites to have custom user preference panels. Without a solution in this space, internationalization on the Web platform will continue to be second-class to internationalization in native apps, which can normally access this information.

User privacy is the number 1 concern for this proposal. @romulocintra has been driving discussions to align on the right way to improve i18n on the Web platform but doing so in a way that reduces fingerprinting vectors.

---

I do have a question though. Can this just be a browser setting? Users can opt-in or opt-out of high-privacy mode to disable user preferences as well as other fingerprinting vectors.

[marcoscaceres]

Without a solution in this space, internationalization on the Web platform will continue to be second-class to internationalization in native apps.

Please note that the web is a much more hostile environment. Feature-parity with native is a non-goal because the web platform holds itself to a higher privacy standard.

Can this just be a browser setting? Users can opt-in or opt-out of high-privacy mode to disable user preferences as well as other fingerprinting vectors.

That’s simply shifting the problem to users, which is not really acceptable. Most users won’t understand the consequences that sharing such information would have on their privacy, nor should they need to.

The criteria for exposing any user preference has to provide significant user benefits (see current set exposed via CSS: prefers-reduced-motion, prefers-color-scheme, prefers-contrast, prefers-reduced-transparency, and prefers-reduced-data). And it has to be generalizable enough in a population that it doesn’t meaningfully serve as a fingerprinting vector.

I’d suggest going over each preference and seeing if it can be generalized and if it meets a high value threshold.

[romulocintra]

The criteria for exposing any user preference has to provide significant user benefits (see current set exposed via CSS: prefers-reduced-motion, prefers-color-scheme, prefers-contrast, prefers-reduced-transparency, and prefers-reduced-data). And it has to be generalizable enough in a population that it doesn’t meaningfully serve as a fingerprinting vector.

The importance of ensuring that the criteria for such exposure provide significant benefits to the user while avoiding being used as a fingerprinting vector is key for us, we've been doing the exercise by asking people from the Browser space, and building several use cases(see slides) and additionally, we are researching how opt-in or opt-out options work for similar cases across the web, so we can better understand the implications of the user's choices and experience across OS, Hosts and platforms.

I see this as a two steps problem space:

The first step involves curating user preferences information in a way that doesn't compromise their privacy while providing the best possible web experience. Standardization is key here, and it's important to avoid competing with native platforms but work on giving the best experience. Moreover, the majority of hosts already have access to user preferences, so it's essential to be mindful of potential malicious use of this information.

The second step involves ensuring that the user experience on OS, hosts, or platforms is secure and that users have the freedom to enable preferences that enhance their web experience.

Overall, the importance of balancing user privacy and experience suggests that there is work to be done in securing user information while providing meaningful benefits to users, so I believe this work on user preferences would trigger some questions to help the enhancement of the security/web experience.

[marcoscaceres]

Thanks @romulocintra for the additional context and link to slide. If you haven't already, I'd recommend filling a standards position request on WebKit and Mozilla. I'd also strongly suggest getting some feedback from the PING folks at this early stage.

[hsivonen]

I posted brief summarized remarks on the Mozilla standards-positions issue, but I figured that my more detailed remarks that I wrote down while I was at it are better suited here than in the Mozilla repo’s comments:

For privacy analysis (as well as to understand the value to weight against the privacy issues), it would be helpful to document realistic use cases to understand the (non-)orthogonality of these settings.

The use case that stands out to me from Gecko bug reports (not in the Web context but primarily in Thunderbird UI context) is that en-US is the typical untranslated language for software (i.e. the developers commit en-US UI strings with the source code and then other-language UI strings are translations), so running software with untranslated UI strings (e.g. to run Nightly builds) results in a commonly-understood language but otherwise the U.S. values for the datetime/measurement settings are internationally uncommon. For this scenario, bundling the settings to be flipped to an international state together would reduce the bits of entropy exposed.

Also, the specific setting came up with Gecko previously was hour cycle–not measurement preferences more generally. The slides show Mac and Windows settings, but not Android and Gnome settings, which only cover the hour cycle. Hour cycle is also the motivating example presented in the original ECMA-402 issue. All this suggests that the hour cycle customizability is in particular demand compared to the other settings.

Regarding realistic use cases for understanding importance, the slides show week starting on Thursday, but CLDR data suggests that the practically relevant values for this setting are Monday, Friday, Saturday, and Sunday (with Friday applying only to one region). Also, the slides suggest that "search" might be a legitimate user-settable collation preference value, which it isn't, since “search” is inappropriate for sorting.

In a recent TG2 meeting, it was pointed out to me that there are use cases relevant to India that involve other settings like the numbering system, so a broader view of the use cases might quickly show that bundling won't work.

In the same TG2 meeting, there was a lack of clarity on the expected mechanism for authorizing access to these preferences in the case of privacy considerations meant that these preferences wouldn't be unconditionally exposed to the Web. (Even if the mechanism wasn't normative, the expected mechanism is still relevant to analyzing if the mechanism would be off-putting enough for sites not to bother.)

Having the browser decide how to respond to getHighEntropyValues based on an entropy budget doesn't have cross-engine buy-in.

Asking for explicit consent has implications on what potential uses are important enough for it to be justified for the site to explictly bother the user. Unfortunately, this is somewhat at odds with where this information would be useful to have ambiently. If a user uses a logged-in calendaring Web app, on one hand, fingerprinting is less irrelevant, because there's the login identifier anyway (although fingerprinting is still relevant to matching not-logged-in uses of other sites to that login), and on the other hand, the trouble of telling the Web app once manually that weeks start on a given weekday gets amortized over years of keeping using the same app. However, if the user goes buy tickets for something and is presented with a date picker, it could be useful for the picker to render the columns according to the user's first-day-of-week preference, but the browser can't tell that this is a legitimate use and not an attempt at fingerprinting.

It’s notable that in the example case of a ticket purchase date picker, the site could avoid this specific issue by using the HTML-native browser-rendered date picker with <input type=date>. Overall, it would be worthwhile to consider to what extent use cases that are being addressed here could be addressed in a privacy-preserving way by other kinds of feature designs.

It would be interesting to know how the topic of i18n preferences vs. fingerprintability is generally viewed in Chrome or if Chrome even has a general view on the topic. I observe that Accept-Language reduction is suggestive of a shift towards being less OK with exposing this stuff. CC @miketaylr

Also relevant to Accept-Language: There is the precedent that browsers expose Accept-Language but Google Search still chooses the search UI language by offering the majority language of the region that the IP address of the user geolocates to (to the great annoyance of users for whom that wasn't the right language and whose browser did advertise what would have been the right language). That is, a very, very major site has for years held the position that the designed browser-provided ambient i18n preference exposure mechanism isn't suitable for honoring, which leaves the intended benefits unrealized but the fingerprinting surface remains. How is the capability being contemplated now materially different so that there's a reason to believe that the same dynamic wouldn't repeat? (In fairness, there are apps that pick the UI string translation from the browser-advertised languages. E.g. Jira appears to be like this.)

Furthermore, the spec gives signals that the inclusion of each BCP47 might not have a thorough use case analysis behind it. The current time zone (for better or worse) is already exposed as Intl.DateTimeFormat().resolvedOptions().timeZone, though it may be in this spec for the HTTP part. Going back to bundling, the spec doesn't discuss the relationship of the region override vs. providing the individual field values implied by a region override. The collation flavor is unlike the other fields: It doesn't make sense as a standalone pref but it attaches to a particular language. That is, it doesn't make sense as "traditional" on its own but as e.g. traditional collation for Spanish.

[zcorpan]

Has this proposal been superseded by https://github.com/ben-allen/locale-extensions#readme ?

[ben-allen]

Yes, that's the current version