-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebUSB #108
Comments
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:
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:
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: The reports attempt to summarize feedback collected during the stable period of a particular Chrome release and are titled accordingly. |
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 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: WICG/webusb#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. |
Currently a draft specification under the WICG. An explainer is also available. Issues are being tracked on GitHub.
The text was updated successfully, but these errors were encountered: