This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22835 - window.navigator.language should not return "en" for privacy protection
Summary: window.navigator.language should not return "en" for privacy protection
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2013-07-30 01:18 UTC by Norbert Lindenberg
Modified: 2016-04-25 23:57 UTC (History)
12 users (show)

See Also:


Description Norbert Lindenberg 2013-07-30 01:18:02 UTC
Section Language preferences has the recommendation "user agent implementors are encouraged to return 'en' unless the user has explicitly indicated that the site in question is allowed access to the information."

"en" is the wrong value to recommend here. "en" is a valid language tag, but not the preferred language of the majority of internet users. If user agents started following the recommendation to return "en" for users whose preferred language is not English, then applications would have to treat "en" as meaning "undefined", i.e., stop providing English-speaking users with their preferred language.

If a user agent wants to protect the user's privacy by not providing the user's real preferred language, then it should simply return |undefined|.
Comment 1 Boris Zbarsky 2013-07-30 01:26:44 UTC
Returning undefined is very likely to break pages that use string methods on the return value (e.g. navigator.language.charAt(0) or whatnot).  We want a default value that's a string; perhaps ""?
Comment 2 Norbert Lindenberg 2013-07-30 01:57:39 UTC
Internet Explorer up to at least version 10 doesn't have navigator.language, so at this point applications have to deal with it being undefined.
Comment 3 Boris Zbarsky 2013-07-30 02:20:02 UTC
Except to the extent that they do sniffing and take different codepaths in different browsers, of course...

We've been bitten far too many times by making something undefined that was already undefined in some one browser and pages suddenly breaking.

But more importantly, think about the situation a few years from now when all UAs return strings except the ones that are implementing the encouragement from the spec (which I expect to be minority UAs).  At that point, those UAs would almost certainly have to return "" (violating this spec) due to compat concerns, assuming the property gets used at all.
Comment 4 Steven R. Loomis 2013-07-30 05:41:33 UTC
(In reply to comment #0)
> If a user agent wants to protect the user's privacy by not providing the
> user's real preferred language, then it should simply return |undefined|.

How about "und" = Undetermined ?
Comment 5 Martin Dürst 2013-07-30 08:03:41 UTC
"und" would work, and so would "" (which is used in XML and HTML to "switch off" outer lang/xml:lang settings for inner structure). I'd personally prefer "".
Comment 6 Norbert Lindenberg 2013-07-30 18:02:51 UTC
If the concern is that applications use the value of navigator.language without any checking, then "und" is better than "". "" is not a valid BCP 47 language tag and will result in exceptions when passed to methods in the ECMAScript Internationalization API.
Comment 7 Mounir Lamouri 2013-08-09 14:32:14 UTC
Why do we need to make navigator.language return a fake value while we already provide more information in the HTTP headers?
Comment 8 Henri Sivonen 2013-08-13 12:47:36 UTC
(In reply to comment #0)
> If a user agent wants to protect the user's privacy by not providing the
> user's real preferred language, then it should simply return |undefined|.

This makes the user more special (i.e. trackable) than if the user was hiding in the "en" crowd.
Comment 9 Robin Berjon 2013-09-03 12:27:25 UTC
Is it common for browsers to return "en" currently? I don't believe I ever configured any of mine for this, but they all return either en-US or en-GB.

Is there really an "en" crowd to hide in?
Comment 10 Travis Leithead [MSFT] 2016-04-25 23:57:56 UTC
HTML5.1 Bugzilla Bug Triage: Works for me. Spec currently gives this advice:

> If the user is using an anonymizing service, then the value "en-US" is suggested; if all users of the service use that same value, that reduces the possibility of distinguishing the users from each other.

Are folks still interested in returning the empty string?

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: where it will be re-triaged. Thanks!