Re: [CSP] Directive to disallow a response from being used as a Service Worker from Joshua Peek on 2014-07-24 (public-webappsec@w3.org from July 2014)

From: Joshua Peek <josh@joshpeek.com>
Date: Thu, 24 Jul 2014 15:05:42 -0700
To: Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Ilya Grigorik <igrigorik@google.com>, Jeffrey Yasskin <jyasskin@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevankesteren@gmail.com>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>
Message-ID: <CA+RmjJJp0z2jYvpMVOQH2G_TKzhQx4jyf4O9u6qv4Y5z5gW9CA@mail.gmail.com>

Couldn't CSP sandbox apply to service workers?

  GET https://raw.githubusercontent.com/worker.html
  navigator.serviceWorker.register('worker.js').

  GET https://raw.githubusercontent.com/worker.js
  Content-Security-Policy: sandbox

I'd expect the registration to fail since `worker.js` should be
considered a separate origin.

For raw.githubusercontent.com, we're planning to set
`Content-Security-Policy: default-src 'none' sandbox;` on all
responses. This would allow us to potentially start serving the
correct Content-Type.

Regarding a custom Content-Type for service workers, if we established
some sort of file extension convention like "foo.serviceworker.js", we
could configured our /etc/mime.types for GitHub Pages static serving.

The idea of script contexts is kinda interesting if you could set
'none' to prevent it from used as any type of script.

On Thu, Jul 24, 2014 at 2:02 AM, Mike West <mkwst@google.com> wrote:
> +Ilya for the client hint.
> +Josh Peek from GitHub for the question WAY down at the bottom.
>
>
> On Thu, Jul 24, 2014 at 4:04 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>> For request headers, how about a "CH-Context: ServiceWorker"? That makes
>> more sense to me than "Service-Worker: script" and it also follows the
>> client hint format.
>
> This seems like a reasonable way of pushing the data up to the server, and
> it's probably useful for server-side response prioritization regardless:
> Ilya? WDYT?
>
>
>> For response, since SW shouldn't wait on CSP2.1, how about a simple header
>> that someone can send to disable all SWs registered on the domain?
>> "ServiceWorker: None" or something like that?
>
> There's no reason this would need to block on CSP v.Next if we think it's
> the right thing to do. The Service Worker spec can define a new directive,
> and we can merge it into CSP whenever we get around to it. That's what
> Manifest is doing right now, in fact:
> http://w3c.github.io/manifest/#content-security-policy
>
>
>> Although, I do wonder: is it really that hard to ask github to let devs
>> set
>> content type sometimes?
>
> Maybe. Josh? :)
>
> -mike

Received on Thursday, 24 July 2014 22:06:09 UTC