Re: Including the Javascript stack trace in the ContentSecurityPolicy report

2013/8/2 Boris Zbarsky <bzbarsky@mit.edu>

> On 8/2/13 9:29 AM, Henry Wong wrote:
>
>> Is there a particular
>> reason not to include the stack trace other than that it might not
>> always be relevant?
>>
>
> It's a significant burden on implementations to do it, especially without
> killing performance.  Because loads are async, any operation that might
> start a load has to eagerly save the stack trace just in case the load will
> later fail a CSP check...
>
All the CSP rules have to be known by the runtime *before* any load, aren't
they? So I don't understand why asynchrony would be an issue. In essence,
an implementation can do (pseudo-JS code, lots of details omitted):

function load(url){
  if(url.violatesCurrentCSPRules()){ // sync because all rules are
available. Has to be done anyway by a CSP conforming impl.
    var stack = getStackTrace();
    // emit the event with the stack as one of its data
    // send the violation report
  }
  else{
    // sendHTTP request
  }
}

The extra cost only occurs if a violation is detected which is expected to
be a rare event.

David