Intent to Implement: Keyboard Map

[Gary Kačmarčík (Кошмарчик)]

Contact emails gar...@chromium.org Spec

https://wicg.github.io/keyboard-map/

Summary An API that returns a map which translates from `KeyboardEvent.code` values into a strings that can be shown to the user to identify each key. 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. Motivation

The only "workaround" for this API is to assume that all users have an en-US keyboard layout and describe the keys accordingly.

See Mozilla Hacks post that calls out this as a missing feature from the web platform (in "What's missing?" section): https://hacks.mozilla.org/2017/03/internationalize-your-keyboard-controls/ Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive

Although note that we have had discussions with various engineers at Mozilla about this API.

Compatibility risk Minimal - introducing a single new simple API

Ongoing technical constraints

None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no.

No, only desktop platforms: Win, Mac, Linux, ChromeOS. This API is intended for systems where a physical keyboards is a primary input method.

OWP launch tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=831743 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6730004075380736 Requesting approval to ship?

No

[PhistucK]

While it might be a small use case (showing keyboard shortcut legends, at least), the current state makes such legends impossible to tailor to the non-English end user.

Even the Chrome Developer Tools feature suffers from this, I believe (press F1 in it and go to Shortcuts).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnkXoEbGRemhfOe8%3DeoTGvpro0UgP8Ny%2BQ0wJYKgF68nQD20g%40mail.gmail.com.

[a...@google.com]

From a reading of the privacy section of the spec, I'm not clear on the fingerprinting potential of this feature. If I use two identical PCs, but with different keyboard models, will this be noticeable via the API? What conditions need to be met for two different keyboards to return a different map: do they need to have a different set of keys, or something else? Do we know the distribution of keyboard maps across users, i.e. is it likely that most people with the same keyboard layout would have an identical map? It would be helpful to understand it more to better evaluate the fingerprinting surface here.

Also, please note that being limited to secure contexts doesn't mitigate these concerns, as the site which attempts to fingerprint the user can easily serve their code over HTTPS.

Cheers,

-Artur

[Gary Kačmarčík (Кошмарчик)]

Some info about this API WRT fingerprinting:

As defined, this API only returns the highest ASCII-capable keyboard layout. For the US, this will be a QWERTY-US mapping for almost everyone, although some people with French or German as their primary layout would report a AZERTY or QWERTZ mapping. For people in the US with Russian or Arabic as their primary lang, the value returned would fall back to QWERTY (or whatever their highest ASCII-capable layout is). So most people in the US will report a QWERTY mapping regardless of their currently active layout.

Users with active dvorak or colemak layouts would be distinguished because those are different, ASCII-capable layouts.

Of interest is the difference between US and UK layouts. The mapping is subtly different (£ instead of # above the 3), and the UK layout provides values for keys that are not present on the US layout. So people with active US vs active UK layouts could be distinguished, but just having a UK layout on your computer in the US would not be revealed unless it was the active layout.

Note that the layout is a OS-software-thing and not a keyboard-hardware-thing. Plugging in a UK keyboard and using it with a US layout still appears as a US layout. E.g., all US layout keyboards are identical as far as this API is concerned.

Basically, the API would group almost all users into buckets that roughly corresponded to the country they were living in. And most of the world (with primary Russian, Arabic, Asian, et al. layouts) would appear in the same bucket as QWERTY-US (or AZERTY, depending on their non-native default).

Contrast this with things that we *do not* do in this API:

* We do not provide info about the currently active layout, since that would permit more accurate fingerprinting based on English, Arabic, Russian, et al.

* We do not provide a list of all installed layouts, since that could be used to identify users who have installed, but rarely use, uncommon layouts for that country (e.g., Japanese in the US) 

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cac4c2ac-9c0a-4785-be3f-37087526f7a5%40chromium.org.

[Artur Janc]

Thanks for the detailed explanation, Gary! This sounds reasonable to me -- it might be useful to include some of this information in the spec (e.g. around the second para in the Privacy section) to paint a more detailed picture of what the API provides, and explain why we expect it to not be particularly useful for fingerprinting.

Cheers,

-Artur

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mounir Lamouri]

Gary, was it considered to have this API return only one key instead of the full map? It may help limiting/blocking things for privacy and could in the future be extended to include modifiers.

-- Mounir

> >> <https://wicg.github.io/keyboard-map/#privacy> of the spec, I'm not

> >> clear on the fingerprinting potential of this feature. If I use two
> >> identical PCs, but with different keyboard models, will this be noticeable
> >> via the API? What conditions need to be met for two different keyboards to
> >> return a different map: do they need to have a different set of keys, or
> >> something else? Do we know the distribution of keyboard maps across users,
> >> i.e. is it likely that most people with the same keyboard layout would have
> >> an identical map? It would be helpful to understand it more to better
> >> evaluate the fingerprinting surface here.
> >>
> >> Also, please note that being limited to secure contexts doesn't mitigate
> >> these concerns, as the site which attempts to fingerprint the user can
> >> easily serve their code over HTTPS.
> >>
> >> Cheers,
> >> -Artur
> >>
> >> On Wednesday, April 11, 2018 at 11:06:21 PM UTC+2, Gary Kačmarčík wrote:
> >>>
> >>> Contact emails gar...@chromium.org Spec
> >>> https://wicg.github.io/keyboard-map/

> >>> <https://www.google.com/url?q=https%3A%2F%2Fwicg.github.io%2Fkeyboard-map%2F&sa=D&sntz=1&usg=AFQjCNEzZFXeJ9TPvwQ86fFOVhgSiZ0Y6w>

> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cac4c2ac-9c0a-4785-be3f-37087526f7a5%40chromium.org?utm_medium=email&utm_source=footer>
> >> .

> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqocjmD%2Bjny6KV_otpLf%2BmOqeAgRzOHHzt2zOmfwi8fDWA%40mail.gmail.com.

[Gary Kačmarčík (Кошмарчик)]

On Tue, Apr 17, 2018 at 6:20 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:

Gary, was it considered to have this API return only one key instead of the full map? It may help limiting/blocking things for privacy and could in the future be extended to include modifiers.

Yes, an early initial straw-man proposal was for a single key but a lot of early feedback was that devs wanted the entire map and would need to call the API in a loop to get the values they wanted. 

In addition, the API returns a Promise, which would make it unwieldy to use if it needed to be called dozens of times to get a complete map.

[Mounir Lamouri]

Actually, you wouldn't need to call this in a loop. Someone could do:
```
Promise.all(getKey(..), getKey(..), getkey(..)).then(results => {
});
```

Developers could make this fairly transparent to them if needed.

-- Mounir

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnkXoHbX%2B9ynFPL7s0Zphf9Y7%3DE4v%3D0Mb3gas3W6cEMWs5pjw%40mail.gmail.com.