- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Fri, 30 Jan 2015 10:26:46 -0800
- To: Brad Hill <hillbrad@gmail.com>, Mike West <mkwst@google.com>
- Cc: yan zhu <yan@mit.edu>, Dan Veditz <dveditz@mozilla.com>, Yan Zhu <yzhu@yahoo-inc.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>, Chris Palmer <palmer@google.com>, Ryan Sleevi <sleevi@google.com>, Frederik Braun <fbraun@mozilla.com>, Jim Manico <jim.manico@owasp.org>
+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:27:16 UTC