Intent to Ship: WebUSB on Dedicated Workers
odej...@chromium.org
Contact emails
odej...@chromium.org, cho...@chromium.org, rei...@chromium.org
Explainer
https://github.com/odejesush/webusb-on-workers/blob/master/EXPLAINER.md
Spec
https://wicg.github.io/webusb/
In the Device Enumeration section, the USB interface is now exposed to Dedicated Workers, and WorkerNavigator has a usb attribute available in Dedicated Workers.
Summary
This change exposes all of the WebUSB API except navigator.usb.requestDevice() to Dedicated Workers. This method is not exposed because it requires a chooser prompt to be shown to the user. Exposing this API to workers enables I/O operations and data processing for a USB device to be moved off the main thread.
Link to "Intent to Implement" blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/MReOVYgRpKk/1jY8MiyACQAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All except for Android WebView. WebUSB is not supported on Android WebView.
Demo link
Apologies in advance because this demo is internal only. The application has not been released yet.
I used performance.now() to time the file preview demo. There's a function called fileCapture() that performs the I/O to the camera and processes the data into a blob that is used to create an Image object. The function returns once all files are read. This is when the timer stops on the window context, while the worker context sends a "finished" message to the window, which stops the timer. In addition to this metric, I also recorded a profile of the file preview demo using DevTools to measure the total time that the main thread spent rendering a frame for each image drawn on the page. I measured the total time starting from when the last image finished rendering to when the current image finished rendering. In this time frame, I took the total time that the main thread spent rendering versus the total time spent idle. I performed the profile three times for each context, and I measured the times for three images in each profile. I used the averages from these to find the average percentage of time spent idle and rendering.
The measurements can be found in this document: https://docs.google.com/spreadsheets/d/1uDQqAoWZcoiKyhOhzV3z5EtH08gv8sDfnuGmjb7lMgY
Debuggability
The feature relies on the JavaScript debugging support provided by DevTools for Dedicated Workers.
Risks
Interoperability and Compatibility Risks
The interoperability and compatibility risks are the same as WebUSB however, if other browsers do implement WebUSB, then this specific feature should have low risk, since it would allow developers to move heavy data processing off of the main thread. Additionally, it is a small addition to an existing API.
Edge: No signals for the WebUSB API in general
Firefox: No signals for the WebUSB API in general
Safari: Not considering the WebUSB API in general
Web Developers: Positive, developers have specifically requested this feature:
Ergonomics
Allowing WebUSB to be used in a Dedicated Worker enables the I/O operations and data processing to be removed from the main thread. In the demo linked above, moving processing off the main thread reduces page jank while retrieving images stored on a DSLR camera.
Activation
This feature should be fairly simple for developers to use. The only requirement for the worker to use a USB device is that the page must already have requested access to the USB device by using navigator.usb.requestDevice in the window context first.
Is this feature fully tested by web platform tests?
The existing WebUSB web platform tests were modified to be multi-global tests. Therefore, the same tests are performed for Dedicated Workers. Since navigator.usb.requestDevice is not exposed to workers, it is not tested in the worker context. There is one test that is not yet implemented, and that is to check if a device that is opened in the worker is closed upon the termination of the worker. This test requires the MojoInterfaceInterceptor from a worker context to be sent to the window context to allow the window context to detect if the device was closed.
Entry on the feature dashboard
Boris Zbarsky
> Firefox: No signals
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MReOVYgRpKk/k4TdpRXWCQAJ>for
signals. This is the _second_ time I'm having to correct this claim for
WebUSB, and it's getting a bit tiring.
The Firefox signals are pretty negative on the proposal as it stands, in
case that wasn't clear.
-Boris
odej...@chromium.org
odej...@chromium.org
odej...@chromium.org
sligh...@chromium.org
Philip Jägenstedt
--
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/aeec0c99-cf73-47c5-bd6b-105c5f360d33%40chromium.org.
Yoav Weiss
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/CAARdPYeNBPD2-Q0wWqze4ARuCgPq77mfWffv9cCwGwzwpEExYw%40mail.gmail.com.
odej...@chromium.org
Boris Zbarsky
> It remains the case that other browser vendors aren't shipping Web USB
> and have concerns, but we initially shipped it in the hope that the
> merits of the API would change that given enough time.
security model and our feeling that this API is reckless [1] in terms of
its handling of security. I doubt that the merits are likely to change
that perception; what would change it is a better approach to security.
Unfortunately, Google seems unwilling to do that.
-Boris
[1] That's a direct quote from discussions with our security folks.
Philip Jägenstedt
if I even understand the concern.
Looking for privacy [1] and security [2] issues on the repo, I only
find https://github.com/WICG/webusb/issues/49 filed by someone at
Mozilla (dbaron), but that about the CORS-like model mentioned in
https://wicg.github.io/webusb/#attacking-a-device which is no longer
in the spec.
Searching widely on GitHub for
commenter:dbaron/bzbarsky/annevk/marcoscaceres/qdot and "webusb" all I
can find is some tangential discussion in
https://github.com/mozilla/standards-positions/issues/58, about Web
MIDI.
In https://github.com/mozilla/standards-positions/issues/58#issuecomment-374151418
Anne makes an interesting comment, that "Measures that solely raise
the bar before an attacker gets to that point are assumed to be in
place and rehashing them won't help this thread progress." Is this the
core of the concern with Web USB as well, that USB devices aren't
hardened against malicious input at all, and the difficulty of
conveying this to users?
Given that the API shape already allows for prompting, would a prompt
that is as scary and time-consuming to navigate as installing a native
application suffice? Or would even this not address the problem, as
Anne says?
Sorry if all of this has already been hashed out in some other forum.
[1] https://github.com/WICG/webusb/issues?q=privacy
[2] https://github.com/WICG/webusb/issues?q=security
Boris Zbarsky
> At the risk of rehashing the same discussion over and over, let me see
> if I even understand the concern.
conversations about this. I'm just watching from the sidelines, mostly.
I in this conversation because I read blink-dev while various other
people don't.
> Looking for privacy [1] and security [2] issues on the repo, I only
> find
were face-to-face discussions or emails or what.
If the issue is that the Blink team was not even aware of the concerns
on the Mozilla side, I can push people to clearly communicate those
concerns in an issue on the webusb repo. Would that be helpful?
> Is this the core of the concern with Web USB as well, that USB devices aren't
> hardened against malicious input at all, and the difficulty of
> conveying this to users?
> Given that the API shape already allows for prompting, would a prompt
> that is as scary and time-consuming to navigate as installing a native
> application suffice
about this, but two problems immediately come to mind with creating such
a prompt:
1) Once I install a native app from a trusted source, it's installed
and I don't have to worry about what happens to the source in the
future, to some extent. A permissions grant to a website doesn't have
this property, if the grant is remembered: I have to worry about XSS
bugs in the site, MITM attacks (even over https, unless key pinning
happens, thanks to TLS middleboxes), the server getting hacked and
"defaced" with attack code, etc. How does one communicate this
distinction in threat model between an application install and a web
permissions grant to a normal user?
2) The "installing a native app" flow on some operating systems is
pretty restrictive. For example, on Mac OS you have to explicitly grant
permission via the OS preferences to run an app downloaded from the web.
And even then there are restrictions to "identified developers" (or
even to the app store) and the like. What prompt do you envision that
would be as scary and time-consuming while providing equivalent vetting
for a non-administrator user account on a Mac that the administrator has
restricted to apps from the app store only?
None of that really addresses the issue of whether a prompt is
"sufficient", of course. I'm not in a position to speak to that at the
moment.
-Boris
Philip Jägenstedt
>
> On 7/20/18 7:35 AM, Philip Jägenstedt wrote:
> > At the risk of rehashing the same discussion over and over, let me see
> > if I even understand the concern.
>
> Just so we're on the same page, I haven't been directly involved in the
> conversations about this. I'm just watching from the sidelines, mostly.
> I in this conversation because I read blink-dev while various other
> people don't.
>
> > Looking for privacy [1] and security [2] issues on the repo, I only
> > find
>
> I don't know whether there are explicit issues filed or whether there
> were face-to-face discussions or emails or what.
>
> If the issue is that the Blink team was not even aware of the concerns
> on the Mozilla side, I can push people to clearly communicate those
> concerns in an issue on the webusb repo. Would that be helpful?
haven't found, I'd expect there to have been offline of f2f
discussions too.
Speaking only for myself, in order to understand the details (and
remember later) it'd be helpful with an issue on the webusb repo filed
by the would-be implementer or code/security reviewer for Gecko.
> > Is this the core of the concern with Web USB as well, that USB devices aren't
> > hardened against malicious input at all, and the difficulty of
> > conveying this to users?
>
> I believe that is the gist of things, yes.
>
> > Given that the API shape already allows for prompting, would a prompt
> > that is as scary and time-consuming to navigate as installing a native
> > application suffice
> Again, I have not been directly involved in the discussions/thinking
> about this, but two problems immediately come to mind with creating such
> a prompt:
>
> 1) Once I install a native app from a trusted source, it's installed
> and I don't have to worry about what happens to the source in the
> future, to some extent. A permissions grant to a website doesn't have
> this property, if the grant is remembered: I have to worry about XSS
> bugs in the site, MITM attacks (even over https, unless key pinning
> happens, thanks to TLS middleboxes), the server getting hacked and
> "defaced" with attack code, etc. How does one communicate this
> distinction in threat model between an application install and a web
> permissions grant to a normal user?
app that uses the network and parses the responses is in principle
susceptible to these risks as well, but how end users should think
about that I don't know.
Even if the permission isn't persisted, you're still in doubt about
whether the current site has been hacked or not, and this is true of
every permission you grant and all data you enter.
> 2) The "installing a native app" flow on some operating systems is
> pretty restrictive. For example, on Mac OS you have to explicitly grant
> permission via the OS preferences to run an app downloaded from the web.
> And even then there are restrictions to "identified developers" (or
> even to the app store) and the like. What prompt do you envision that
> would be as scary and time-consuming while providing equivalent vetting
> for a non-administrator user account on a Mac that the administrator has
> restricted to apps from the app store only?
and that the "scary and time-consuming" bit is technically easy even
though I can only imagine a caricature of the UX.
P.S. The app store bit implies a review step, which is hard to
reconcile with the web's lack of gatekeepers. Perhaps best to not
explore solutions unless that really is what it'd take for the Firefox
security reviewers to sign off on WebUSB.
Boris Zbarsky
> Speaking only for myself, in order to understand the details (and
> remember later) it'd be helpful with an issue on the webusb repo filed
> by the would-be implementer or code/security reviewer for Gecko.
> This is an interesting distinction I hadn't thought about. Any native
> app that uses the network and parses the responses is in principle
> susceptible to these risks as well
pinning is susceptible to all the same risks, basically.
> but how end users should think about that I don't know.
Explaining the risk to them would be pretty nontrivial.
> Even if the permission isn't persisted, you're still in doubt about
> whether the current site has been hacked or not
at that point you don't know whether you're downloading the right thing
either. Places that supply out-of-band cryptographic hashes of your
expected download are somewhat rare, and users who check those are
pretty rare too.
> P.S. The app store bit implies a review step, which is hard to
> reconcile with the web's lack of gatekeepers.
> Perhaps best to not
> explore solutions unless that really is what it'd take for the Firefox
> security reviewers to sign off on WebUSB.
existing solution, but with more prompting or review, as opposed to a
different solution altogether, or a more-restricted one...
-Boris
Philip Jägenstedt
>
> On 7/23/18 9:18 AM, Philip Jägenstedt wrote:
>
> > Speaking only for myself, in order to understand the details (and
> > remember later) it'd be helpful with an issue on the webusb repo filed
> > by the would-be implementer or code/security reviewer for Gecko.
>
> OK, I'll poke people.
> > This is an interesting distinction I hadn't thought about. Any native
> > app that uses the network and parses the responses is in principle
> > susceptible to these risks as well
>
> Indeed. A native app that does over-the-network updates without key
> pinning is susceptible to all the same risks, basically.
>
> > but how end users should think about that I don't know.
>
> End users have no idea these risks exist at all, generally speaking.
> Explaining the risk to them would be pretty nontrivial.
>
> > Even if the permission isn't persisted, you're still in doubt about
> > whether the current site has been hacked or not
>
> Sure, but that's not worse than the initial download of a non-web app:
> at that point you don't know whether you're downloading the right thing
> either. Places that supply out-of-band cryptographic hashes of your
> expected download are somewhat rare, and users who check those are
> pretty rare too.
>
> > P.S. The app store bit implies a review step, which is hard to
> > reconcile with the web's lack of gatekeepers.
>
> Indeed.
>
> > Perhaps best to not
> > explore solutions unless that really is what it'd take for the Firefox
> > security reviewers to sign off on WebUSB.
>
> There's an assumption here that what's needed is a signoff on the
> existing solution, but with more prompting or review, as opposed to a
> different solution altogether, or a more-restricted one...
compromises are often needed to reach interop on a new thing, and
WebUSB is probably no different. But in the "different solution
altogether" department, I lack the imagination to see any solution
that would allow the web platform to support new devices without
minting a new API each time. I guess let's discuss on the upcoming
issue(s) filed.