Intent to Ship: Keyboard Map API

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

Contact emails

gar...@chromium.org, joe...@chromium.org, den...@chromium.org

Explainer

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

Spec

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

TAG review: https://github.com/w3ctag/design-reviews/issues/238

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/

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/m0OOlPJGNTY

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all desktop platforms: Linux, Windows, Mac and ChromeOS.

No immediate plans to support this on mobile.

Debuggability

The Keyboard Layout Map is returned as a standard maplike object, which can be inspected in devtools.

Risks

Interoperability and Compatibility

Minimal - introducing a single new simple API. General agreement that this is a useful thing for the Web Platform, but no indications of support in other browsers.

Firefox: No public signals (although have been involved in discussions about API)

Edge: No public signals Safari: No public signals Web developers: Positive

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Possibly with Keyboard Lock (e.g., for games that want to capture events fullscreen). More generally with standard KeyboardEvents.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

API returns a Promise and it should be rarely called (typically only during UX setup screens).

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

A basic polyfill that always returns US-QWERTY data would be useful. One has been started here: https://github.com/WICG/keyboard-map/blob/master/keyboard-polyfill.js although it needs to be updated to return a maplike.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://github.com/web-platform-tests/wpt/tree/master/keyboard-map

https://wpt.fyi/results/keyboard-map

Entry on the feature dashboard

https://www.chromestatus.com/features/6730004075380736

Launch Tracking Bug

https://bugs.chromium.org/p/chromium/issues/detail?id=831743

[PhistucK]

It would be great if you -

- Filed feature requests for all of the other browsers.

- Tried to get some signals from the other vendors.

Shipping something only in Chrome without any long term plan or even an interest and intention from other vendors can create a bad situation where an API is Chrome only for good.

A public tracking bug can be found here -

crbug.com/832811

☆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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnkXoFfVfpUXL2b%2Bs%3D8y_mXjtOKqxekb%2B4LnS9eNfZkb%2BS%2BKg%40mail.gmail.com.

[Boris Zbarsky]

On 6/13/18 3:53 PM, 'Gary Kačmarčík (Кошмарчик)' via blink-dev wrote:
> https://wicg.github.io/keyboard-map/

Has there been any thought about the increased fingerprinting surface?
I know that would come up as one of the first questions in a Firefox
intent to ship for something like this...

-Boris

[Daniel Bratell]

There was indeed some fingerprint discussions in the Intent to Implement
thread. On the downside I can see this used both for geoblocking and
fingerprinting which makes it a non-trivial addition. I'd be happy to hear
the thoughts of those that have been working on this.

/Daniel

--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Chris Harrelson]

LGTM1

--
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/op.zkldgizhrbppqq%40cicero2.linkoping.osa.

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

Yes, this was discussed in the TAG review (https://github.com/WICG/keyboard-map/issues/8) and it is explicitly covered in the Privacy section (https://wicg.github.io/keyboard-map/#privacy). Please let me know if you think there should be additional information there.

[Yoav Weiss]

On Thu, Jun 14, 2018 at 8:44 PM 'Gary Kačmarčík (Кошмарчик)' via blink-dev <blin...@chromium.org> wrote:

Yes, this was discussed in the TAG review (https://github.com/WICG/keyboard-map/issues/8) and it is explicitly covered in the Privacy section (https://wicg.github.io/keyboard-map/#privacy). Please let me know if you think there should be additional information there.

Glad to see the privacy aspects were thoroughly discussed :) LGTM2

To reiterate a previous comment, can you also file issues with other browser vendors?

 

On Thu, Jun 14, 2018 at 1:32 AM Boris Zbarsky <bzba...@mit.edu> wrote:

On 6/13/18 3:53 PM, 'Gary Kačmarčík (Кошмарчик)' via blink-dev wrote:
> https://wicg.github.io/keyboard-map/

Has there been any thought about the increased fingerprinting surface?
I know that would come up as one of the first questions in a Firefox
intent to ship for something like this...

-Boris

--

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/CAGnkXoFF9vWqcgL2b3jPXKCoc2R9aomNT8%3Da9-c9qrc0Bio3vg%40mail.gmail.com.

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

Sorry for the delay, I was out for most of yesterday.

For reference, here are the tracking issues in other browsers:

* Webkit: https://bugs.webkit.org/show_bug.cgi?id=186680

* Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1469017

* Edge: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/34574317-support-navigator-keyboard-getlayoutmap-api

[Mike West]

This API does increase the fingerprinting surface, by revealing the user's keyboard layout to websites they visit. I don't think that affects a huge population, but it does make certain categories of users pretty visible. I, for instance, live in Germany, where QWERTZ is common, but I use QWERTY, because it's the keyboard layout I grew up with. That differentiates me to some extent (though I suspect that that specific differentiation is already possible in many of these cases by examining the `Accept-Language` headers I'm sending out (`en-US`) vs the headers of a typical German (`de-DE`)).

I think the problem the API aims to address is real, and in general helps us get away from the US-centric view of the world that developers often accidentally espouse. The API seems to be designed in such a way as to allow vendors to pick a reasonable layout for users who've expressed some opinions about their fingerprintability. I'm not sure any vendor would ever prompt the user for this question, as the spec suggests that they might, but a chooser is imaginable, as is vendors being clever about returning the most common keyboard variant in whatever location the user happens to occupy. That seems like a reasonable path forward for Incognito if (when?) we recognize that the API is being abused.

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnkXoFEXhHeWnqK%2B7Bu8gDJYotjyR40P3VD63hpzJ_ytvZgNg%40mail.gmail.com.

[Thiemo Nagel]

In order reduce the fingerprinting impact, have you considered:

* disallowing use in 3rd-party iframes?

* requiring a user interaction with the frame?

* making the feature https-only?

Thank you,

Thiemo

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/CAGnkXoFF9vWqcgL2b3jPXKCoc2R9aomNT8%3Da9-c9qrc0Bio3vg%40mail.gmail.com.

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

On Wed, Jul 18, 2018 at 6:09 AM Thiemo Nagel <tna...@chromium.org> wrote:

In order reduce the fingerprinting impact, have you considered:

* disallowing use in 3rd-party iframes?

* requiring a user interaction with the frame?

This spec requires that this API is only available to top-level browsing contexts.

 

* making the feature https-only?

The spec requires SecureContext for this API.

[Thiemo Nagel]

Thank you! -- I only looked at the privacy section. :/

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

To make that information (i.e., secure context and top-level browsing context) easier to find, I duplicated it at the start of the Privacy Mitigations section. Thanks for pointing that out.