Re: CSP 1.0: relaxing mandated enforcing and monitoring to avoid probing and to avoid content being written to depend on CSP.

On Sun, Sep 16, 2012 at 4:07 PM, Fred Andrews <fredandw@live.com> wrote:

> If someone can be tagged then they can be tracked and it is often easy to
> identify them by correlating their actions and by the timing of their actions.

This is a tautological argument. The question is whether CSP reporting
exposes identifiable information above and beyond what's available to
web authors in its absence.

You've raised the potential exposure of installed extensions/add-ons
as an issue (assuming those extensions embed content that would
violate a page's CSP). I agree with you that that's a concern, and so
does the spec: "Enforcing a CSP policy should not interfere with the
operation of user-supplied scripts such as third-party user-agent
add-ons and JavaScript bookmarklets." Resources included by an
extension shouldn't violate a page's CSP, hence no report should be
generated. We're working on ensuring that extensions bypass CSP in
Chrome, and I'm sure other user agents have similar goals.

That said, if an extension modifies the DOM, it's detectable (via
brute-force scanning, Mutation Observers, etc). Servers are perfectly
capable of sending themselves information about detected extensions
via XHR or other means, even without CSP reporting.

With that in mind, is there anything specific to the CSP violation
reporting mechanism that goes above and beyond what a website can
already gather on it's own?

> So let me get this straight.  You propose to expose the CSP policy to attacking
> injected scripts allowing then to search all policy for an attack approach without
> detection or to otherwise lay dormant without detection?

That's certainly one way to phrase it.

The primary use case I had in mind was the myriad of client-side
templating libraries that rely on `new Function()` to do their work.
Angular.js, for instance, toggles between implementations in exactly
the way I described[2].

[2]: https://github.com/vojtajina/angular.js/commit/1da4cccddb449705dbf99a8916980c7da5598dc3

> And all for the purpose of allowing 'frameworks' to conveniently inject Google
> Analytics tracking.

I don't understand the threat you're alluding to here. Surely if a
server wants to use some analytics package, they'll whitelist it in
the CSP they send.

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

Received on Monday, 17 September 2012 09:04:44 UTC