- From: Alex Russell <slightlyoff@google.com>
- Date: Tue, 28 May 2013 14:52:41 +0100
- To: Adam Barth <w3c@adambarth.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "www-tag@w3.org List" <www-tag@w3.org>, Marcos Caceres <w3c@marcosc.com>, Mike West <mkwst@google.com>, Yehuda Katz <wycats@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CANr5HFUhYg7O7WSOVozufntfhZhdsTgRo40P7QJtxDd4R3i5Kw@mail.gmail.com>
Hey Adam, Thanks for taking the time to read the post. I re-implemented CSP in JS not that long ago, based in part on the earlier 1.1 proposed API. Here's the jumping-off point for the API: https://github.com/slightlyoff/CriSP/blob/master/csp.js#L488 The big things I changed were that I added constructors and that the aggregate policy isn't a single item. SecurityPolicy grew a couple of methods: a getter/setter pair for "policy" which acts as an API to the parser and serializer. Related, there's a toString serializer. It also makes some previous methods getters. There are also some new statics, e.g.: SecurityPolicy.directiveReservedValues[], SecurityPolicy.directives[], but they're not essential. The overall that's exposed at document.securityPolicy would need to be re-built, and I think that's an open issue. Regards On Sat, May 25, 2013 at 10:27 PM, Adam Barth <w3c@adambarth.com> wrote: > Thanks for taking the time to write up your thoughts in long form. I > think the problem is (as you point out) that the previous API was somewhere > in between scenario-solving and showing-our-work. We went towards the > scenario-solving side. I'll try working up a counter proposal that's more > in the vein of showing our work. > > Adam > On May 24, 2013 10:02 AM, "Alex Russell" <slightlyoff@google.com> wrote: > >> Apologies for not replying more fully before. >> >> I've spent some time putting my thinking on this in blog-post form: >> >> http://infrequently.org/2013/05/use-case-zero/ >> >> On Saturday, April 27, 2013, Adam Barth wrote: >> >>> Alex, would you be willing to share the specific use cases you have in >>> mind? We just want to make sure there are solid use cases for the >>> features in the spec. >>> >>> Adam >>> >>> >>> On Sat, Apr 27, 2013 at 11:31 AM, Alex Russell <slightlyoff@google.com> >>> wrote: >>> > I object to these changes in the strongest possible terms. If it is not >>> > possible to implement CSP policy enforcement on top of your API, it is >>> not >>> > sufficient. >>> > >>> > On Apr 27, 2013 5:46 PM, "Adam Barth" <w3c@adambarth.com> wrote: >>> >> >>> >> As discussed at the face-to-face meeting, I've trimmed the >>> >> SecurityPolicy DOM interface to just the first four attributes: >>> >> >>> >> https://dvcs.w3.org/hg/content-security-policy/rev/f338192860c5 >>> >> >>> >> At the meeting, we discussed that these attribute have strong use >>> >> cases, but we couldn't think of any strong use cases for the remaining >>> >> DOM interfaces. >>> >> >>> >> If folks come up with strong use cases, we should consider adding back >>> >> the removed interfaces (or adding new interfaces that better address >>> >> those use cases). >>> >> >>> >> Note: At the face-to-face, we discussed making some of these attribute >>> >> writable in some circumstances, but I haven't made that change yet >>> >> because it probably deserves more discussion. >>> >> >>> >> Adam >>> >> >>> > >>> >>
Received on Tuesday, 28 May 2013 13:53:44 UTC