Bug 163220

Summary: Add support for Navigator.languages attribute
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: DOMAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, ap, bfulgham, cdumez, commit-queue, darin, esprehn+autocc, kondapallykalyan, rniwa, sam
Priority: P2 Keywords: WebExposed
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
URL: https://html.spec.whatwg.org/#navigatorlanguage
Bug Depends on:    
Bug Blocks: 163222    
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Chris Dumez 2016-10-10 10:33:45 PDT
Add support for Navigator.languages attribute:
- https://html.spec.whatwg.org/#navigatorlanguage

Firefox and Chrome already support this.
Comment 1 Chris Dumez 2016-10-10 10:54:22 PDT
Created attachment 291122 [details]
Patch
Comment 2 Sam Weinig 2016-10-10 11:06:31 PDT
Does this expose additional information that is not already available to pages?
Comment 3 Chris Dumez 2016-10-10 11:09:20 PDT
(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.
Comment 4 Sam Weinig 2016-10-10 11:21:08 PDT
(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.
Comment 5 Chris Dumez 2016-10-10 11:54:05 PDT
(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 6 Sam Weinig 2016-10-10 12:20:25 PDT
Comment on attachment 291122 [details]
Patch

r-ing until we can have further conversations about the privacy impact of this.
Comment 7 Brent Fulgham 2016-10-10 12:23:57 PDT
(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.
Comment 8 Chris Dumez 2016-10-10 12:55:38 PDT
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.
Comment 9 Chris Dumez 2016-10-10 12:59:05 PDT
Created attachment 291147 [details]
Patch
Comment 10 Darin Adler 2016-10-10 13:51:22 PDT
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?
Comment 11 Chris Dumez 2016-10-10 14:01:26 PDT
(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.
Comment 12 Chris Dumez 2016-10-10 14:03:15 PDT
Created attachment 291156 [details]
Patch
Comment 13 Chris Dumez 2016-10-10 14:04:15 PDT
Comment on attachment 291156 [details]
Patch

Clearing flags on attachment: 291156

Committed r207021: <http://trac.webkit.org/changeset/207021>
Comment 14 Chris Dumez 2016-10-10 14:04:19 PDT
All reviewed patches have been landed.  Closing bug.