Implement service worker modules

[ghazale-hosseinabadi]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Allow workers to execute module scripts too.

• Proposed spec: https://w3c.github.io/ServiceWorker (see "type" in the section)

• Specification or proposal URL: https://docs.google.com/document/d/1SeQ085YdBTtW3D_ygSpO0Wz2DAe8QiS1gj37IG5lstg/edit#

[annevk]

This is worth prototyping. We'll probably not update the dashboard for this as it's somewhat minor and unless there are other comments I would expect to close this as such next week.

[ghost]

I think that before we should implement the ability for the service worker to run any number of arbitrary complex scripts, we should think about a security model protecting the users of the application.

Because, imagine that deep down within the dependencies of a service worker module, we have a hidden backdoor that is programmed to run after the service worker completed the installation of the application. The backdoor may be programmed to run one hour after the installation, or two days or even three weeks after the installation, silently waiting for the users to bring their own private documents in places that are now accessible to the application and thus to the spyware/malware that could be deployed from the backdoor.

We have to think on ways able to mitigate this scenario.

[annevk]

@abflow I don't see how that's related. Service worker modules don't change the security properties of service workers. I'm closing this as per earlier comment.

Thanks for asking @ghazale-hosseinabadi!

[ghost]

Service worker modules don't change the security properties of service workers.

What security properties ?

[asutherland]

What security properties ?

• https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
• https://w3c.github.io/ServiceWorker/#security-considerations

[ghost]

"Potentially Trustworthy" is not really what can be described as "secure"...

https://html.spec.whatwg.org/multipage/webappapis.html#secure-context

[ghost]

Here a related proposition: #509

[mangelozzi]

I think that before we should implement the ability for the service worker to run any number of arbitrary complex scripts, we should think about a security model protecting the users of the application.

Because, imagine that deep down within the dependencies of a service worker module, we have a hidden backdoor that is programmed to run after the service worker completed the installation of the application. The backdoor may be programmed to run one hour after the installation, or two days or even three weeks after the installation, silently waiting for the users to bring their own private documents in places that are now accessible to the application and thus to the spyware/malware that could be deployed from the backdoor.

We have to think on ways able to mitigate this scenario.

Could not the same argument be used against any module imports? The concept of libraries is fundamental to programming.

Many people require to use a library in their service worker to aid using IndexedDB. At the moment one must inline modules to use them, is that not any less secure? If you have a dependency, you are going to add it one way or another, its just about convience of having a proper module/library system, or hacking files together in bundles because of no module support.

[AlbertMarashi]

Bump... Need service workers to be able to support import statements - critical for service worker development using SvelteKit.

Currently chrome supports this, so it would be nice to see it in Firefox