Re: WindowProxy objects violate ES5 invariants

Le 13/12/2012 19:37, Boris Zbarsky a écrit :
> On 12/13/12 12:24 PM, David Bruant wrote:
>> When a script in a page has access to its global object, this object is
>> a WindowProxy. In this case, under which conditions can the underlying
>> window object change? (and that change be observable by the same script,
>> of course)
>
> When the window is navigated or document.open() is called.
>
> Here's a simple testcase that shows the underlying window changing:
>
> test2.html:
>   <script>
>     var self = window;
>     var foo = 1;
>     var f = function() { alert(foo); alert(self.foo); }
>   </script>
>
> test.html:
>
>   <iframe src="test2.html"></iframe>
>   <script>
>     window.onload = function() {
>       window.f = frames[0].f;
>       f();
>       var i = document.querySelector("iframe");
>       i.setAttribute("onload", "f()");
>       frames[0].location = "about:blank";
>     }
>   </script>
>
> This alerts 1, 1, 1, undefined in at least Safari, Opera, Firefox.
Wow! Thank you very much for having shown this. I would have never 
thought of doing this.

>
>>> That's not ok, unfortunately, because for security reasons we must be
>>> able to define things that look like non-configurable properties on a
>>> window.
>> By "we", you mean "implementors" and that's fine. Only web authors won't
>> be able to define their own non-configurable properties.
>
> I don't see how that's OK.  "we" as in implementors are using the same 
> APIs to define our properties...
Specifically not. Implementors can define Window objects while authors 
can't for instance. It means that implementors have access to primitives 
that web authors don't. That's just one example of how "implementor 
APIs" are different than authors APIs.

In our case, implementors can instantiate the objects in ways that 
authors can't.

David

Received on Saturday, 15 December 2012 00:14:59 UTC