[whatwg] Location object identity and navigation behavior
bzbarsky at MIT.EDU
Mon Nov 19 23:20:11 PST 2012
On 11/20/12 1:23 AM, Ian Hickson wrote:
> Could you elaborate in the bug? I've no idea what you think is wrong.
Done, but what's wrong is that the security checks described in the spec
check the origin of the wrong document.
>> You can maintain a stack of entry scripts. You can't use a global,
>> because you need to push and pop entry scripts as various things happen
>> (e.g. invoking event listeners sets the entry script to the event
>> listener function's script for the duration of the event listener
> The way the spec does it, the stack is implemented as the actual call
> stack, with nested calls to "jump to a code entry-point" storing the old
> value, updating the global, running the script, then restoring the global
> to the stored old value.
Sure, that works. One way or another, you need to have a stack. ;)
And if part of your WebAPI/DOM/etc implementation itself is done in JS
you have to be careful to not update the entry-point stuff when calling
into that JS, of course.
>> The thing that _really_ requires stack introspection is when you need to
>> look at the caller script instead of the entry script. Which is what
>> you need to do when performing Location security checks (or indeed, any
>> security checks).
> Can you show an example of when that is needed?
Uh... any time you do a security check, in general.
> As far as I can tell, the entry script always has the same origin as the
> running script.
All you need for script A to be able to call script B as the spec us
currently written is that sometime in the past the effective script
origin of A matched the effective script origin of some script C and
that at some point in the past (possibly a completely different point)
the effective script origin of B matched the effective script origin of
C (which may not have been the same at that point as when C matched A!).
There is no requirement that A ever matched B, or even that the sets
of effective script origins A and B have had in the past have nonempty
And even that may not be true depending on whether UAs allow
"privileged" JS in various settings. If they do, then the entry script
becomes very useless for origin determination unless crossing origin
barriers resets the entry script. Which, again, is not the case in
Gecko right now. But that's obviously Gecko's problem, for the moment.
> I guess this isn't necessarily true of the effective
> origin, which is what we're using for the Location object security? Is
> that the problem here?
I think the problem is that you're assuming invariants that just don't
hold. There is no current requirement in the spec that there be any
relationship between either the origin or effective script origin of the
entry script and the origins of the currently running script.
> If so, why don't we just make it be an origin check of the entry script
> instead of an effective origin check?
Because that would be totally wrong; see above.
> If that would make it simpler for Gecko
As things stand, it wouldn't, particularly. It would actually introduce
> if you have both calling each other then you can almost
> certainly trick the script into doing what you want either way.
Who said anything about both calling each other? Gecko's security model
is asymmetric in practice.
More information about the whatwg