W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

Re: Trimming the SecurityPolicy DOM interface

From: Alex Russell <slightlyoff@google.com>
Date: Tue, 28 May 2013 14:52:41 +0100
Message-ID: <CANr5HFUhYg7O7WSOVozufntfhZhdsTgRo40P7QJtxDd4R3i5Kw@mail.gmail.com>
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>
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:


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.


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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC