Re: Including the Javascript stack trace in the ContentSecurityPolicy report

Le 02/08/2013 18:40, Boris Zbarsky a écrit :
> then, asynchronously, things like security checks and CSP checks 
> happen, I/O happens, etc.  For img.src things are actually a bit more 
> complicated for compat reasons, but fundamentally implementations want 
> to do as little work as possible on the main JS execution thread 
> before returning from that src setter.
I hadn't thought of that. Even if the CSP checks are/were cheap, doing 
as little as possible in setters sounds crucial.

> Oh, and I guess only in the case when there is a CSP.  So one obvious 
> optimization for UAs is to continue doing load processing async but 
> deoptimize the "has CSP" case by only snapshotting stacks on DOM 
> mutations if there is a policy. Which also seems suboptimal. 
That'd be a pure mistake indeed. If CSP-enabled website are slower, 
people will stop using it which would defeat the purpose.

I like the idea of "SecurityPolicyViolationEvent". I feel it solves the 
problem of having more runtime context when a violation occurs. As I 
said and as agreed by Henry, the stacktrace is often useless. The 
ability to add arbitrarily accurate info about the context when inside 
the event sounds priceless.

By the way, for spec editors, it could be nice if, for instance, the 
return value of the event handler was used to enhance the violation 
report (maybe in a "custom" or "user-added" field). It makes the report 
being actually reported a bit later, but I don't think that's a big deal.

David

Received on Friday, 2 August 2013 19:45:20 UTC