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 _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
