- From: Mike West <mkwst@google.com>
- Date: Mon, 16 Feb 2015 19:58:47 +0100
- To: Deian Stefan <deian@cs.stanford.edu>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Brian Smith <brian@briansmith.org>
Hi, Deian! On Mon, Feb 16, 2015 at 7:38 PM, Deian Stefan <deian@cs.stanford.edu> wrote: > - Pinning directives that are not purely restrictive. Are you open to excluding them for now? Since we've dropped `referrer` and `reflected-xss` from CSP2, yes. I would like to get both back in when CSP3 comes around, and I'm confident that we can find ways to do so (limiting them both to `no-referrer` and `block`, for instance). I've also added an issue to the spec about dropping reporting: https://w3c.github.io/webappsec/specs/csp-pinning/#issue-d8134519. I hope we can figure out a way to serve the central use case (which I would suggest is reporting pages on which you should have served a policy), but if we can't, we can't. > - Is there a reason to not limiting pinning to ServiceWork path? Because I don't understand why ServiceWorkers have introduced path-based granularity. As I noted in that thread (and as Brian agreed), the origin makes sense as a security boundary. Pretending that such a boundary exists for paths seems problematic. -- Mike West <mkwst@google.com>, @mikewest 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.)
Received on Monday, 16 February 2015 18:59:36 UTC