New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 802039 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Keyboard language should not be tied to accept language

Project Member Reported by tnagel@chromium.org, Jan 15 2018

Issue description

Chrome Version: 63
OS: Chrome

What steps will reproduce the problem?
(1) Use a device whose keyboard layout doesn't match any of the accept languages (e.g. accept language: EN-US, keyboard: EN-UK).

What is the expected result?
I should be able to select the correct keyboard layout (EN-UK) without adding that language to the accept languages header because using multiple accept languages is a relevant fingerprinting vector and also I might not even speak that language (just happen to use a keyboard in that language).

What happens instead?
I need to add EN-UK to accept language in order to use the EN-UK keyboard layout.
 

Comment 1 by tnagel@chromium.org, Jan 30 2018

Cc: claudiomagni@chromium.org
Labels: -Pri-2 Pri-3
That seems an edge use case: using a keyboard for a language you don't speak. Fingerprinting with language setting is minimal for a typical use with max 2-3 languages and millions of people in the world with the same fingerprint. Lowering priority to 3.
Owner: yyushkina@chromium.org
> That seems an edge use case: using a keyboard for a language you don't speak.

I would expect that use case to be pretty common in NBU where English keyboards may be the ones most readily available and/or where it may be a question of prestige to use an English keyboard.

Regarding fingerprinting, I've used Panopticlick [1] to estimate entropy for HTTP ACCEPT [2] headers: {en-US} (4.75 bits), {en-US,de} (10.86 bits), {en-US,en-UK} (12.12 bits) and {en-US,de,en-UK} (16.96). Taking en-US as a baseline and subtracting that value to get rid of the contributions of non-language ACCEPT headers:

 0.0 bits: en-US
 6.1 bits: en-US, de
 7.4 bits: en-US, en-UK
12.2 bits: en-US, de, en-UK

Compared to the total entropy that is sufficient for identification of approximately 30 bits these are very sizeable numbers and I'd kindly ask you to be mindful of this when designing language features and to not consume more entropy than absolutely necessary.

[1] https://panopticlick.eff.org/
re: "I would expect that use case to be pretty common in NBU where English keyboards may be the ones most readily available and/or where it may be a question of prestige to use an English keyboard." Those users mostly have their UI on English for the same reasons and thus have English in their accept language header by default.

Thanks for the entropy numbers. We'll keep that in mind.
> Those users mostly have their UI on English for the same reasons and thus
> have English in their accept language header by default.

Which seems less than ideal. But I understand that better heuristics/ML are in the works?
Yes (happy to chat offline if you're curious) though they wouldn't change anything in this case. 
Status: Assigned (was: Untriaged)
Status: WontFix (was: Assigned)
Having thought about this more, the convenience to most users of combined settings makes it unlikely that we'd ever decouple the too. Marking as won't fix.

Sign in to add a comment