Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create service worker from Blob/String URL #578

Closed
h2non opened this issue Dec 7, 2014 · 18 comments
Closed

Create service worker from Blob/String URL #578

h2non opened this issue Dec 7, 2014 · 18 comments

Comments

@h2non
Copy link

h2non commented Dec 7, 2014

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
Copy link
Member

annevk commented Dec 8, 2014

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 annevk closed this as completed Dec 8, 2014
@jdalton
Copy link
Member

jdalton commented Aug 26, 2016

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
Copy link
Contributor

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
Copy link
Member

jdalton commented Aug 26, 2016

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
Copy link
Collaborator

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
Copy link

NekR commented Aug 26, 2016

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
Copy link

inian commented Aug 27, 2016

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
Copy link
Member

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
Copy link

Zibri commented Jul 6, 2018

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
Copy link

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
Copy link
Contributor

@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
Copy link

Hashbrown777 commented Sep 7, 2021

@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
Copy link

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
Copy link

@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
Copy link

@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
Copy link

nin-jin commented Sep 22, 2022

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
Copy link

Sean4572435243 commented Mar 26, 2023

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
Copy link

hazae41 commented Aug 19, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests