search

w3c / ServiceWorker

Service Workers
https://w3c.github.io/ServiceWorker/
Other
3.63k stars 313 forks source link

Create Service Worker from Blob/String that does not persist and auto claims for testing #1642

Open frank-dspeed opened 2 years ago

frank-dspeed commented 2 years ago

I want to pick up https://github.com/w3c/ServiceWorker/issues/578 again with some addition i would like for cases like codepens and gists that i can register a service worker via blob/url that auto claims https://developer.mozilla.org/en-US/docs/Web/API/Clients/claim

and does not persist a page refresh. so it gets only used on run time once like any normal script but it can use the service Worker Apis

Does any one see any security blockers for that?

my Conclusion

The only bad thing is the long time effect as in my design decision is no long time effect while it allow to run one off tests should be fine

asutherland commented 2 years ago

I understand the intent of this request to be similar to https://github.com/w3c/ServiceWorker/issues/1437 but also requesting a relaxation of the fundamental security path constraint. Specifically, the goal is to have the special powers of a ServiceWorker in terms of fetch interception and being marked as the controller, and there's no expressed desire to have a real scope, but rather to control the current page or an iframe. That issue, however, is not requesting relaxation of the path constraint, but instead powers over a non-same-origin iframe.

This proposal doesn't address the fundamental security problem of step 8 of the update algorithm which enforces path constraints. Given the rest of the existing spec text, any ServiceWorker registered even ephemerally would still be able to intercept any page on the origin, which would still make this a potential means of XSS, just ephemeral to a browser session. If the registration were to somehow not have a scope so it only matches the current page, that would conceptually side-step the interception concern, but it's also an entirely new thing that would increase implementation complexity in a way that would have security concerns.

For the use-case of ServiceWorker testing on code editor sites, are the sites preventing use of ServiceWorkers (in which case perhaps an alternate site like glitch.com should be used), or is this a desire to clean up? For clean-up, a ServiceWorker registration can be unregistered while still controlling a page, and so once the page is claimed, unregister could be called. Additionally, as a meta thing, I believe that for Firefox our tracking protection logic may already, and potentially our QuotaManager logic will soon, more aggressively clear data for origins that were visited once and then never again so a unique origin leaving behind a ServiceWorker isn't a major concern.

frank-dspeed commented 2 years ago

@asutherland nope the intent is really to register a worker just acts as worker for the whole origin the only diffrent thing is that it does only get registered temporary. I see no problem in controlling the whole site when i can inject code already.

the code will get executed in a single client that then is effected for as long as he is on that page without a referesh or url change so as long as the current DOM is valid without recreation of the current document that did register the service worker.

my expected lifecycle is

  1. current page parsing picks up script that registers service worker and waits for activation
  2. after install it claims to activate it for the whole origin everything is 1:1 and it works only if not a other service worker for the same scope is already registered so everything like the specs.
  3. but as soon as he makes a new request via the browser bar or the tab closes that did run the registering code it gets unregistered

my final goal is to be able to give demos and snippets that work while they do not harm the eco system

and my guess is there is no hurt as long as the service worker is able to register temporarly with autoclaim for as long as the session takes.

georgir commented 2 years ago

Besides for testing, I want to point out another use-case that I've wanted this for: an easier and more complete way for TamperMonkey user scripts to intercept and change page content (scripts, ajax requests/responses, etc.; ideally even the main page content request itself if user scripts could run and register the service worker before it, but that's a whole other topic) right when it's loaded instead of using hacks and monkeypatches. The same limitations apply for that use-case: the service worker should only apply to the current tab/document (and maybe child same-origin iframes?) and not be persisted through reloads or navigation as the user-script can re-register it every time.