W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: [CSP] Directive to disallow a response from being used as a Service Worker

From: Mike West <mkwst@google.com>
Date: Thu, 24 Jul 2014 11:02:22 +0200
Message-ID: <CAKXHy=c534GLaTmrL2rgHs4Ag81wTTR5_HoiCVTWm2OAntOG1A@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>, Joshua Peek <josh@joshpeek.com>, Ilya Grigorik <igrigorik@google.com>
Cc: 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>
+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 09:03:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC