W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Jan 2015 00:40:16 +0000 (UTC)
To: Boris Zbarsky <bzbarsky@mit.edu>, "Mark S. Miller" <erights@google.com>
cc: Travis Leithead <travis.leithead@microsoft.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <alpine.DEB.2.00.1501142338270.6653@ps20323.dreamhostps.com>
On Wed, 14 Jan 2015, Boris Zbarsky wrote:
> On 1/14/15 3:17 PM, Ian Hickson wrote:
> > It's more than that. It's how the HTML spec defines WindowProxy.
> 
> The point is, the HTML spec's definition is not expressible in ES terms.  
> So how do go about bridging this gap?

I don't understand what you mean by "expressible in ES terms".

It's expressed in English.


> > According to the HTML spec, all operations that would be performed on 
> > the WindowProxy object must be performed on the Window object of the 
> > browsing context's active document instead. So the above would set a 
> > property on the underlying Window object, not the WindowProxy.
> 
> It would call the [[DefineOwnProperty]] trap of the WindowProxy.  That 
> then forwards to the Window, yes?

No. WindowProxy isn't an ES Proxy. (The term WindowProxy predates ES 
Proxy). When you have a WindowProxy object, it acts exactly like the 
Window object to which it currently points. It is indistinguishable from 
the Window object. When the WindowProxy changes what it's pointing at, 
it's exactly as if the browser had reached in and changed every 
WindowProxy that pointed to the former and made it point to the latter.


> > ...but the window proxy's [[GetOwnProperty]] just forwards that 
> > straight to the Window's [[GetOwnProperty]].
> 
> Yes, but since which window it forwards to changes you get an invariant 
> violation for the WindowProxy object itself.

I don't understand how that follows.


> > The property is on the Window, not the WindowProxy. It can't disappear 
> > from the Window. The invariant is thus maintained.
> 
> I think you misunderstand what the invariant is.

Maybe. Please elaborate.


> > There is no way to directly query the WindowProxy.
> 
> It doesn't matter.  The user sees the WindowProxy, not the Window.

No. What the author has is a WindowProxy, but in every sense it acts like 
a Window. (Which Window it acts like changes occasionally.)


> After you navigate, you still have the same WindowProxy (e.g. 
> .contentWindow returns something that is === to the thing you had before 
> you navigated).

You have no way to actually test this. Since every reference to the old 
Window is now a reference to the new Window, you have no way to test if 
the WindowProxy references something new. It's just like if the browser 
had reached in and changed all your references from under you.


> But properties it claimed to have that were non-configurable are now 
> gone.  That is precisely a violation of the invariants.

Suppose you have this code:

   // part 1
   let a = {};
   let b = {};
   let c = a;

   // part 2
   c.foo = 1;

   // part 3
   c = b;

   // part 4
   console.log(c.foo);

Is it surprising that the log doesn't log "1"?

This is what is going on here, except that part 3 is done by the browser.


> > To all intents and purposes, it's not a real object.
> 
> It looks like an object and quacks like an object.

It looks and quacks like a Window.


> > It's a reference to another object
> 
> JS doesn't have such a type in the language, sadly, so we can't model it 
> that way for consumers.

It turns out that it does have such a type. WindowProxy is it. I agree 
that that makes it a special snowflake.



On Wed, 14 Jan 2015, Mark S. Miller wrote:
>
> Boris has this exactly right. Further, a malicious proxy handler can 
> leverage the presence of a single object that violates these invariants 
> into the creation of arbitrary other proxies objects that also violate 
> these invariants. The key is that the enforcement of the invariants 
> relies on the proxy's target being constrained by these invariants.
> 
> See http://research.google.com/pubs/pub40736.html

If you're exposing your Window object to untrusted code you are so far 
beyond losing that this is the least of your concerns.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 January 2015 00:40:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 January 2015 00:40:40 UTC