Contact emails
mattre...@chromium.org, rei...@chromium.org
Explainer
Summary
A HID (Human Interface Device) is a type of device that takes input from or provides output to humans. It also refers to the HID protocol, a standard for bi-directional communication between a host and a device that is designed to simplify the installation procedure. Mice, keyboards, touchscreens, gamepads, and many other devices are typically implemented using HID. Our WebHID proposal would provide low-level access to these devices so that web applications can access them even when they are not supported well by the host OS.
Motivation
Many popular and useful devices use HID. For some devices, generic HID drivers provided by the operating system can support all important use cases and no additional device-specific support is needed. However, some devices may provide additional capabilities outside of the features supported by the generic driver. There are many devices that use HID but do not fall into the categories of devices that are supported by generic drivers.
Risks
Interoperability and Compatibility
We haven't received feedback yet, but HID support is not provided in any other browsers and is unlikely to be adopted. Chrome already has support for HID through the chrome.hid API exclusive to Chrome Apps, and this API aims to bring that functionality to the web. Some types of HID devices are already widely supported on the web platform through pointer, keyboard, and gamepad APIs.
Edge: No signals
Firefox: No signals
Safari: No signals
Web developers: No signals
Ergonomics
With WebHID we are trying to address issues with the ergonomics of the chrome.hid API. The chrome.hid API similarly allows access to HID subsystem devices but treats HID reports as opaque binary blobs. We aim to improve on this by providing utility methods to get and set the values of individual fields within the report.
Activation
I expect that this API will typically be used through a library or polyfill that encapsulates device-specific behavior to provide developers a cleaner interface. These libraries will not be available at first, which may slow adoption.
Debuggability
Chrome already provides some debugging support for HID through the chrome://device-log dashboard.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5172464636133376
Requesting approval to ship?
No.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2Bqnouc%3DESV8Spawf8m1OkuWWadXMyM2e8igoHHrcEFUvvx%2B6A%40mail.gmail.com.
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/CA%2BqnoufS6pmq3sOJmu9xSPm7V4YvP_RzvjvtpgzNp5B-2GR81A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfJXBUCUwLfSFeDaTk%3DsbN4aotzkYL009WkEioA%3DhhHXA%40mail.gmail.com.
Hi Gary,Can you explain more about the interaction with keyboard events?I expect we will avoid the issue by not allowing keyboards to be exposed through this API as it could allow a tab to observe keystrokes without keyboard focus (i.e., you could turn it into a keylogger). For similar reasons we will also exclude mice and security keys. But even if they were made accessible, I don't expect it would have any impact on existing events.Some devices offer functionality over HID that could potentially be used to attack the host. For example, it's possible for a keyboard with macro functionality to have its macros reprogrammed over HID, leading to unexpected input the next time the macro is triggered. Some devices receive firmware updates over HID, and could potentially be reprogrammed to do any number of terrible things.
To mitigate this, we should exclude any devices that look like keyboards or mice by examining the HID report descriptors during enumeration. For known exploits, we can implement a blocklist that bans access to particular devices or disallows specific reports.
Hi Gary,Can you explain more about the interaction with keyboard events?
I expect we will avoid the issue by not allowing keyboards to be exposed through this API as it could allow a tab to observe keystrokes without keyboard focus (i.e., you could turn it into a keylogger). For similar reasons we will also exclude mice and security keys. But even if they were made accessible, I don't expect it would have any impact on existing events.
Some devices offer functionality over HID that could potentially be used to attack the host. For example, it's possible for a keyboard with macro functionality to have its macros reprogrammed over HID, leading to unexpected input the next time the macro is triggered. Some devices receive firmware updates over HID, and could potentially be reprogrammed to do any number of terrible things. To mitigate this, we should exclude any devices that look like keyboards or mice by examining the HID report descriptors during enumeration. For known exploits, we can implement a blocklist that bans access to particular devices or disallows specific reports.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/OaDCpCaEe_4/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAGnkXoEJZ_1zCwW-9xJsryYmMu0nDr_oLpHB775sQ%2B3JcaahTA%40mail.gmail.com.