Keyboard Map introduces a high entropy fingerprinting surface

[rniwa]

As I've noted in person a while ago, the Keyboard Map API as proposed exposes a high entropy fingerprinting surface. This is not acceptable from privacy perspective. As a result, the WebKit team at Apple is not interested in implementing this feature as currently proposed / spec'ed.

[tszynalski]

@rniwa Does it really leak so much information compared with other channels? Sure, it lets you determine the active keyboard layout, but can't you already predict it with >90% accuracy just from the IP country and/or preferred languages set in browser?

[rniwa]

@rniwa Does it really leak so much information compared with other channels? Sure, it lets you determine the active keyboard layout, but can't you already predict it with >90% accuracy just from the IP country and/or preferred languages set in browser?

No. There are like 5-6 different keyboard layouts for Japanese alone. And if you use a keyboard layout that's not common in a given country / region, you'd stand out.

[MelvinWM]

Without using the 'Keyboard Map' API, assuming that an application can listen to keyboard events and record code-key pairs, a user that types and uses a large number of different letters could possibly have their keyboard layout detected either way, right? About which differences there are for privacy between these two methods for guessing keyboard layout:

• User keypress recording: A user typing a large number of different letters with an application recording these pairs by listening to KeyboardEvents and guessing the user's keyboard layout. It would give no information if the user types nothing, or if KeyboardEvents for some reason cannot be listened to.
• The 'Keyboard Map' API: Directly use the API to query code values and guess the user's keyboard layout. This would not require the user to type anything, and the guessing would likely have a higher success rate for guessing due to being able to query any code value, though I could imagine that the difference in success rate to the 'user keypress recording' method would be small if the user types at least a fair number of keys.

I wonder whether these differences are really that large, or whether one could exploit it - for instance, only let the 'Keyboard Map' API become available if the user has typed at least 10 different 'letter' keys, since at that point there may be enough information either way to guess with a high success rate the user's keyboard layout.

One case that does argue for a substantial difference is if a user has a very specific/personal keyboard layout (like x number of keys being mapped to something atypical, and the user not normally typing those keys).

[MelvinWM]

Could it make sense to (either generally or as a mode when requesting KeyboardLayoutMap) only successfully map code values that the user has already pressed (for a certain lifetime/context), and when querying, return undefined if no mapping is presently available for a specific code value? If KeyboardLayoutMap only ever returns the same mapping as the mapping in a KeyboardEvent for code-key, no extra information would be shared beyond what can already be gathered.

This does mean that the mapping would not be available and useful initially for a web application, and the mapping would only become available piecemeal, which might be bothersome and confusing for users and possibly annoying for web application developers to handle. It might also mean that such a mode of KeyboardLayoutMap would only offer very little or nothing over custom-made non-'Keyboard Map'-API solutions, since developers can already implement this functionality. It would also imply the addition of state to the API. And there is also the issue of layouts changing during the given lifetime/context.

But that might still give a way forward. For instance: When requesting KeyboardLayoutMap, you have to specify one of two modes:

• For the first mode, the browser/user-agent has to get explicit permission from the user before the Promise for KeyboardLayoutMap resolves successfully.
• For the second mode, no permission is required from the user, but the querying information that KeyboardLayoutMap yields is only ever what has so far been gotten by listening to KeyboardEvents (maybe even require callers to give a callback for supplying the listened-to KeyboardEvents).

This may furthermore possibly enable the relaxation/removal of the 'top-level global context' requirement. The 'top-level global context' requirement is somewhat of a hindrance for the cases where iframes are used, which includes many web games and web game portals, a main use case for this API.

One could also combine the modes in this example, such that there is a third mode that starts with the first mode, and if the user rejects it, falls back to the second mode (though that can also be handled by web application developers, so may not make sense to include in the API).

[benjamind]

Without this API it is very hard for an application to show a user correctly the keyboard shortcuts that are mapped in the application. This is a major drawback and harms the experience on web vs desktop.

We at Adobe really need some solution here to discover the true mapping of code to the users physical key lettering as otherwise its I think currently impossible to show the keyboard shotcut ahead of them pressing the keys! This is not only a user experience failing, but an accessibility one as well.

Is anyone at Apple interested in reopening the conversation here and trying to find a solution?

[MelvinWM]

@benjamind The approach I ended up going with for my case was making it clear to the user that the user has to press the key on their keyboard that corresponds to the given code value (ie. showing the users the code value and informing them in some way that the value is the code/"raw" value), leaving it up to the user to know already or figure out which physical key on their keyboard yields the given code value. Not a very nice approach in many cases, however.

[snnsnn]

Why would browsers vendors provide event.code values since without KeyboardLayoutMap if it is not much different than keyCode.