Should a service worker be allowed to register new service workers?

[mkruisselbrink]

In the spec as currently written navigator.serviceWorker.register is exposed in all worker contexts, including service workers. That will then allow a service worker to register arbitrarily many new service workers (which could be nicely abused for some sort of nested worker support), as long as it uses different scopes for each. Is that desirable though?
Currently no implementation seems to actually have implemented navigator.serviceWorker in service worker contexts (or in any worker contexts for that matter, as far as I can tell). But if they do, and this is actually something that should be supported implementations need to be careful that this isn't an avenue that can be used to keep a worker alive indefinitely (by "forking" itself repeatedly before it is killed).

[deepduggal]

It would be a wasted opportunity if one service worker could not register another. The goal of a service worker is to allow scripts to respond to events in the background. Some events will require specific scripts to handle them.

Not allowing a service worker to register other service workers will encourage larger, service workers that can handle all outcomes and disfavor smaller, modular service workers that are built to handle specific tasks.

It would be imprudent, inefficient, and just not cool to do so.

Nonetheless, security is going to be a major concern with this, so it would be best to proceed with caution and perhaps impose some limitations on service workers registering each other.

[wanderview]

I agree it would be prudent to restrict register() to contexts rooted by an open window. So only permit it in worker contexts such that:

• a dedicated Worker created by a Window
• a dedicated Worker created by a parent Worker that is ultimately owned by a Window
• a SharedWorker with a Window attached

I think blocking register() in ServiceWorker would be reasonable for now. We can always open it later if necessary.

[alastaircoote]

Just to chime in with some thoughts here: I have some experience using project-specific service workers on a site that also has a site-wide worker (some details here) and it would be incredibly useful for the two to be able to communicate, particularly given that they share the same storage allowance - the site-wide worker could tell old project workers to clean up storage/unregister them, etc. etc.

So, agreeing that it makes sense to limit register() for security reasons (though I'd like that too!), it would be great if we could still get the rest of navigator.serviceWorker in worker contexts, so that we can use getRegistrations(), then postMessage(), etc. etc.

[jakearchibald]

I think we'd be able to allow registering a service worker from a service worker once we tighten up our story around service worker lifetime #980 (comment).

But rejecting until we have that properly implemented seems fine.