Not to bikeshed too much, but everywhere else we have a subtractive combination logic for policy. We're proposing (with good reason) a replacement model here. I only wonder how to make that as clear as possible. Perhaps instead of "Content-Security-Policy-Pin", "Content-Security-Policy-Origin-Default" ? On Fri Jan 30 2015 at 10:48:46 AM Mike West <mkwst@google.com> wrote: > #2 also happens to be what's in the draft, and #2a is trivial to add if we > decide we want it in the future. > > If you don't mind, skim https://w3c.github.io/webappsec/specs/csp-pinning/ > again over the weekend. I'll rebrand it on Monday, and kick off a CfC to > get a FPWD published. I believe it should fit pretty cleanly into our > charter, old or new. > > Thanks! > > -- > 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.) > > On Fri, Jan 30, 2015 at 7:26 PM, Deian Stefan <deian@cs.stanford.edu> > wrote: > >> >> +1 >> >> I don't have a strong opinion here and #2 is a simple, clean way to move >> forward. >> >> Brad Hill <hillbrad@gmail.com> writes: >> >> > We didn't discuss it at AppSec, so you're not missing any notes. >> > >> > Hat=individual >> > >> > I like option #2, and Facebook would have real use for such a feature. >> > >> > I think Yan's use case is valid and interesting, but I don't think it's >> a >> > CSP pinning feature, it's a something-else meta-stable-crypto-key >> > confinement something feature, and I think both it and CSP would be >> harmed >> > by trying to shoehorn it in as CSP pinning. >> > >> > -Brad >> > >> > On Fri Jan 30 2015 at 6:06:06 AM Mike West <mkwst@google.com> wrote: >> > >> >> >> >> On Jan 30, 2015 12:56 PM, "Mike West" <mkwst@google.com> wrote: >> >> > For simplicity's sake, I'd vote for #2, with the option of moving to >> #3 >> >> in the future. That 'no-override' model leaves the majority of the >> power >> >> with the _pin_ and not the _page_, which seems like the right tradeoff. >> >> >> >> I confused myself, apologies. I vote for #2 with the option of moving >> to >> >> #2a in the future. Not #3. >> >> >> >> -mike >> >> >> > >
Received on Friday, 30 January 2015 18:55:44 UTC