Keyboard Map API

[hsinyi]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Keyboard Map API
• Specification or proposal URL: https://wicg.github.io/keyboard-map/
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1469017
• Mozillians who can provide input (optional): @masayuki-nakano @smaug----

Other information

This is not possible with existing web platform APIs because the value that should be shown to the user depends on the keyboard layouts that the user has installed and active.

Explainer: https://github.com/WICG/keyboard-map/blob/master/explainer.md

[hsinyi]

Masayuki left some comments on bugzilla:

And we often get bugs reports from customized or really minor keyboard layout users. For such users, exposing this information is really strong fingerpintting source. Finally, Apple has already refused. So, I think that we do not need to this API. On the other hand, this API might be useful for our UI. So, as a chrome only API, this could be useful. If we implement this API as chrome only API, and, too many web apps require this API (and banned other browsers than Chrome), just open it for web apps might be the best way for web-compat. (Anyway there are some strong fringerprinting source for minor environment users, e.g., screen resolution, so that I think that demand of this API is also important for the consideration. But currently, I believe that web apps requiring this API are only a few.)

[hsinyi]

Also CC @tomrittervg for feedback on privacy.

[dbaron]

It seems like this API would change an existing vector for fingerprinting that requires user interaction (i.e., requires getting the user to press keys, and then look at the resulting key and code on the events) into a fingerprinting vector that doesn't require using interaction.

[hsivonen]

Do desktop platforms even expose sufficient information for implementing this API?

If we were to require some keyboard user interaction before exposing the proposed API, it's worthwhile to consider what user interaction a game could already ask for. A game could already ask the user to press the key below the key labeled (among other labels) 1 and the key below the key labeled (among other labels) 6, and this would already go a very long way in terms of identifying mainstream layouts globally on a level sufficient for describing gaming key locations for keys that are invariant under locale-specific variation of QWERTY (i.e. you wouldn't be able to accurately describe the keys that on U.S. QWERTY have the labels backtick, slashes, square brackets, semicolon, apostrophe, minus and equals).

Maybe it's weird or inelegant for a game to ask the user to press the key below the key labeled (among other labels) 1 and the key below the key labeled (among other labels) 6, but it seems like a rather mild thing to ask when compared with giving this fingerprinting surface to all sites that currently seek to do fingerprinting but where the user generally doesn't input text. (This is the majority of sites that users browse to: The user follows a link, reads stuff without writing anything, and leaves.)

So: Why isn't it good enough to ship a JS library that contains enough information about mainstream layouts across the globe to guess the layout (excluding for keys that vary in QWERTY between locales) from the two above-mentioned key presses?

[hsivonen]

For clarity: The two mentioned keys are enough to distinguish between QWERTY, AZERTY, QWERTZ, and various mainstream non-Latin layouts. They aren't enough to distinguish locale-specific variants of QWERTY, AZERTY, and QWERTZ.

[titoBouzout]

@hsinyi @dbaron @hsivonen
Why not just let the user decide with a permission that is disabled by default?