W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Proposal: Locale Preferences API

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 31 Jan 2014 21:58:01 +0000 (UTC)
To: Jungshik Shin (, ) <jshin@chromium.org>, Boris Zbarsky <bzbarsky@MIT.EDU>
Message-ID: <alpine.DEB.2.00.1401312156360.26647@ps20323.dreamhostps.com>
Cc: WHATWG Proposals <whatwg@lists.whatwg.org>
On Thu, 12 Dec 2013, Jungshik Shin (, ) wrote:
> 2013/11/27 Boris Zbarsky <bzbarsky@mit.edu>
> > On 11/27/13 4:28 PM, Jungshik Shin (, ) wrote:
> >
> >> That is, I suggest that 'navigator.language' always be the UI 
> >> language of a web browser.
> >
> > That's an unacceptable privacy leak from Mozilla's point of view.  
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we 
> > explicitly switched from that to basing navigator.language on the 
> > Accept header.
>
> Well, the vast majority of users would never touch A-L list. So, the top 
> entry in the A-L list would remain the default value, which is usually 
> the UI language. So, I don't know how much your change helps privacy if 
> revealing the UI language is indeed a valid privacy concern.

On Fri, 13 Dec 2013, Boris Zbarsky wrote:
> 
> The point is, the Accept-Languages header already reveals whatever it 
> reveals, so there is no additional privacy leak from navigator.language 
> if you just mirror what the header.  And for people who _do_ change the 
> A-L list, they get it picked up in both places automatically.

It does seem reasonable that the three APIs (the header and the two IDL 
attributes, one giving one value and the other a list) would expose the 
same information, or at least subsets thereof (for the single value one).

Jungshik, is there any particular reason for _not_ doing this?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 31 January 2014 21:58:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC