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 -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, 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 <jakearchibald@google.com>wrote: > On Wed, Mar 26, 2014 at 11:16 AM, Devdatta Akhawe <dev.akhawe@gmail.com>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