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.

[Hashbrown777]

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

Possibly better to multiplex the SW script into requests for the script containing the navigator.serviceWorker.register() call using HTTP2.0.

[jikkujose]

But isn't there a way other than Blob URL to inline the service worker in a single HTML page so a fully contained page can be a valid PWA?

[benkaiser]

@annevk could a potential mitigation against the "single attack compromising users for a long time" issue be to only persist the service worker for the current session?

The use case I have for this is quite odd. I'm trying to register a service worker from a chrome extension so that I can get a PWA install prompt to show up. Basically building a chrome extension that lets you convert any website into a PWA.

[alimertcakar]

@annevk could a potential mitigation against the "single attack compromising users for a long time" issue be to only persist the service worker for the current session?

The use case I have for this is quite odd. I'm trying to register a service worker from a chrome extension so that I can get a PWA install prompt to show up. Basically building a chrome extension that lets you convert any website into a PWA.

yeah we are trying to do the same thing. can't find a way around. only if chrome let us make any site into a pwa itself...

[nin-jin]

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.

But this is exactly what is needed to protect against server compromise. The current serviceworker downloads a new one, checks its digital signature and only then initiates an update.

[Sean4572435243]

The idea that potentially numerous nefarious browser extensions can and are allowed to rewrite entire DOMs, and yet developers are inhibited from compiling efficient single-file websites due to some edge case of a web server being compromised, seems a conflict in philosophy, and seems overtly oppressive given that other mechanisms can be employed to achieve the objective of code integrity.

[hazae41]

There is more probability in being infected by the server in the long run if things are mutable

An immutable service worker implies an immutable webapp if cached properly

This would annihilate any possibility of server-side attack once first downloaded

Also if your webapp is infected (via XSS or supply-chain), it's probably already game over

Just let the developer choose between mutable and immutable service workers

The developer is probably the best person to evaluate such risk-benefit