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.

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.)

The spec asserts that these options are equally safe, because if something is 
able to move the scripts so that 1, 2 and 3 would result in different script 
global objects, the script gets moved within one Origin.

However, if there's something other than Same Origin restricting what scripts 
are eligible for evaluation (e.g. Content Security Policies that I don't know 
well enough to reason about), 1, 2 and 3 might not be equally safe.

Questions:
 * Is anyone aware of an existing or upcoming security mechanism that would not 
make the three above cases equally safe--especially if e.g. the security check 
was made according to #1 but the effective script global object were chosen 
accoding to #3?
 * Why does the spec say #3 when none of the browsers did #3 at the time of 
spec writing?
 * Are there use cases that favor any one of these in particular? (I doubt it.)

FWIW, my gut says we should do #1, since it is obviously secure, except it 
would be unfortunate if the spec changed to #1 but too late for IE9 to match.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Reply via email to