Keyboard language should not be tied to accept language |
|||||
Issue descriptionChrome 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.
,
Mar 7 2018
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.
,
Mar 7 2018
> 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/
,
Mar 7 2018
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.
,
Mar 8 2018
> 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?
,
Mar 8 2018
Yes (happy to chat offline if you're curious) though they wouldn't change anything in this case.
,
Mar 8 2018
,
Jun 5 2018
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 |
|||||
Comment 1 by tnagel@chromium.org
, Jan 30 2018