Re: Including the Javascript stack trace in the ContentSecurityPolicy report

Hi,

I'd like to distinguish 2 cases: production and development.
In development, I believe that changing the platform would be a mistake and
that external tools like Casper.js [1] should be preferred (assuming they
report CSP violations [2])
Production is a different story as you can't embed tooling in your users
browsers. Since I consider developmeent dealt with with tooling, let's only
talk about production.

2013/8/2 Henry Wong <henrywong@google.com>

> I'd like to propose that CSP reports include the Javascript stack trace
> that resulted in loading the forbidden resource (similar to window.onerror).
>
> In many large web applications (eg: Google+) it's almost impossible to
> figure out why a report was sent.
>
I imagine that in many large web applications, the JS is minified or even
optimized with things like inlining (through e.g. the Google Closure
Compiler) so I wonder how accurate and relevant the stack trace can be.
Also, with promises [3] and async programming rising up, I wonder how
relevant a stack trace can be. I know that in Node.js, a stack trace is
rarely a relevant piece of information to debug (we joke on a regular basis
with a friend on that topic).

The document uri is typically just "http://plus.google.com" which doesn't
> really give us enough context to know what the user was doing. For example,
> if an XSS spreads via users' chat status then a stack trace that pointed to
> the status message code would be much more useful than something that just
> said there was a report sent from somewhere on the page.
>
But I understand that you need some context for the violation. An
alternative idea to sending the stack trace could be adding a method like
"navigator.setCSPViolationContext(context)" (I don't know where CSP-related
methods are, but you get the idea).
If a violation is detected, the latest context value is sent along the
report (you can test that the right context is passed in developement mode
with [1][2] ;-) ).

For the use case you described, you can set the context "chat" when dealing
with the chat-related code and that comes along with your report. I feel
that this form of user-created context will yield much better results than
a stack trace, because it is at a higher-level of abstraction and doesn't
care about the subtleties of a native definition of "resultded in" Boris
mentioned.

David

[1] http://casperjs.org/
[2] https://github.com/n1k0/casperjs/issues/494
[3] http://dom.spec.whatwg.org/#promises