Serviceworker: Create service worker from Blob/String URL

[h2non]

I guess it's a security decision, however it could be really useful for better and easier approach when developing generic libraries which needs to abstract implementation details to end developers which uses the ServiceWorker to provide functionalities such as transpartent assets caching or HTTP traffic interceptor/modification on the flight

Taking a look to its parent implementations (Workers and SharedWorkers), any developer can create them using different ways to dynamically serialize code and transforming it as a binary. I think that the same feature for service workers will be great match. The scope limitation has no sense in this cases

A basic example:

var workerBlob = new Blob([ serviceWorkerFn.toString() ], { type: 'text/javascript' })
navigator.serviceWorker.register(URL.createObjectURL(workerBlob))
  .then(function () { ... })
  .catch(function () { ... })

[annevk]

We don't want to support this because it would mean a single successful attack on a server could compromise users for a long time.

[jdalton]

We don't want to support this because it would mean a single successful attack on a server could compromise users for a long time.

Is there something about Blob that makes it worse than other options?
If there's a successful attack on a server and files are compromised wouldn't that trump this guard?

[jakearchibald]

If it allows a SW to be registered in a way that prevents the owner of the controlled origin from unregistering it, we don't want it 😀

[jdalton]

If a server is compromised they could register the traditional way since they have file access.
Ah, I guess this is more about XSS guards, right?

[mkruisselbrink]

The problem is that to unregister you need to first actually get to get code to run on that origin. If the service worker doesn't have an actual network url to check for updates, the service worker can just intercept all navigation, and never let any new request to the server actually reach the server, so even fixing the server won't enable fixing the clients. Basically the entire 24 hour update check wouldn't be possible anymore with blob urls.

[NekR]

It probably could be this though:

navigator.serviceWorker.register('blob:...', {
  updateUrl: '/sw.js'
})

I just don't know what are the use cases here?

[inian]

It could lead to faster SW startup times since there is not RTT involved in fetching the scripts..Might make sense for SW scripts that are small enough to be inlined..

[wanderview]

What @mkruisselbrink said.

It could lead to faster SW startup times since there is not RTT involved in fetching the scripts..Might make sense for SW scripts that are small enough to be inlined..

We've tried to design things so the install of a service worker does not block page load or interactivity. So optimizing install and update times will not have much visible effect for the user. I think we should err towards correctness and safety for these cases.

[Zibri]

It would be way better for web-apps and single file contained local apps.
Also since serviceworkers are used in push notifications this will allow to receive push notifications from a local hosted app.

[goofballLogic]

We don't want to support this because it would mean a single successful attack on a server could compromise users for a long time.

@annevk is there anywhere there is more reading on this topic? I'm eager to learn more

[jakearchibald]

@goofballLogic https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle

The browser needs to know where it should look to discover service worker updates.