- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 02 Aug 2013 12:40:19 -0400
- To: David Bruant <bruant.d@gmail.com>
- CC: public-webappsec@w3.org
On 8/2/13 11:50 AM, David Bruant wrote:
> All the CSP rules have to be known by the runtime *before* any load
Yes....
> So I don't understand why asynchrony would be an issue.
Because implementations want to do the check of CSP rules asynchronously.
> 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.
Sync with what? Consider this script:
var img = new Image();
img.src = "http://whatever";
And implementation typically wants to do something like this in the
setter for "src":
postEventToImageLoaderThread(newURI);
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.
> The extra cost only occurs if a violation is detected which is expected
> to be a rare event.
The extra cost is that of either forcing CSP checks to be sync under DOM
mutations or forcing DOM mutations to snapshot JS callstacks.
-Boris
Received on Friday, 2 August 2013 16:40:49 UTC