Re: Proposal: A pinning mechanism for CSP?

#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
> >>
>