Intent to Implement and Ship: Nested dedicated workers

[Nate Chapin]

Contact emails

jap...@chromium.org

Spec

References to nested workers are spread through section 10 of the HTML spec. For example, https://html.spec.whatwg.org/#the-worker's-workers

Summary

Workers should be able to spawn additional, descendant dedicated workers.

This exposes the dedicated worker constructor to shared workers and dedicated workers.  While there has been discussion about allowing service workers to create dedicated workers, there is no spec support at this time.

Note that the spec states that we should also be able to create shared workers from a dedicated worker or shared worker, but that is substantially more complex to implement, so there is no immediate plan to support it.

Motivation

Spec support for nested workers is old, and lack of nested worker support is one of our more glaring divergences from the spec. https://bugs.chromium.org/p/chromium/issues/detail?id=31666, which requests this feature, is one of the most starred Blink issues in the bug tracker.

Nested workers would allow libraries which use workers to be adapted to run in a worker context themselves, giving developers more options to move business logic off of the main thread.

Risks

Interoperability and Compatibility

Edge: Shipped

Firefox: Shipped

Safari: There's an open WebKit issue, but no recent activity: https://bugs.webkit.org/show_bug.cgi?id=22723

Web developers: In favor, if https://bugs.chromium.org/p/chromium/issues/detail?id=31666 is any indication. It’s the 11th most starred component:Blink bug in the chromium tracker.

Ergonomics

It's unclear to me how much effort should be put in to preventing developers from shooting themselves in the foot with workers (e.g., by preventing infinite recursion or putting a limit on the total number of workers that can be active at a given time). There isn't anything specific in the spec at the moment, but I'm open to suggestions.

Activation

Using nested dedicated workers should be no more difficult than using normal dedicated workers.  This change would make it possible to use libraries from a worker that themselves create worker, which makes adopting workers more viable for library authors.

There may be additional work to do regarding memory consumption and preventing developers from exhausting memory if it becomes apparent that there are strong use cases for having many nested workers.

Debuggability

Nested workers should be visible in developer tools, just like any other worker. There is, however, no indication that they are nested or which other worker owns the nested worker. I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=848450 to follow up on that.

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

Yes.

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

* external/wpt/workers/nested_worker.worker.js exercises basic functionality.

* html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/ tests shared array buffers in nested worker contexts.

* external/wpt/secure-contexts/ exercises their security properties.

* external/wpt/websockets/Create-on-worker-shutdown.any.js tests websocket creation in nested workers.

My draft CL also adds tests to verify sync XHR and importScripts() in nested workers, and modifies an existing worker modules test to test the ability to load modules into nested workers.

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes.

[Jochen Eisinger]

lgtm1 \o/

--
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/CACf%3D2LLGj-d4GWrpcKig6EZHmxXChey6jCtutaW05y5mWvZi8w%40mail.gmail.com.

[Ben Kelly]

On Mon, Jun 4, 2018 at 2:33 PM, Nate Chapin <jap...@chromium.org> wrote:

Summary

Workers should be able to spawn additional, descendant dedicated workers.

This exposes the dedicated worker constructor to shared workers and dedicated workers.  While there has been discussion about allowing service workers to create dedicated workers, there is no spec support at this time.

Note that the spec states that we should also be able to create shared workers from a dedicated worker or shared worker, but that is substantially more complex to implement, so there is no immediate plan to support it.

Are you supporting nested dedicated workers under a parent shared worker?  It was not clear to me if you were excluding that case as well here or only excluding nested shared workers.

Thanks.

Ben

[Nate Chapin]

Yes. Either a dedicated worker or a shared worker can be the parent, but only a dedicated worker can be the child.  Sorry for the confusion.

~Nate

 

[Ben Kelly]

Hmm, ok.  We don't support this in firefox currently and haven't though of it as a priority previously.  Do you know if edge supports it?

Thanks again.

Ben

[Nate Chapin]

I ran https://w3c-test.org/secure-contexts/shared-worker-insecure-first.https.html in Edge and Firefox just now. Edge appears to create the nested dedicated worker inside a shared worker in the last test, but fails later in the test. Firefox passes all 4 tests.  Have I misunderstood what this test does, or does Firefox at least make it partway through constructing a dedicated worker from a shared worker?
~Nate

 

 

[Ben Kelly]

On Mon, Jun 4, 2018 at 4:14 PM, Nate Chapin <jap...@chromium.org> wrote:

I ran https://w3c-test.org/secure-contexts/shared-worker-insecure-first.https.html in Edge and Firefox just now. Edge appears to create the nested dedicated worker inside a shared worker in the last test, but fails later in the test. Firefox passes all 4 tests.  Have I misunderstood what this test does, or does Firefox at least make it partway through constructing a dedicated worker from a shared worker?

You are correct.  Firefox does indeed support nested dedicated workers within SharedWorker.  Sorry for my confusion!

[TAMURA, Kent]

LGTM2!

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

--

TAMURA Kent
Software Engineer, Google

[Nate Chapin]

I just double-checked, and I misread the test output for Edge. Edge doesn't implement SharedWorker at all.

~Nate

[Daniel Bratell]

LGTM3

(some concerns about how to prevent foot gun shooting, or user shooting by exhausting computer resources but I think you'll figure that out on the way)

/Daniel

--
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/CACf%3D2LJC2GOik%2BMnmp%2BKaXWeAgPRKhgDyRpmruFic5opNDfSkA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Daniel Vogelheim]

On Mon, Jun 4, 2018 at 8:33 PM Nate Chapin <jap...@chromium.org> wrote:

Risks

Interoperability and Compatibility

Edge: Shipped

Firefox: Shipped

Safari: There's an open WebKit issue, but no recent activity: https://bugs.webkit.org/show_bug.cgi?id=22723

Web developers: In favor, if https://bugs.chromium.org/p/chromium/issues/detail?id=31666 is any indication. It’s the 11th most starred component:Blink bug in the chromium tracker.

Ergonomics

It's unclear to me how much effort should be put in to preventing developers from shooting themselves in the foot with workers (e.g., by preventing infinite recursion or putting a limit on the total number of workers that can be active at a given time). There isn't anything specific in the spec at the moment, but I'm open to suggestions.

Activation

Using nested dedicated workers should be no more difficult than using normal dedicated workers.  This change would make it possible to use libraries from a worker that themselves create worker, which makes adopting workers more viable for library authors.

There may be additional work to do regarding memory consumption and preventing developers from exhausting memory if it becomes apparent that there are strong use cases for having many nested workers.

Exhausting memory/cpu might be a security issue (basically, some low-grade "ransomware", where a malicious page might cause harm by slowing down your computer or crashing (other) tabs by forcing out of memory situations). I don't think of this as super serious, but it might be worth putting some reasonable limit on worker creation, or maybe gating it on memory availability.

[Matt Falkenhagen]

I don't think nested workers change the security aspect. You can easily hit an OOM today (sad tab) by creating many non-nested workers. The risk with nested workers is about if well-intentioned sites start more easily hitting the OOM if nested workers induce an increase in the number of workers.

 

--
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/CALG6KPNTV0OtmSsbbjs18H2sL2%3Da6pSmHWy8uC9Z361EgtF82A%40mail.gmail.com.

[Daniel Bratell]

On Sat, 09 Jun 2018 16:43:42 +0200, Matt Falkenhagen <fal...@chromium.org> wrote:

On Sat, Jun 9, 2018 at 12:54 AM, Daniel Vogelheim <voge...@chromium.org> wrote:

On Mon, Jun 4, 2018 at 8:33 PM Nate Chapin <jap...@chromium.org> wrote:

Risks

Interoperability and Compatibility

Edge: Shipped

Firefox: Shipped

Safari: There's an open WebKit issue, but no recent activity: https://bugs.webkit.org/show_bug.cgi?id=22723

Web developers: In favor, if https://bugs.chromium.org/p/chromium/issues/detail?id=31666 is any indication. It’s the 11th most starred component:Blink bug in the chromium tracker.

Ergonomics

It's unclear to me how much effort should be put in to preventing developers from shooting themselves in the foot with workers (e.g., by preventing infinite recursion or putting a limit on the total number of workers that can be active at a given time). There isn't anything specific in the spec at the moment, but I'm open to suggestions.

Activation

Using nested dedicated workers should be no more difficult than using normal dedicated workers.  This change would make it possible to use libraries from a worker that themselves create worker, which makes adopting workers more viable for library authors.

There may be additional work to do regarding memory consumption and preventing developers from exhausting memory if it becomes apparent that there are strong use cases for having many nested workers.

Exhausting memory/cpu might be a security issue (basically, some low-grade "ransomware", where a malicious page might cause harm by slowing down your computer or crashing (other) tabs by forcing out of memory situations). I don't think of this as super serious, but it might be worth putting some reasonable limit on worker creation, or maybe gating it on memory availability.

I don't think nested workers change the security aspect. You can easily hit an OOM today (sad tab) by creating many non-nested workers. The risk with nested workers is about if well-intentioned sites start more easily hitting the OOM if nested workers induce an increase in the number of workers.

If it's just OOM as in "hitting the 2 GB RAM" limit, then it's a known problem that sites can easily trigger the oom suicide. A new risk would be if you could exhaust all the RAM in the computer by spawning many processes each using ~2 GB. That could bring the whole computer to its knee rather than just killing a browser tab. And thinking about it, that would be a risk in the OOPIF project as well.

/Daniel

[Nate Chapin]

Nested dedicated workers might make such an attack easier by making it easier to use large amounts of memory in a given process, but they aren't sufficient in and of themselves, because they don't result in creation of a new process. A dedicated worker always runs on a new thread in the same process as its owner.

~Nate

 

[odej...@google.com]

Would a worker be able to tell if it was started by a dedicated or shared worker? I currently have an implementation for WebUSB on Dedicated Workers behind a runtime flag, and WebUSB uses the parent frame of the worker to enforce device access permissions. If a Dedicated Worker is created by a Shared Worker, then what would be the parent frame in that case? I saw a comment in the draft CL mention that the Dedicated Worker would get the shadow frame of the Shared Worker. If this is the case, I'm not sure how WebUSB would behave.

[Anne van Kesteren]

On Wed, Jun 13, 2018 at 11:35 PM, odejesush via blink-dev
<blin...@chromium.org> wrote:
> Would a worker be able to tell if it was started by a dedicated or shared
> worker?

You can look at the global's "owner set" (see the HTML Standard). If
we're going to restrict certain APIs to a particular agent cluster we
should maybe add more IDL features so the API is not exposed in
dedicated workers created from a shared or service worker.


--
https://annevankesteren.nl/

[Nate Chapin]

Update: concerns came up during code review that allowing the creation of dedicated workers from a shared worker would lead to dependencies on deprecated code that would be difficult to untangle, so for the initial commit we are only going to support nesting dedicated->dedicated.  I hope to add shared->dedicated nesting soon.