W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC to publish FPWD of CSP Pinning; deadline Feb. 9th

From: Mike West <mkwst@google.com>
Date: Mon, 16 Feb 2015 19:58:47 +0100
Message-ID: <CAKXHy=cbp5eh6CyN0CTt328K-H_rEdMtqkEV_F9N_ibJLZxJGA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC