Add support for Navigator.languages attribute: - https://html.spec.whatwg.org/#navigatorlanguage Firefox and Chrome already support this.
Created attachment 291122 [details] Patch
Does this expose additional information that is not already available to pages?
(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.
(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.
(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.
Comment on attachment 291122 [details] Patch r-ing until we can have further conversations about the privacy impact of this.
(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.
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.
Created attachment 291147 [details] Patch
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?
(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.
Created attachment 291156 [details] Patch
Comment on attachment 291156 [details] Patch Clearing flags on attachment: 291156 Committed r207021: <http://trac.webkit.org/changeset/207021>
All reviewed patches have been landed. Closing bug.
(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?
(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.