Bug 163220 – Add support for Navigator.languages attribute

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Chris Dumez]

Add support for Navigator.languages attribute:
- https://html.spec.whatwg.org/#navigatorlanguage

Firefox and Chrome already support this.

[Chris Dumez]

Created attachment 291122 [details]
Patch

[Sam Weinig]

Does this expose additional information that is not already available to pages?

[Chris Dumez]

(In reply to comment #2)
> Does this expose additional information that is not already available to
> pages?

I believe so, I think we've only exposed the first language so far. Chrome and firefox already support this though.

[Sam Weinig]

(In reply to comment #3)
> (In reply to comment #2)
> > Does this expose additional information that is not already available to
> > pages?
> 
> I believe so, I think we've only exposed the first language so far. Chrome
> and firefox already support this though.

Hm, then I don't think we should support this, at least so completely.  Perhaps we should just return the first language, to limit the tracking surface area.

[Chris Dumez]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Does this expose additional information that is not already available to
> > > pages?
> > 
> > I believe so, I think we've only exposed the first language so far. Chrome
> > and firefox already support this though.
> 
> Hm, then I don't think we should support this, at least so completely. 
> Perhaps we should just return the first language, to limit the tracking
> surface area.

Limiting to 1 makes this API completely useless as it brings nothing compared to navigator.language. This is useful API for anyone who can understand more than one language (as the WebSite may not support their primary language but may support their secondary language.

Limiting to 1 (and maybe always return en-US) in private sessions seems like a good idea. For regular sessions, I think exposing 2 languages would be a minimum to make this API of any use at all.

[Sam Weinig]

Comment on attachment 291122 [details]
Patch

r-ing until we can have further conversations about the privacy impact of this.

[Brent Fulgham]

(In reply to comment #6)
> Comment on attachment 291122 [details]
> Patch
> 
> r-ing until we can have further conversations about the privacy impact of
> this.

I agree with Sam here. The fingerprinting opportunities here are significant; it seems like we need a way for users to choose whether to expose this information or not.

[Chris Dumez]

I checked what HTTP headers we send to the server and it appears we only send the first language in HTTP headers. Therefore, it seems this API would indeed expose extra information that could be used for fingerprinting.

As a result, my plan is to:
1. Implement this API (for compatibility with other browsers) but only expose 1 language in the array.
2. Implement firing of a languagechange event whenever the default language changes (again to match other browsers and match the HTML specification).

Let me know if you disagree with this plan.

[Chris Dumez]

Created attachment 291147 [details]
Patch

[Darin Adler]

Comment on attachment 291147 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=291147&action=review

> Source/WebCore/page/NavigatorBase.cpp:144
> +    return { defaultLanguage() };

I suggest adding a comment here explaining why there is only a single language.

In the early days of WebKit I made Accept-Language contain the entire languages list from Mac System Preferences. But way back then, we scaled back to a single language because of website compatibility problems with servers that had difficulties when we sent anything other than a single language. You can see the history where we kept scaling back more and more until it was just one language.\\

Many years later the possibility of fingerprinting became a reason to stick with that behavior.

> LayoutTests/imported/w3c/web-platform-tests/html/dom/interfaces-expected.txt:5410
> +FAIL Navigator interface: window.navigator must inherit property "languages" with the proper type (10) Unrecognized type [object Object]

What does this failure mean?

[Chris Dumez]

(In reply to comment #10)
> Comment on attachment 291147 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=291147&action=review
> 
> > Source/WebCore/page/NavigatorBase.cpp:144
> > +    return { defaultLanguage() };
> 
> I suggest adding a comment here explaining why there is only a single
> language.
> 
> In the early days of WebKit I made Accept-Language contain the entire
> languages list from Mac System Preferences. But way back then, we scaled
> back to a single language because of website compatibility problems with
> servers that had difficulties when we sent anything other than a single
> language. You can see the history where we kept scaling back more and more
> until it was just one language.\\
> 
> Many years later the possibility of fingerprinting became a reason to stick
> with that behavior.
> 
> > LayoutTests/imported/w3c/web-platform-tests/html/dom/interfaces-expected.txt:5410
> > +FAIL Navigator interface: window.navigator must inherit property "languages" with the proper type (10) Unrecognized type [object Object]
> 
> What does this failure mean?

I have not investigated yet but I have verified that Chrome is getting the exact same failure. It is possible that the test is wrong or is not expecting a frozen array. I'll check.

[Chris Dumez]

Created attachment 291156 [details]
Patch

[Chris Dumez]

Comment on attachment 291156 [details]
Patch

Clearing flags on attachment: 291156

Committed r207021: <http://trac.webkit.org/changeset/207021>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Angjelko Miloshevski (Jack)]

(In reply to Chris Dumez from comment #3)
> (In reply to comment #2)
> > Does this expose additional information that is not already available to
> > pages?
> 
> I believe so, I think we've only exposed the first language so far. Chrome
> and firefox already support this though.

This completely destroys the purpose of the navigator.languages, in our case the user might have selected English as the default but previously he had Deutsch selected, and our app would like to display Deutsch as the selected language, that's working fine in Chrome, but in Safari that's broken, are there any plans to list the "preferred languages" properly in navigator.languages?

[Ryosuke Niwa]

(In reply to Angjelko Miloshevski (Jack) from comment #15)
> (In reply to Chris Dumez from comment #3)
> > (In reply to comment #2)
> > > Does this expose additional information that is not already available to
> > > pages?
> > 
> > I believe so, I think we've only exposed the first language so far. Chrome
> > and firefox already support this though.
> 
> This completely destroys the purpose of the navigator.languages, in our case
> the user might have selected English as the default but previously he had
> Deutsch selected, and our app would like to display Deutsch as the selected
> language, that's working fine in Chrome, but in Safari that's broken, are
> there any plans to list the "preferred languages" properly in
> navigator.languages?

It seems unlikely given the fingerprinting surface it introduces.