- From: Mike West <mkwst@google.com>
- Date: Mon, 17 Sep 2012 11:03:50 +0200
- To: Fred Andrews <fredandw@live.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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