CSP3: Service Worker "kill switch"

[joelweinberger]

We should consider whether CSP is the right place to have a "kill switch" that specifies whether a Service Worker should be allowed on the page or not. In w3c/ServiceWorker#614, @annevk suggests that CSP would be a better place to have such control, rather than an explicit Service Worker header. cc @slightlyoff @KenjiBaheux

[devd]

I don't know ..seems weird. SW is origin (or,uggh, directory) grained while CSP is very much page granularity. And fundamentally, if a SW is already registered, then the SW will catch the load before it hits the server.

Do you mean "Use CSP to say --don't allow this page to ever register a SW"? Not sure this is good; it might lead people to a false sense of security. The security of SW registration really relies on the script file being same origin and in a particular location (and sending the service-worker header on the request for that script); not on "these are the pages allowed or disallowed to register a SW"

[KenjiBaheux]

And fundamentally, if a SW is already registered, then the SW will catch the load before it hits the server.

I think it's worth pointing that the user agent will automatically seek updates for a Service Worker script (respecting the max-age directive if it's less than 24 hours). These requests can not be intercepted by the Service Worker.

The spec also allows UA to do more frequent checks with soft update.

[joelweinberger]

I was imaging such a kill switch having two effects:

1. Killing all Service Workers currently running on the origin.
2. Not allowing a Service Worker to be installed in the current page context.

(1) is probably the less important point because a malicious SW that's already running could, of course, intercept this CSP and modify it to take away the kill switch. (2) seems more interesting to me as it's the usual use of CSP to whitelist allowed content and behavior in the page, in this case, registering SWs.