A way to immediately unregister a service worker

[KenjiBaheux]

Spin off from #468.
Alex:

I a conversation I had with @metromoxie makes me think we should also add a special none or blank
value to Service-Worker-Allowed to disable SWs entirely. Many users want a similar kill-switch.

I'd be happy with a different header to kill things, but something seems necessary.

Anne:

I had the impression unregister() was the way to remove a single service worker and there would be no protocol equivalent.

If we want a protocol solution to removing a service worker, using HTTP 410 seems much more applicable.

Using none as keyword to forbid service workers of any kind seems fine although it's a bit unclear to me how you disambiguate that from a relative URL. Would we require URLs in that header to start with a slash?

[KenjiBaheux]

cc/ @slightlyoff @annevk @jungkees

[joelweinberger]

@annevk I think unregister only allows the you to do so at your current scope, o it seems like a 'kill switch' in the header gives the added benefit of the server being able, for any URL, to specify "no service workers at all".

Requiring absolute paths in Service-Worker-Allowed seems reasonable to me since I believe in the spec 'scope' is already required to be absolute anyway (http://www.w3.org/TR/service-workers/#unregister-algorithm for example). On the other hand, @slightlyoff's suggestion of a blank value also seems reasonable to me.

[annevk]

What is quoted above is out of context as I was responding to a suggestion of using none to remove the current worker, which was a suggestion I disagreed with per that comment.

[jakearchibald]

I believe in the spec 'scope' is already required to be absolute anyway

Nah, they can be relative (to the page).

The kill switch idea came up before and #236 was created as a result. Would that work here? You could serve a SW that contained only:

self.registration.unregister({immediate: true})

…which would unregister but also un-claim all pages immediately. Alternatively, clients.release() as an explicit opposite to 'claim'.

[joelweinberger]

I don't think that's sufficient. I'd want to be able to just serve headers that tell the client that Service Workers are not allowed so that any content with HTTP headers, even if it's not going to run JavaScript, can specify that the origin should not have ServiceWorkers.

I'd also love to have it be a preventative measure as well, and prevent registration of ServiceWorkers, but that may be more ambitious/complicated than I think. For example, if Dropbox knows that it should never have a ServiceWorker, they should be able to effectively "turn Service Workers off" for their origin by always specifying said header with all requests.

[annevk]

Disabling SWs altogether and preventing installation seems like a CSP directive.

Disabling just one SW through HTTP should use HTTP status codes on its script URL.

[mfalken]

If the motivation of the kill-switch is a sure-fire way to immediately shutdown SW in an emergency (say you roll out a respondWith('hello world') SW), these don't seem sufficient yet:

• unregister({immediate: true}) won't be run (your page is just 'hello world')
• HTTP status 410 on the script URL could take 24 hours before it's fixed

But maybe 24 hours is the best guarantee the SW spec should provide? Sites that are worried can set no-cache or max-age.

[mfalken]

Ah, I see the SW would run self.registration.unregister({immediate: true}), so that also takes 24 hours.

I implementing both unregister({immediate: true}) and HTTP status 410 would be OK. The protocol solution is a bigger hammer in case the browser's having trouble even spinning up workers or its registration job queue is wedged.

[mfalken]

Could it make sense for the Update algorithm to do a HEAD request and more aggressively than the 24 hour cache check? For example every 1 hour or even every time? This would be a powerful kill-switch, no waiting for 24 hours.

[kinu]

@mattto Let me make sure... when you say 'every 1 hour' you mean 'when navigation happens after 1 hour+ since the last update check runs', right? I'd be worried about the battery consumption on mobile devices.

[mfalken]

Sorry that wasn't clear. My idea was in the Update algorithm, do a HEAD request before fetching the script. The HEAD request could be done every time, or else limited by something like once every hour (similar to how fetching the script bypasses the cache only once every 24 hours). Update can be invoked via by SoftUpdate, which the UA can run at anytime (Chrome schedules one to happen soon after every navigation to a page in scope).

In Chrome's case, I think it shouldn't be too battery/network costly since you're already hitting network by navigating to the site.