Intent to Ship: WebHID (Human Interface Device)

[Matt Reynolds]

Contact emails

mattre...@chromium.org

Explainer

https://github.com/WICG/webhid/blob/master/EXPLAINER.md

Specification

https://wicg.github.io/webhid/index.html

API spec

Yes

Design docs

https://web.dev/hid

Summary

Enables web applications to interact with human interface devices (HIDs) other than the standard supported devices (mice, keyboards, touchscreens, and gamepads). However, there are many other HID devices that are currently inaccessible to the web. This API allows web applications to request access to these devices, send and receive HID reports, and retrieve information about the report descriptor.

Blink component

Blink>HID

Search tags

webhid, hid

TAG review

https://github.com/w3ctag/design-reviews/issues/370

TAG review status

Pending

Risks

Privacy risks were discussed in the TPAC 2020 Device & Sensors WG meeting:
https://www.w3.org/2020/10/23-dap-minutes.html

Interoperability and Compatibility

Gecko: Negative

WebKit: No signal

Web developers: Strongly positive

USB headset vendors want to use WebHID to improve integration of call control features in web-based softphone applications (answer/reject/end call, microphone mute, redial, etc): https://developer.jabra.com/site/global/sdks/web/documentation/index.gsp 
Hobbyists are using WebHID to control niche devices like Razer Kraken Kitty: https://twitter.com/sarahemm/status/1314006489510666241

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://crbug.com/890096

Launch bug

https://crbug.com/890033

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5172464636133376

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/OaDCpCaEe_4/m/eRqOcJ_eCgAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/LoyzK8xTRME/m/WQLaGQ99CQAJ

This intent message was generated by Chrome Platform Status.

[Joshua Bell]

Can you speak to what is covered by WPT, what the gaps are, and how those could get coverage in the future?

 

Tracking bug

https://crbug.com/890096

Launch bug

https://crbug.com/890033

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5172464636133376

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/OaDCpCaEe_4/m/eRqOcJ_eCgAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/LoyzK8xTRME/m/WQLaGQ99CQAJ

This intent message was generated by Chrome Platform Status.

--
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/CA%2Bqnouf2vDrW6y11FAEvyF%2B7qbEdqm%3DuS28RTF%2Bk%2BGy%3Dy9HuEA%40mail.gmail.com.

[Yoav Weiss]

Any links to those positions?

 

Web developers: Strongly positive  

USB headset vendors want to use WebHID to improve integration of call control features in web-based softphone applications (answer/reject/end call, microphone mute, redial, etc): https://developer.jabra.com/site/global/sdks/web/documentation/index.gsp 
Hobbyists are using WebHID to control niche devices like Razer Kraken Kitty: https://twitter.com/sarahemm/status/1314006489510666241

Is this feature fully tested by web-platform-tests?

No

Why not?

 

Tracking bug

https://crbug.com/890096

Launch bug

https://crbug.com/890033

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5172464636133376

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/OaDCpCaEe_4/m/eRqOcJ_eCgAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/LoyzK8xTRME/m/WQLaGQ99CQAJ

This intent message was generated by Chrome Platform Status.

--

[Matt Reynolds]

The vendor signals section was out of date, here's an updated version with links:

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/459) Waiting for a response

WebKit: Negative (https://webkit.org/tracking-prevention/) WebHID is mentioned under Anti Fingerprinting as an example of "features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns"

Web developers: Strongly positive USB headset vendors want to use WebHID to improve integration of call control features in web-based softphone applications (answer/reject/end call, microphone mute, redial, etc): https://developer.jabra.com/site/global/sdks/web/documentation/index.gsp Hobbyists are using WebHID to control niche devices like Razer Kraken Kitty: https://twitter.com/sarahemm/status/1314006489510666241

> Can you speak to what is covered by WPT, what the gaps are, and how those could get coverage in the future?

WPT are planned, we have some web_tests already but the external web platform tests are minimal and only verify the presence of interfaces and attributes:
https://wpt.fyi/results/webhid

We have internal web tests that will be converted to WPT, I expect we'll use the same pattern described in Robert Ma's "Test-only API in WPT" lightning talk. These internal web tests cover requesting a device, opening/closing the device, connection events, reading/writing reports, and verifying that the device info exposed through the API matches the info in the internal Mojo objects.
https://source.chromium.org/chromium/chromium/src/+/master:third_ and may differ by party/blink/web_tests/hid/

Some of the behaviors of the WebHID API are platform or device dependent, and automated web platform tests aren't a good fit for testing these behaviors. For instance, the HIDDevice.collections attribute is populated with information from the device's HID report descriptor. The content of the collections attribute can differ based on how the platform provides report descriptor info to applications. I've written a manual test that validates the platform behavior against specific devices with known report descriptors, but this can't be automated since it relies on a supported device being connected.

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/wpt_internal/hid/hidDevice_collections-manual.https.html

- Matt

[Mike West]

LGTM1.

This API has both security and privacy implications, but I believe they're adequately addressed in Chromium's implementation and in the security/privacy considerations section of the specification. The chooser-based UX model and user-visible tab-level access indicator has proven effective in mediating access to USB and Bluetooth devices. I expect it will be equally effective here, especially as we've carried over the blocklist concept from those APIs to prevent access to devices considered particularly dangerous. I appreciate the work the team has done to address these concerns over time, and I'm looking forward to seeing what developers can do with this kind of access.

I would like to see the WPT coverage continue to expand. It's an important investment in eventual interoperability, and one I'm happy to see y'all actively planning.

-mike

[yo...@yoav.ws]

LGTM2

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ae091cb-fdc1-4c74-8f70-238c7e77d1c5n%40chromium.org.