Intent to Ship: WebUSB

[Reilly Grant]

Contact emails

owe...@chromium.org, rei...@chromium.org

Spec

https://wicg.github.io/webusb/

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

Summary

Users purchase devices and connect them to their computers. Most of these devices are enabled by existing high-level web platform APIs (e.g. keyboards, mice, printers, gamepads). The WebUSB API is designed to support the long tail of hardware peripherals such as special-purpose educational, scientific and industrial devices. WebUSB allows users to avoid installing (often sketchy) native drivers and applications, and instead access them via a more sandboxed web application.

Installing native applications or drivers grants broad access to the system. In contrast, the sandboxed web application environment provides significant isolation.

Similar to file and Bluetooth access, WebUSB uses a chooser model. Web applications have no knowledge of connected devices until a selection of a particular device is made and confirmed in the chooser.

Link to “Intent to Implement” blink-dev discussion

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

Link to Origin Trial feedback summary

https://docs.google.com/document/d/1NPG08-yfo-c9FOJ_WCBMOWAyF7VpQdcncW0iysUn7I0/edit

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

All except for Android WebView.

Demo link

https://sowbug.github.io/weblight

Debuggability

This feature relies on the existing JavaScript debugging support provided by DevTools. There is an opportunity, however, to build additional debugging tools such as request tracing.

Interoperability and Compatibility Risk

As a new API with no other vendor expressing they will implement, the primary risk of shipping this API is that no other implementations will be created.

We have worked to mitigate this risk by, submitting the API for TAG review and soliciting feedback from developers experimenting with the API through an Origin Trial in order to build assurance that the shape of the API is correct, and building a set of tests that can be upstreamed to the web-platform-tests repository in order to give other implementers a clear path towards interoperability.

Edge: No signals

Firefox: Uncertainty

Safari: No signals

Web developers: Positive (collected from Origin Trial feedback)

Why now? Hardware development cycles are long. Outside of the maker space it will take time for device manufacturers to build hardware taking advantage of this capability. They won’t do so until WebUSB is considered available, and shipping is necessary to do that. Other browser implementors are likely to either agree with the potential, or wait and see evidence of manufacturers building web applications.

How do we measure success? We never expect to have high utilization because it will be used only by applications built for long tail peripherals. In our early experience deprecation features we learned that, “Percent of page views by itself is not the only metric we care about.” Even infrequent use demonstrates value (e.g. setting up a device, uploading new audio to a toy, or upgrading firmware). Performed only once a year these are significant moments. We will judge the success of this feature launch on the long term trend in adoption.

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

This feature is partially tested by web-platform-tests/webusb. There is a plan to move the remaining tests in LayoutTests/usb into web-platform-tests however it is blocked on discussion on the public-t...@w3.org mailing list to determine if such tests (which require a test-only API) will be useful for future implementers.

OWP launch tracking bug

https://crbug.com/492204

Entry on the feature dashboard

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

[Rick Byers]

Thanks for all the care around eventual interop and security here.  I agree the potential of supporting a new hardware ecosystem (even if primarily niche devices) is worth the interop risk.  LGTM1

--
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/CAEmk%3DMb4VkiawLRL8YJJi%2B0gw7GKkeNUyVgt0q948u0TXrrp0g%40mail.gmail.com.

[Jochen Eisinger]

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

thanks

-jochen

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

[Reilly Grant]

On Mon, May 29, 2017 at 8:05 AM Jochen Eisinger <joc...@chromium.org> wrote:

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

Yes. It was recommended to me not to define UX in the specification and only provide the extension points where a UA can choose to implement a particular policy, especially around security UX where we have been doing a lot of experimentation.

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

There is nothing in the specification to limit the device classes that could be accessed with this API however the implementation is limited by the host operating systems on which the UA runs. In all cases a device which is supported by the host operating system (that is, has a kernel or user-space driver claiming it) cannot be claimed by Chrome and so the examples you cite above are disallowed.

The intention of this API is to allow the web to fill in the gaps in native support, particularly in the long tail of uncommon (and non-standard) peripherals, providing a mechanism for supporting devices where the UA does not offer a higher-level API.

[Jochen Eisinger]

On Mon, May 29, 2017 at 8:06 PM Reilly Grant <rei...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:05 AM Jochen Eisinger <joc...@chromium.org> wrote:

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

Yes. It was recommended to me not to define UX in the specification and only provide the extension points where a UA can choose to implement a particular policy, especially around security UX where we have been doing a lot of experimentation.

Ok, so I assume you go through the regular chrome launch review to ensure that security UX is onboard? Can you point me at the chrome-launch issue please?

 

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

There is nothing in the specification to limit the device classes that could be accessed with this API however the implementation is limited by the host operating systems on which the UA runs. In all cases a device which is supported by the host operating system (that is, has a kernel or user-space driver claiming it) cannot be claimed by Chrome and so the examples you cite above are disallowed.

The intention of this API is to allow the web to fill in the gaps in native support, particularly in the long tail of uncommon (and non-standard) peripherals, providing a mechanism for supporting devices where the UA does not offer a higher-level API.

I wonder why the security considerations section in the spec then explicitly calls out e.g. printers, as it shouldn't be possible to connect to a printer using this API anyways?

[Owen Campbell-Moore]

Yes, this is fully approved by Chrome launch review: https://bugs.chromium.org/p/chromium/issues/detail?id=576958

We also got approval at one final security review with Chris Palmer last week (despite technically already being approved) just to ensure we're all on the same page about shipping now.

[Vincent Scheib]

On Tue, May 30, 2017 at 10:58 AM, 'Owen Campbell-Moore' via blink-dev <blin...@chromium.org> wrote:

Yes, this is fully approved by Chrome launch review: https://bugs.chromium.org/p/chromium/issues/detail?id=576958

We also got approval at one final security review with Chris Palmer last week (despite technically already being approved) just to ensure we're all on the same page about shipping now.

See recent Palmer WebUSB security reply on the Proposal for Allowing WebUSB from Any Origin thread.

[Reilly Grant]

On Tue, May 30, 2017 at 6:22 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:06 PM Reilly Grant <rei...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:05 AM Jochen Eisinger <joc...@chromium.org> wrote:

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

Yes. It was recommended to me not to define UX in the specification and only provide the extension points where a UA can choose to implement a particular policy, especially around security UX where we have been doing a lot of experimentation.

Ok, so I assume you go through the regular chrome launch review to ensure that security UX is onboard? Can you point me at the chrome-launch issue please?

 

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

There is nothing in the specification to limit the device classes that could be accessed with this API however the implementation is limited by the host operating systems on which the UA runs. In all cases a device which is supported by the host operating system (that is, has a kernel or user-space driver claiming it) cannot be claimed by Chrome and so the examples you cite above are disallowed.

The intention of this API is to allow the web to fill in the gaps in native support, particularly in the long tail of uncommon (and non-standard) peripherals, providing a mechanism for supporting devices where the UA does not offer a higher-level API.

I wonder why the security considerations section in the spec then explicitly calls out e.g. printers, as it shouldn't be possible to connect to a printer using this API anyways?

The spec calls out printers because they are a familiar example of devices that manipulate the world.

To correct my earlier comment, "In all cases a device which is supported by the host operating system [...] cannot be claimed by Chrome and so the examples you cite above are disallowed," as it applies to printers: 

Depending on the platform and hardware a particular printer may or may not be accessible via WebUSB. They are less standardized than keyboards, mice, storage devices and webcams which have kernel drivers blocking direct access by the browser. There is a spectrum of printer hardware and some may be underserved by the platform's existing printing support and work better with WebUSB. A label printer exposes a much more restricted printing capability. 

Attempting to define the class of "printer" is difficult because USB devices have limited metadata available to make that decision so we defer to the OS for all devices.

Looking forward, I think printers are a good test case for what happens when a device class for which WebUSB was used during early standardization is eventually supported by high-level APIs.

Imagine that we later develop a printing API which serves the label printer use case. How aggressively should we block access to these devices through WebUSB? We choose to leave it open as the printing API has a lower permission barrier than WebUSB.

[Jochen Eisinger]

On Wed, May 31, 2017 at 3:32 AM Reilly Grant <rei...@chromium.org> wrote:

On Tue, May 30, 2017 at 6:22 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:06 PM Reilly Grant <rei...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:05 AM Jochen Eisinger <joc...@chromium.org> wrote:

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

Yes. It was recommended to me not to define UX in the specification and only provide the extension points where a UA can choose to implement a particular policy, especially around security UX where we have been doing a lot of experimentation.

Ok, so I assume you go through the regular chrome launch review to ensure that security UX is onboard? Can you point me at the chrome-launch issue please?

 

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

There is nothing in the specification to limit the device classes that could be accessed with this API however the implementation is limited by the host operating systems on which the UA runs. In all cases a device which is supported by the host operating system (that is, has a kernel or user-space driver claiming it) cannot be claimed by Chrome and so the examples you cite above are disallowed.

The intention of this API is to allow the web to fill in the gaps in native support, particularly in the long tail of uncommon (and non-standard) peripherals, providing a mechanism for supporting devices where the UA does not offer a higher-level API.

I wonder why the security considerations section in the spec then explicitly calls out e.g. printers, as it shouldn't be possible to connect to a printer using this API anyways?

The spec calls out printers because they are a familiar example of devices that manipulate the world.

To correct my earlier comment, "In all cases a device which is supported by the host operating system [...] cannot be claimed by Chrome and so the examples you cite above are disallowed," as it applies to printers: 

Depending on the platform and hardware a particular printer may or may not be accessible via WebUSB. They are less standardized than keyboards, mice, storage devices and webcams which have kernel drivers blocking direct access by the browser. There is a spectrum of printer hardware and some may be underserved by the platform's existing printing support and work better with WebUSB. A label printer exposes a much more restricted printing capability. 

Attempting to define the class of "printer" is difficult because USB devices have limited metadata available to make that decision so we defer to the OS for all devices.

Looking forward, I think printers are a good test case for what happens when a device class for which WebUSB was used during early standardization is eventually supported by high-level APIs.

Imagine that we later develop a printing API which serves the label printer use case. How aggressively should we block access to these devices through WebUSB? We choose to leave it open as the printing API has a lower permission barrier than WebUSB.

printing requires explicit user consent every time you invoke the API. How is the barrier for WebUSB higher?

[Reilly Grant]

On Wed, May 31, 2017 at 4:03 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Wed, May 31, 2017 at 3:32 AM Reilly Grant <rei...@chromium.org> wrote:

On Tue, May 30, 2017 at 6:22 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:06 PM Reilly Grant <rei...@chromium.org> wrote:

On Mon, May 29, 2017 at 8:05 AM Jochen Eisinger <joc...@chromium.org> wrote:

Reading through the spec, it sounds like the UA might chose to not prompt the user to grant permission to a device?

Yes. It was recommended to me not to define UX in the specification and only provide the extension points where a UA can choose to implement a particular policy, especially around security UX where we have been doing a lot of experimentation.

Ok, so I assume you go through the regular chrome launch review to ensure that security UX is onboard? Can you point me at the chrome-launch issue please?

 

I also wonder whether it makes sense to only allow certain device classes? Specifically, what's the motivation of exposing devices via WebUSB that could otherwise be used over other APIs? E.g., if the user once grants access to a video device, will the site then be possible to use that device in the future without the typical video indicator that we show for WebRTC popping up? Or for printers, would a site then be able on subsequent visits to print without further user interaction?

There is nothing in the specification to limit the device classes that could be accessed with this API however the implementation is limited by the host operating systems on which the UA runs. In all cases a device which is supported by the host operating system (that is, has a kernel or user-space driver claiming it) cannot be claimed by Chrome and so the examples you cite above are disallowed.

The intention of this API is to allow the web to fill in the gaps in native support, particularly in the long tail of uncommon (and non-standard) peripherals, providing a mechanism for supporting devices where the UA does not offer a higher-level API.

I wonder why the security considerations section in the spec then explicitly calls out e.g. printers, as it shouldn't be possible to connect to a printer using this API anyways?

The spec calls out printers because they are a familiar example of devices that manipulate the world.

To correct my earlier comment, "In all cases a device which is supported by the host operating system [...] cannot be claimed by Chrome and so the examples you cite above are disallowed," as it applies to printers: 

Depending on the platform and hardware a particular printer may or may not be accessible via WebUSB. They are less standardized than keyboards, mice, storage devices and webcams which have kernel drivers blocking direct access by the browser. There is a spectrum of printer hardware and some may be underserved by the platform's existing printing support and work better with WebUSB. A label printer exposes a much more restricted printing capability. 

Attempting to define the class of "printer" is difficult because USB devices have limited metadata available to make that decision so we defer to the OS for all devices.

Looking forward, I think printers are a good test case for what happens when a device class for which WebUSB was used during early standardization is eventually supported by high-level APIs.

Imagine that we later develop a printing API which serves the label printer use case. How aggressively should we block access to these devices through WebUSB? We choose to leave it open as the printing API has a lower permission barrier than WebUSB.

printing requires explicit user consent every time you invoke the API. How is the barrier for WebUSB higher?

It's true that printing requires explicit consent every time. I was thinking about how the print preview dialog box is pre-populated with default settings so only two user gestures are required for a single print while the WebUSB chooser requires three because a specific device needs to be selected first.

To mitigate the more persistent access that WebUSB provides we have a tab indicator for when it is in use.

[Jochen Eisinger]

ok thanks for answering all my questions.

I think API wise, this makes sense, and I trust the review from Chris has covered all the security questions, so lgtm1

[Philip Jägenstedt]

Rick has already LGTMd, so that makes 2xLGTM.

Given the size of the API (implementation effort) and the fact that it caters to the long tail of hardware peripherals, I think the interop is higher than usual, in that other vendors may perpetually have other things higher on their priority list.

Edge: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/16268590-support-webusb-api

WebKit: https://webkit.org/status/#feature-webusb

However, I do not see that there's much that can be done apart from waiting, and the potential upside of shipping this seems large.

The discussion about web-platform-tests continues, and isn't blocking.

LGTM3

--

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/CALjhuifu574T7EGiXoP7h-UYqfOBSq0%3DQy%2BYjvuc5YOF4nL0Hw%40mail.gmail.com.

[j.j.]

Am Dienstag, 23. Mai 2017 21:37:48 UTC+2 schrieb Reilly Grant:

As a new API with no other vendor expressing they will implement, the primary risk of shipping this API is that no other implementations will be created.

We have worked to mitigate this risk by, submitting the API for TAG review and soliciting feedback from developers experimenting with the API through an Origin Trial in order to build assurance that the shape of the API is correct, and building a set of tests that can be upstreamed to the web-platform-tests repository in order to give other implementers a clear path towards interoperability.

Edge: No signals

Firefox: Uncertainty

Safari: No signals

Web developers: Positive (collected from Origin Trial feedback)

Interoperability and Compatibility Risk

FWIW: There is no plan to implement WebUSB in Firefox, see

https://bugzilla.mozilla.org/show_bug.cgi?id=674718#c108