Discussed at London f2f

@slightlyoff to ask @reillyeon to join us on a future TAG call so we can explore some of the questions that came out of our discussions at the f2f.

Friendly ping! We'd love some feedback here :)

Discussed at Stockholm F2f Thank you for bearing with us @owencm. We are still planning to review but this has been sitting on our backlog I'm afraid. […]

Discussed at (yet another) F2F meeting in Tokyo.

Summary of feedback:

• Generally happy with this. Glad to see it moving forward. Generally a clean bill of health.
• Only major concern is that we'd like lots of example code in the spec and the explainer. Not having these makes the current spec difficult to evaluate.
• Please link to the explainer from the draft spec.
• It's unclear how to use these devices from workers and we're concerned about main-thread contention.
• We'd like to see the chooser style model for non-CORS devices explored. We understand current spec anticipates that, but want to see discussion either non-normatively in the spec or in an explainer.
• We'd like to learn results of origin trial that's currently in process (although this doesn't block anything).

Thanks again for moving this forward. Only leaving this issue open to capture future feedback.

Latest status in Chromium: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LI7O__FjIJk/6dlwUmGhFgAJ

Hey @reillyeon: just looking at this again. Was hoping we'd be able to look at more end-to-end examples. Also, is it possible to get the explainer linked from the spec?

Trolling through the open issues on WebUSB, a few of our concerns were opened there:

• https://github.com/WICG/webusb/issues/73
• https://github.com/WICG/webusb/issues/49#issuecomment-204616741
• https://github.com/WICG/webusb/issues/10

Perhaps we should be following up there.

Thank you for the review. I think I've captured the remaining TAG feedback on the issues above. Updates on the Origin Trial are distributed on the blink-dev mailing list. Here are the updates so far:

• Chrome 54
• Chrome 55
• Chrome 56

The reports attempt to summarize feedback collected during the stable period of a particular Chrome release and are titled accordingly.

While @slightlyoff follows up on the specific issues, we'll circle-back around at our next f2f.

There's an Intent to Ship for this on blink-dev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KuXx_k2KIis/-g-75FScBgAJ

If there is any further feedback that would change the shape of the API, time is of the essence.

Some members of the TAG remain philosophically concerned about the security and privacy implications that WebUSB raises. The technical question we opened is integration with the permissions API WICG/webusb#84 and we'd like to know where that stands.

While full integration with the Permission API is still a work in progress (the Permissions API spec has changed since my original integration so the current text in WebUSB does not match it well) integration with the Feature Policy spec is complete and is part of what will be shipped in Chrome 61. While the Permissions API integration is simply a restatement of the USB.requestDevice and USB.getDevices methods using concepts from the Permissions API the Feature Policy integration provides new mitigations against attack vectors such as malicious code injected through iframes. Please elaborate on your concerns and whether or not the Feature Policy integration work is relevant.

UPDATED after some experimentation and personal enlightenment.

Although late to this thread, I'd still like to give some input from my experience with WebUSB.

Web USB API only allow communication with devices that are first 'paired' by user interaction and from web applications/pages running in secure contexts. Most common interfaces (e.g. HID, Serial, etc.) will already be claimed by the system and cannot be claimed by WebUSB - so in practice - and especially on windows - one would produce firmware exposing an interface specific to WebUSB use and hence, take security considerations into account on the device side as well.

On top of this, from an OS (especially windows) point of view, Web USB eliminates potential security risks from shady drivers for new devices with only a WebUSB specific purpose.

off-topic - bear with me, please ;) ->

Outside the security aspects, I feel it's important to mention that Web USB, together with Web Bluetooth, Web Components and Progressive Web Applications, has shown (actual experience) to create a solid viable migration path for especially legacy companies stuck with potentially expensive hardware out in the field and aging native implementations with an ever increasing maintenance cost attached.

(to remove misunderstandings):

• Web USB: very minimal firmware upgrade 'web enables' legacy hardware
• Web Components: larger non-SW (only) legacy companies often have long lived code bases and can't rely on frameworks changing ever so often.
• PWA: HW connected enterprise legacy solutions should often work 'as a native app'/offline

Web USB and Web Bluetooth are essential parts in those solutions.

Taken up at Nice F2F.

Taken to breakout with @hadleybeeman @slightlyoff @dbaron @torgo.

We're having trouble finding the parts of the spec that explain which websites have the ability to have access to which devices. I was under the impression that there was both a CORS-like model where the device has data that says which origin is allowed to access it, and a chooser model where the user could choose to let a site access a USB device despite the lack of such permission on the device (and maybe the lack of anything WebUSB-specific on the device).

@dbaron In the early implementation (and spec), there was an 'allowed origins' part to be implemented in hardware. Now, the WebUSB spec and implementation has aligned more with e.g. WebBluetooth (requires user gesture, pairing, https) + Feature Policy for iframes: https://github.com/WICG/webusb/issues/82

Maybe @reillyeon can clarify

@dbaron The evolution of the design around the (now removed) CORS-like mechanism is explained in §3.2. Attacking a Device.

Permissions API integration was discussed on TAG call 31-October.

discussing some CORS and permissions API concerns via @hadleybeeman - from TPAC

taken up at London f2f

I'm happy with the permissions API outcomes. Thanks for doing that.