Re: CSP 1.1 DOM design

On Sun, Nov 4, 2012 at 9:58 PM, Alex Russell <slightlyoff@google.com> wrote:

> Looking at Section 3.4 of the CSP 1.1 draft [1], I'm noticing that the IDL
> specified feels very, very strange to use from the JS perspective.
>

Thanks for taking a look! This is great feedback.


> For instance, the name "document.SecurityPolicy" would indicate to a mere
> JS hacker like me that the SecurityPolicy is a class from which instances
> will be created. Instead, it's an instance of the SecurityPolicy interface.
> A more idiomatic name might be "document.policy", "document.csp", or
> "document.securityPolicy" as leading-caps tend to be reserved for classes,
> not instances.
>

Adam, do you remember why we ran with 'SecurityPolicy' rather than
'securityPolicy'? I know we discussed it, but I can only find the comment
resulting from that discussion (
https://bugs.webkit.org/show_bug.cgi?id=91707#c5).


> Similarly, it's not possible (AFAICT) to new-up an instance of
> SecurityPolicy and no API provided for parsing a policy to understand how
> it would react.
>

That's an interesting suggestion. What's the use-case you see for providing
a mechanism for parsing/examining a policy?

The only thing I can come up with off the top of my head is the tool we
briefly chatted about that would help developers understand the impact of a
policy. :)


> Lastly, there's no serialization method provided. A toString()
> implementation might work well.
>

What would the string representation of the object look like? Just the
original policy?

One complication is that the page's active policy might be created by the
union of several policies (one sent per HTTP, one in a meta tag, etc).
Would we want to retain that representation in a string version?


>     readonly attribute DOMString[] reportURIs;
>

We decided at TPAC to remove the reportURIs getter unless someone has a
really good use-case for it.


> One open issue: I'm not sure If allowsEval, allowsInlineScript, and
> allowsInlineStyle should just be boolean getters or if they should stay
> methods.
>

I like the idea of converting these `allowEval()`-style calls to read-only
booleans. Perhaps 'isActive' as well.


> Also, it's unclear if the current document's policy should simply be a
> locked-down instance of a SecurityPolicy class that has accessors for each
> of the policy items (script-src, object-src, style-src, img-src,
> media-src, frame-src, font-src, connect-src).
>

I think that's more or less what the current interface does. (e.g.
`document.SecurityPolicy.allowsFontFrom('xxx')` is an accessor for the
effective permissions granted via the 'font-src' directive). Would you
prefer more direct access to the policy? We'd shied away from that on the
assumption that this interface required less knowledge of CSP in order to
usefully include on a page. Should we revisit that question?

Thanks again!

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91