22835 2013-07-30 01:18:02 +0000 window.navigator.language should not return "en" for privacy protection 2016-04-25 23:57:56 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED WORKSFORME P2 normal --- 1 w3-bugs dave.null bzbarsky duerst hsivonen mike mounir public-html-admin public-html-wg-issue-tracking robin srl travil w3c www-international public-html-bugzilla oldest_to_newest 91400 0 w3-bugs 2013-07-30 01:18:02 +0000 Section 6.5.1.2 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|. 91401 1 bzbarsky 2013-07-30 01:26:44 +0000 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 ""? 91402 2 w3-bugs 2013-07-30 01:57:39 +0000 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. 91403 3 bzbarsky 2013-07-30 02:20:02 +0000 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. 91405 4 srl 2013-07-30 05:41:33 +0000 (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 ? http://www.loc.gov/standards/iso639-2/php/code_list.php 91408 5 duerst 2013-07-30 08:03:41 +0000 "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 "". 91419 6 w3-bugs 2013-07-30 18:02:51 +0000 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. 91835 7 mounir 2013-08-09 14:32:14 +0000 Why do we need to make navigator.language return a fake value while we already provide more information in the HTTP headers? 91983 8 hsivonen 2013-08-13 12:47:36 +0000 (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. 92862 9 robin 2013-09-03 12:27:25 +0000 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? 126143 10 travil 2016-04-25 23:57:56 +0000 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: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!