The global object in browsers

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Fri Feb 20 16:13:35 PST 2009


Maciej Stachowiak wrote:
> On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote:
>> Ian Hickson wrote:
>>> On Tue, 17 Feb 2009, Mark S. Miller wrote:
>>>> I don't understand. If the object you're calling Window is inaccessible
>>>> from ES code, and if the object you're calling WindowProxy forwards
>>>> everything to your Window, why not just relabel Window ->
>>>> InternalWindow, WindowProxy -> Window?
>>>
>>> I don't really mind what the objects are called, the point is just that
>>> the object at the top of the scope chain is not the same as the object
>>> returned by "this" (or "window" on the global object).
>>
>> MarkM's point is that *given that the object called Window is inaccessible*,
>> there's no way to observe that the object called Window is at the top of
>> the scope chain. An implementation could reflect all property changes
>> in that object to the object called WindowProxy, by some unspecified
>> mechanism (which is allowed since they are both host objects).
> 
> It is possible to observe that the object at the top of the scope chain
> behaves differently than the global "this" value (it may have an
> entirely different set of properties), so this arguably violates the
> ECMAScript requirement that these be the same object, even though object
> identity cannot be observed directly.

Ian Hickson's description of the two objects was:

# The global object is a Window object. This object is per-Document.
# The object returned by the "window" attribute on that global object
# is actually a WindowProxy object, which forwards everything to the
# "current" Window object.

I don't understand how the WindowProxy "forwarding everything" to
the Window object is is consistent with the two objects having
"entirely different set[s] of properties".

In any case, note that host objects can have arbitrary [[Put]] and
[[Get]] internal methods, so it is possible for them to implement
almost any conceivable behaviour that HTML5 could specify (given
that ES code cannot obtain a reference to the object at the top of
the scope chain, and so === cannot be used on it). That was my point
above. In other words, ES3 has such a weak specification for host
objects that literally any behaviour for property accesses on them is
conformant.

[...]
>> I'm confused by the motivation of the change in HTML5. It seems like
>> it is imposing most of the complexity that would be needed to fix
>> some of the security problems associated with the global object,
>> *without* actually fixing those problems.
> 
> The HTML5 spec behavior does fix important security problems, relative
> to what older browsers used to do. Older behavior was to reuse the same
> global object across navigations, but simply clear the variables. This
> creates easily exploitable XSS vulnerabilities.

That's obviously broken, yes. When you say "older behaviour", what versions
of the main browsers are you talking about, approximately?

> Note though that HTML5 is following the implementations here rather
> than leading.
> 
>> Also, it is a breach of standards development etiquette for the HTML
>> WG to make a a change (even in a draft) that it believes to be
>> incompatible with the ECMAScript spec, without consulting TC39. It
>> should not have been left to you in the role of an implementor to
>> point out the incompatibility.
> 
> I think Ian discharged his obligation by notifying TC39 of the issue and
> starting this discussion. At this point, the important thing is to come
> up with a solution we can agree on.

I was confused partly by the fact that Ian said:

# For HTML5, this behaviour has been defined in more detail. [...]
# The HTML5 spec says: [...]

as opposed to something like: "It has been proposed for the next draft
of HTML5 to define this in more detail. [...] The proposal is: [...]"

-- 
David-Sarah Hopwood



More information about the Es-discuss mailing list