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?

[asakusuma]

I think there should be a distinction between "I don't want a service worker anymore" and "this specific service worker isn't working but I still want one when there's a working one available". "Unregister" appears to address the former, but we don't seem to have a 1st class construct for the later.

[asutherland]

At least in Firefox, the user permission for an origin to send push notifications is decoupled from any specific registration. (Similarly, if a user expresses a desire to never allow push notifications for an origin, that is persisted. That way a site can't just try and unregister and register to get more tries to prompt the user.)

[asakusuma]

@asutherland I like that approach. So for Firefox are subscriptions still associated with a registration? Given an origin that has already received permission for push notifications, after CSD: storage is applied, if the application wants to resume notifications, does the application simply call subscribe() again, and permission is assumed, without having to ask the user again?

Another relevant section of the spec:

User agents MUST acquire consent for permission through a user interface for each call to the subscribe() method, unless a previous permission grant has been persisted, or a prearranged trust relationship applies. Permissions that are preserved beyond the current browsing session MUST be revocable.

[asutherland]

The subscriptions are associated with specific registrations yes. (Technically, they're indirectly keyed by the registration scope, but that will likely change.)

The origin-scoped permission is not cleared by Clear-Site-Data, and so when subscribe() is called, if the permission was previously granted (and not subsequently revoked by the user), subscribe will succeed without prompting.

[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: https://github.com/w3c/ServiceWorker/issues/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 https://github.com/web-platform-tests/wpt/pull/19132