search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 52 forks source link

Identify which of multiple keyboards an event came from #226

Closed robatwilliams closed 5 years ago

robatwilliams commented 5 years ago

When multiple keyboards are available, there is currently no way to distinguish which one a KeyboardEvent came from using web APIs. We should have one.

Use case 1: special-purpose keyboards/keypads that are used alongside normal keyboards, for example financial trading keypads and retail POS keyboards. They are used to provide quick access to regular/time-sensitive actions, while the normal full-sized keyboard is used for other input. The key codes they expose (as far as I know) are the same as for the normal keyboard (but the mappings can be programmed), so the listening application needs to use the source of the key event to determine what action to take.

Use case 2 (similar): gaming keyboards, if use of the main keyboard is also needed (otherwise the Keyboard Lock API seems like it would do the job).

I started a discussion over at WICG Discourse: Identify which of multiple keyboards an event came from. Some of the ideas there would probably be within the scope of UI Events, but the more advanced ones would not.

marcoscaceres commented 5 years ago

I'm still at a bit of a loss as to why one needs to distinguish the devices? Isn't all that matters that the key event came from somewhere? That is, the mapping should be unique for device, but the device themselves should not be identifiable (otherwise it serves as fingerprinting vector, or a way of violating user's privacy - "ah, this person works in the financial industry! or this person uses a special kind of keyboard that only people with disability X use." and so on...).

robatwilliams commented 5 years ago

As I mentioned, special-purpose keyboard is used alongside a normal keyboard. It dispatches the same key codes, but actually the button on them is labelled e.g. "buy", so to act on that you need to know which device it came from.

For the basic use case, some device attribute on an event with value 0 or 1 etc. would suffice. The user could tell us in the app that they have one of these devices, we could then ask them to press a button on it to learn which device it is. For that, I'm not sure if there is a privacy/fingerprinting issue; all that could be learnt is that the user has >1 keyboard.

True about the fingerprinting/privacy for the more capable features like identifying which model it is; I mentioned a bit about this on the WICG thread - consent may need to be sought.

Perhaps the wider issue here is that these devices, which were not designed for the web, are physical keyboards but are not for entering characters. In that respect, they are more like a game pad - which we have an API for already.

robatwilliams commented 5 years ago

At least some of these kinds of keyboards (e.g. X-keys) have multiple modes - including one that exposes the device on the USB HID Consumer Page. That page isn't a protected usage under WebHID (unlike GenericDesktop>Keyboard/Keypad, so the device could be accessed via WebHID and there is no need for what I'm asking for here.

There may still be use cases for this in older devices, or those gaming keypads (I don't know what they expose).