Intent to Implement: WebUSB on Web 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

Pull request: https://github.com/WICG/webusb/pull/130

Spec preview: https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/odejesush/webusb/worker-integration/index.bs

Summary

The ability to use WebUSB on a Web Worker will enable the API to be used on Dedicated Workers and Shared Workers. This will let pages perform heavy I/O operations on a USB device on a separate thread so that it doesn't affect the main thread of the page with a Dedicated Worker. This will also allow an origin to synchronize the state of a USB device and share data received from the device using Shared Workers.

Motivation

At the moment, it is really difficult for pages of the same to share information about a USB device, as mentioned in the following GitHub issue:  https://github.com/WICG/webusb/issues/73. This change would make it easier for developers to share the state of a USB device and data received from a USB device between users within the same origin. Additionally, it would allow developers to offload heavy I/O operations to the worker thread to allow their pages to run smoothly.

Risks: Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers:

There are positive comments in the Firefox bug for WebUSB: https://bugzilla.mozilla.org/show_bug.cgi?id=674718#c107

The Microsoft Developer feedback thread for Edge has mostly positive feedback with some negative comments on WebUSB:

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

Specifically for WebUSB on shared worker, there is also a positive comments in the following issues:

https://github.com/WICG/webusb/issues/73

https://github.com/WICG/webusb/issues/22

At the moment, only Chrome has implemented WebUSB, but there's seems to be support from developers for other browsers to implement WebUSB. As for Web Workers, Chrome, Firefox, Edge, and Safari have implemented the API. This change would only allow the two already defined specs to work together.

Activation

Developers that are already familiar with how WebUSB and Web Workers work should not have difficulty in taking advantage of this feature.

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

Yes

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=732038

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5928209916887040

Request approval to ship?

No

[Mike West]

What's the permission story here? Are you planning to allow workers to pop up a chooser themselves, or will that be mediated by the document to which the worker is bound?

This intent does not include Service Workers, right? I imagine there would be additional concerns with accessing USB devices in the background, without an active page?

-mike

--
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/b5a704df-7a84-4a61-92cb-1d5b838dcdb1%40chromium.org.

[odej...@chromium.org]

The workers will not be able to use the requestDevice method. The developer would need to call requestDevice within the Window context to grant permission to access the device, then the worker will be able to access the device using getDevices. So yes, it will be mediated by the document to which the worker is bound.

Yes, this intent does not include Service Workers. Only Shared Workers and Dedicated Workers.

Thanks for the feedback!

[Boris Zbarsky]

On 4/16/18 6:40 PM, odej...@chromium.org wrote:
> Firefox: No signals

I don't believe this is an accurate characterization.

For example, the Firefox bug for WebUSB that you cite in your intent is
marked "RESOLVED WONTFIX" (though partly because it was for FirefoxOS)
and there are comments in that bug indicating no current plans to
implement WebUSB.

Further, there are comments in
https://github.com/mozilla/standards-positions/issues/58 that indicate
that there are major concerns about the security story for WebUSB.

> At the moment, only Chrome has implemented WebUSB, but there's seems to
> be support from developers for other browsers to implement WebUSB.

Please cite support for this claim where Firefox is concerned.

-Boris

[Ian Kilpatrick]

This is a great addition to the API surface.

This is one of the things Surma and I ran into when using WebUSB to control dSLRs[1]. The desire to have everything within a worker so that camera I/O didn't jank the main thread.

One question (maybe not for the devices team) is do we expect the need for user permissions to be granted to worker threads to increase in the future? And how much work would it be to do this now? (I.e. how hard is it to have requestDevice on a worker).

[1] https://twitter.com/DasSurma/status/982275228956024832

--
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.

[odej...@chromium.org]

Thank you for your correction. I will update the signal for Firefox in the Chrome Platform Status entry to reflect their position on WebUSB.

For the second concern that you brought up, I meant to say that there seems to be mostly positive support from web developers for the WebUSB API as a whole based on the comments that I saw in the links posted above, with some support for enabling WebUSB to work in a Dedicated or Shared Worker. I apologize if it seemed that I was claiming that browsers showed positive support.

Please let me know if there are other concerns that you have.

Thank you,

Ovidio

[Boris Zbarsky]

On 4/17/18 4:44 PM, odej...@chromium.org wrote:
> Thank you for your correction. I will update the signal for Firefox in
> the Chrome Platform Status entry to reflect their position on WebUSB.

Note that we don't have an official position at this time, by the way.
I know that's not very helpful, but I just want us all to be clear on
where things stand.

> For the second concern that you brought up, I meant to say that there
> seems to be mostly positive support from web developers for the WebUSB
> API as a whole

Ah, OK. Sorry, that was a misunderstanding on my part.

-Boris

[Adam Rice]

it will be mediated by the document to which the worker is bound.

What does this mean in the context of a Shared Worker? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ef3a07f-3d9a-4832-9bb5-e2e873830e9f%40chromium.org.

[odej...@chromium.org]

For a Shared Worker, they would be mediated by the origin that started it. A page would request the device to get permission to access the device, and then start a Shared Worker. The Shared Worker would be able to access the device using getDevices. All of the pages that connect to the Shared Worker from the same origin would be able to use the device for I/O operations through the Shared Worker.

[odej...@chromium.org]

Hi Ian I might not be able to answer your questions completely but at the moment, there is no plan to add requestDevice support to the worker because we would have to handle how to display the chooser prompt. In order to keep it simple to implement, we would require the page to request the device beforehand to get permission for the worker. One thing that we might consider in the future would to be allow a device to be passed to a worker using postMessage.

I hope this helps.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ian Kilpatrick]

Thanks, yeah totally understand the complexity here.

Mainly want to make sure we investigate how complex requestDevice would be if we could plumb through user activation data in a sane/correct/thread-safe way. Might be worth quickly talking to the input team about this. (Primarily just want to make sure if we start seeing this in more web APIs we are able to do it in a good way, and don't start "bending" other APIs in a weird way).

That said - supporting and shipping just getDevices on workers is a great step. Can't wait! :)

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/b5a704df-7a84-4a61-92cb-1d5b838dcdb1%40chromium.org.

--

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/6cab7161-421f-4b78-8d18-bfd503f320d3%40chromium.org.

[odej...@chromium.org]

Thanks for the suggestion. I posted a thread to input-dev asking about sending user activation data from a worker thread to the main thread. I CC'd you on in, but I'll also post the link here for anyone else that would like to see it: https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/BngXXJaSWno

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5a704df-7a84-4a61-92cb-1d5b838dcdb1%40chromium.org.

--
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+unsubscribe@chromium.org.

[cho...@chromium.org]

+Chrome Worker team for wider discussions.

There are some concerns / objections regarding making the feature depending on Shared Worker (Cannot forward since it was on the internal mailing list).

A summary of bullet points are:

• Shared Worker is only supported by Chrome and Firefox, and could face deprecation.
  
• Safari dropped support in https://bugs.webkit.org/show_bug.cgi?id=116359#c6 due to the lack of use cases.
• (No signal from Edge?)
• (Do we have signals from ChromeOS? It'd nice if they could be CCed on this thread)
• Alternatives are considered (e.g. Broadcast Channel, Web Locks, Service Worker) but they don't fit into the model well.
• Broadcast Channel, Web Locks: Still tab-centralized, and we have to make USBDevice objects transferrable.
• Service Worker: Lifetime and security concerns.
  
• Chicken-and-egg problem (quoted from jsbell@ as the last message in the mailing list):

re: Shared Workers

I haven't heard a lot of strong interest from developers. It's unfortunately a bit of a chicken-and-egg thing - as Reilly notes, if all browsers supported Shared Workers and if they had client connect/disconnect events, then dedicated APIs like Locks and BroadcastChannel and IDB Observers wouldn't be necessary. One could argue we should push harder on rounding out the feature set for Shared Workers, but other browsers seem more amenable to adding small API primitives vs. adding such a big hammer. So we seem to be slowly chipping away at the need for it.

Also, the set of developers who really worry about optimizing for multi-tab cases appears to be quite small - e.g. productivity apps on the scale of Google Docs. And those either are Chrome-only (so Shared Worker is fine) or already have workarounds, and most are somewhere in the process of migrating to Service Workers. With adoption of Service Workers by all browsers and the offline/responsiveness ability that grants, it pushes developers to a pattern of heavyweight, mostly independent tabs with lightweight, ephemeral coordination, rather than centralized and persistent application logic with multiple lightweight views. So... Shared Workers remain a useful tool, but there's dwindling incentive for developers to use it.

Please add if I missed something.

---

So my question is: Do we have a general guideline on deciding whether to invest on a feature?

I'm feeling that Chrome has to lead in this specific area since we care more about capabilities and the potential hardware ecosystem[1].

Thanks!

Chong

[1] WebUSB Intent-to-Ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KuXx_k2KIis/0t5tHA4ZBQAJ

[odej...@chromium.org]

I'll add some updates to some of these sections:

Explainer

The explainer link is still good, however I also have a design document that expands on the explainer: https://docs.google.com/document/d/16T3rhUtYg3GBGotj_pPUXmGmYbf15qdYNEYf4LhKAhM

Spec

The WebUSB spec has been updated to expose the API to WorkerNavigator for Dedicated and Shared Workers: https://wicg.github.io/webusb/

The PRs with the changes are the following:

• https://github.com/WICG/webusb/pull/130
  
• https://github.com/WICG/webusb/pull/131
  
• https://github.com/WICG/webusb/pull/134

OWP Launch Tracking Bug

I created a tracking bug for the feature: https://crbug.com/837406

The previously linked bug was an issue that someone else opened suggesting that WebUSB should be usabled from a worker.

Currently, WebUSB is usable in a Dedicated Worker using the WebUSBOnDedicatedAndSharedWorkers blink feature flag. The feature was tested with real USB devices using a modified version of the Weblight project, which can be found in my fork of the project. The relevant Gerrit changes are the following:

• https://chromium-review.googlesource.com/c/chromium/src/+/1014196
  
• https://chromium-review.googlesource.com/c/chromium/src/+/1024724
  
• https://chromium-review.googlesource.com/c/chromium/src/+/1045309

Thanks Chong for suggesting to move the discussion here.

[cho...@chromium.org]

On Wednesday, May 30, 2018 at 11:43:32 AM UTC-7, cho...@chromium.org wrote:

+Chrome Worker team for wider discussions.

There are some concerns / objections regarding making the feature depending on Shared Worker (Cannot forward since it was on the internal mailing list).

A summary of bullet points are:

• Shared Worker is only supported by Chrome and Firefox, and could face deprecation.
  
• Safari dropped support in https://bugs.webkit.org/show_bug.cgi?id=116359#c6 due to the lack of use cases.
• (No signal from Edge?)
• (Do we have signals from ChromeOS? It'd nice if they could be CCed on this thread)

Just a clarification: By "signals from ChromeOS" I'm referring to first-party apps. e.g. PWA file manager, PTP, or MTP.

[odej...@chromium.org]

I have updated the design document with two potential alternatives to WebUSB on Shared Workers. The link to the section is the following: https://docs.google.com/document/d/16T3rhUtYg3GBGotj_pPUXmGmYbf15qdYNEYf4LhKAhM/edit#heading=h.gzb1boy43pyp

I'll also summarize WebUSB on shared workers and the two alternatives below.

The main reason for WebUSB on Shared Workers is to have a single context that connects to a USB device and perform I/O operations on behalf of the connected contexts. The connected contexts can use the MessagePort to send data to or receive data from the USB device.

The first alternative is to use WebUSB with the Web Locks API to allow contexts to coordinate their access to the USB device. WebUSB would need to be modified to allow a USB device to be shared across an origin rather than just a single context. The shared USB device would reflect it's state across the contexts, and serialize requests to the device from the contexts. Since USB devices are unable to distinguish requests from different sources, Web Locks would allow contexts to acquire a lock before performing I/O operations on the USB device.

The second alternative is to enable Service Workers to use WebUSB. However, this alternative would require a lot of different questions to be resolved, such as what a request for a USB device should do if the service worker is running in the background without open frames. Some of these questions are listed in the Service Worker section of the design document.

Feedback on these approaches is very welcome and appreciated!

On Wednesday, May 30, 2018 at 11:43:32 AM UTC-7, cho...@chromium.org wrote:

[k...@karelbilek.com]

Hello,

I was asked on github to comment on webusb+shared worker and how we use it in our web app

I wrote something, maybe a bit too verbosely :)

See

https://github.com/WICG/webusb/issues/73#issuecomment-395262361

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/b5a704df-7a84-4a61-92cb-1d5b838dcdb1%40chromium.org.

--
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.

[odej...@chromium.org]

At the moment, I will only implement WebUSB on Dedicated Workers for now.

On Monday, April 16, 2018 at 3:43:10 PM UTC-7, odej...@chromium.org wrote:

[Anne van Kesteren]

On Thu, Jun 28, 2018 at 8:32 PM, <odej...@chromium.org> wrote:
> At the moment, I will only implement WebUSB on Dedicated Workers for now.

What's the strategy for dedicated workers spawned from shared or
service workers? (Perhaps this isn't possible yet in Chrome, but it
seems like a number of features are running into this.)


--
https://annevankesteren.nl/

[odej...@chromium.org]

For now, dedicated workers spawned from another context other than a window or a parent dedicated worker will not be able to use WebUSB. We did have a small discussion about the case for dedicated workers spawned from shared workers in the following link if you're interested: https://chromium-review.googlesource.com/c/chromium/src/+/1098031/1/third_party/blink/renderer/modules/webusb/usb.cc#282.

WebUSB currently uses the render frame of a page to enforce the permissions in Chrome. As a result, this permission model would need to be modified for shared workers, since they can have multiple render frames associated with it. I outlined a way to do allow WebUSB to work in Shared Workers in my design document, but it is a workaround to not being able to access the worker code in `content/browser/` from `chrome/browser`. If support is added for dedicated workers spawned from shared workers in Chrome, then perhaps the changes to the worker code would allow us to easily implement WebUSB for it, or to at least detect if the dedicated worker was spawned from a shared worker to prevent the use of the API.