Re: CSP, Fetch, and Service Workers

I believe Dev's suggestion is that we tie service workers to something like
`child-src`, and only allow them to be created from a page if the page's
CSP allows it.

That is, a page served with `child-src 'none'` can't create service
workers. A page served with `child-src 'self'` can create service workers
from the same origin, etc.

Does that match your thinking, Dev?


Mike West <>
Google+:, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Mar 26, 2014 at 1:03 PM, Jake Archibald <>wrote:

> On Wed, Mar 26, 2014 at 11:16 AM, Devdatta Akhawe <>wrote:
>>  > Maybe we need a CSP rule for SW registrations. They're already limited
>> to
>> > the same origin, but maybe you'd want to limit that further or disable
>> it
>> Given the power of SWs, I would suggest a CSP rule to whitelist SW
>> registrations: so a page can only have an SW if it comes with a CSP
>> explicitly allowing such a SW.
> Requiring a specific content-type for appcache manifests was so much of a
> problem it was dropped from the spec. Static servers such as github & s3
> weren't ready in time, a lot of frontend developers don't know how to do it
> on their local dev servers. Requiring header modification for SW to work
> would hurt adoption badly. Those static servers are already isolated by
> origin, so you can only shoot yourself in the foot.
> In the "big-company-using-csp" case where developers can deploy sites but
> cannot modify headers of any url on the origin, is that common?

Received on Wednesday, 26 March 2014 12:09:12 UTC