[whatwg] The choice of script global object to use when the script element is moved

[Henri Sivonen]

On Sep 9, 2010, at 00:47, Ian Hickson wrote:

> On Fri, 3 Sep 2010, Henri Sivonen wrote:
>> 
>> When evaluating a parser-inserted script, there are three potential script global objects to use:
>> 1) The script global object of the document whose active parser the parser that inserted the script is.
>> 2) The script global object of the document that owned the script element at the time of invoking the "run" algorithm.
>> 3) The script global object of the document that owns the script element at the time of script evaluation.
> 
> #1 and #2 are dodgy because the documents in question might have been 
> GC'ed by that point.

This problem doesn't arise in Gecko, because if a document gets GC'ed, the pending external script loads that have started while the script was in that document never get evaluated. That is, the document (via its script loader) owns the pending loads--not the script node.

I could see theoretical merit in an argument that this is itself dodgy for script-inserted external scripts. However, I think the parser or the document whose active parser the parser is should own the loads for parser-inserted external script, because things become weird if defer script handling doesn't stay with the inserter parser and things get weird if the parser-blocking script doesn't stay with the inserter parser.

While it would be *possible* to decouple various aspects of script loading from each other, I think it's not really worthwhile to go through that exercise just for an edge case that's currently broken in more severe ways in the current release versions every one of the top 4 engines.

That is, I'd really like to see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10540 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=10542 become FIXED rather than WONTFIX. Furthermore (to avoid major changes to Gecko's script loading), I'd like the pending load of script-inserted external scripts to be owned by the owner doc at the time of the "run" algorithm. 

>> The spec says the answer is #3. WebKit (with HTML5 parser or without) 
>> says the answer is #1. Firefox 3.6 says the answer is #2.
>> 
>> I doubt that there are Web compat considerations forcing this choice, 
>> because IE8 doesn't get as far as running the script in this case. IE9 
>> tries to do either #2 or #3 (not sure which) succeeding for inline 
>> scripts and failing for external ones. (IIRC, the text in the spec that 
>> explains the distinction between 1 and the other (without explaining the 
>> distinction between 2 and 3) was added specifically for the benefit of 
>> the IE team.)
> 
> I'm not sure exactly which sentence you mean here, but I'm happy to 
> clarify text if anything is ambiguous.

The example http://www.whatwg.org/specs/web-apps/current-work/#scripts-that-modify-the-page-as-it-is-being-parsed doesn't cover the script moving to a third document between the first parser-performed insertion and the external script finishing loading.

> So in conclusion, I really don't see a new attack vector regardless of 
> what we do here.

OK.

> One advantage of doing #3 is that, as Adam pointed out, the implementation 
> is required to get the security context at the last minute, where it's 
> most likely to be up to date (e.g. with document.domain changes, etc) even 
> in the case of the <script> element not being moved around.

For last-minute security context grabbing to have an extra benefit, wouldn't the security checks have to be re-performed at last-minute?

> #3 is simpler to understand, IMHO. However, #1 is not particularly hard to 
> spec, and I guess does decrease the odds of scripts being made to run 
> accidentally by a bug in a script using sandboxed or CSP context.
> 
> If everyone is ok with #1, I'm happy to change the spec accordingly.

In case we don't end up doing #1, I have a follow-up question:

Is there a good reason to perform the "run" algorithm against the then-current owner doc as opposed to the parser's doc for parser-inserted scripts? (Performing it against the parser's doc would require fewer changes to Gecko but implementing the checks against the owner doc would be doable.)

>> Suppose there are two docs from one Origin. The document that the parser 
>> is associated with doesn't have a CSP. A script in it moves a node in 
>> such a way that the parser ends up inserting subsequent scripts into 
>> another document. That document has a CSP that bans scripts. Would you 
>> consider it a bug if a script ran in the context of the script global 
>> object of the document whose CSP says no scripts?
> 
> If the CSP applied then the script would not run, if it didn't then it 
> would run in the context of the doc without the CSP. I'm sure we wouldn't 
> want to define the CSP as applying to nodes in a different way than the 
> global scope is picked.

Currently, CSP is evaluated at the "run" algorithm time. This seems a natural extension to the "scripting disabled" check that happens at "run" algorithm time.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/