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.

[mfalken]

FYI I think the current APIs let you implement the equivalent of an unregister({immediate:true}) worker:

skipWaiting();
onactivate = function(e) {
  e.waitUntil(clients.claim()
    .then(function() { return self.registration.unregister(); }
    .then(function() { return Promise.reject(); })));
};

A more sugary syntax may still be good.

[mfalken]

Nevermind, as per issue #659 the spec will likely change so that waitUntil(reject) is equivalent to waitUntil(resolve) in onactivate. So I think current APIs don't yet support unregister({immediate:true}) or cllients.release().

[jakearchibald]

I'm a little confused by the 24hr thing. A SW is checked for updates on navigation, so:

1. User navigates to broken page
2. SW serves up "hello world"
3. SW checks for updates, finds update, skips waiting, and tells clients to reload (Navigating clients from the SW context? #681 (comment))

Step 2 would only be skipped if the ServiceWorker was served with a max-age and was still considered fresh.

For this use-case, I don't see a benefit to unregistering rather than fixing the SW. If an evil user has managed to install a SW on another site, the other site probably wants to unregister it pretty fast, but that's still just:

1. User navigates to hacked page
2. SW serves up "l33t hacked"
3. SW checks for updates, finds update, skips waiting, unregisters, and tells clients to reload (Navigating clients from the SW context? #681 (comment))

So the new SW would be:

self.oninstall = _ => self.skipWaiting();
self.onactivate = _ => {
  self.registration.unregister()
    .then(_ => client.getAll())
    .then(clients => clients.map(c => c.navigate()));
};

[jakearchibald]

Moving this to v2, as we have ways of doing this without a specific API.

In cases where the SW is totally broken, this could happen:

• User navigates to page
• SW is broken, so it serves a network error
• Browser may make a skip-service-worker request, if that works they can load the page uncontrolled

Continual failures may even result in the UA unregistering the SW.

[jakearchibald]

At the f2f we also had discussion about how developers could detect that their responses weren't valid. We had the idea that fetchEvent.respondWith() could return a promise that rejects if the promise passed to respondWith…

• resolves to a network error
• rejects
• is converted to a network error by fetch (eg due to opaqueness where opaque is inappropriate)

[mfalken]

Hi Jake can we track the respondWith() return promise as a different issue? The idea also came up in a codereview from @mikewest: https://codereview.chromium.org/1228233007/#msg9

[gauntface]

Just wanted to add an extra use case.

I've writing some unit tests for SW fetch events and hit a scenario where registering and unregistering SW's between tests and essentially there was no way to completely remove the currently controlling sw since the redundant SW is brought back to life if the same SW is used between tests.

[jakearchibald]

I think this makes WPTs awkward too.

[wanderview]

Would an API performing the Clear-Site-Data header operation serve this purpose?

[jakearchibald]

Yeah, that spec used to have an API defined, but it doesn't anymore. It'd also clear a whole lot more, but maybe that's ok.

[asakusuma]

@asutherland awesome, thank you for the clarification.

@mattto do you know what Chrome does with permissions when CSD is used? Will Chrome re-use existing permissions if subscribe() is called again after CSD?

[jakearchibald]

For TPAC:

• I took a lot at spec'ing this, and it was hard. I just need to do the work. It's necessary for clear-site-data.

[asakusuma]

I created an issue related to the logistics of applying Clear-Site-Data: #1471

[jakearchibald]

TPAC:

• This could take longer to spec than implement.
• Do tests first, so implementation can happen in parallel with spec.

[asakusuma]

@jakearchibald took a pass at a failing test for verifying that clients are uncontrolled after Clear-Site-Data web-platform-tests/wpt#19132