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

Hi Travis, I didn't follow. Could you expand, assuming less background
knowledge?  Thanks.
 On Jan 14, 2015 2:58 PM, "Travis Leithead" <travis.leithead@microsoft.com>
wrote:

>  WindowProxies are going to be a challenge when it comes to a pure ES
> implementation. The other challenge that just came to mind, is the document
> object—at least in Gecko and IE: a document.write call will “re-init” the
> object (subbing out the old var for a new one) while maintaining the ===
> invariant. Chrome appears to have a simpler model for dealing with this.
> I’m not sure what HTML has to say about this currently…
>
>
>
> *From:* Mark S. Miller [mailto:erights@google.com]
> *Sent:* Wednesday, January 14, 2015 2:44 PM
> *To:* Boris Zbarsky
> *Cc:* Ian Hickson; Travis Leithead; Domenic Denicola;
> public-script-coord@w3.org; es-discuss
> *Subject:* Re: Figuring out the behavior of WindowProxy in the face of
> non-configurable properties
>
>
>
> 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
>
>
>
>
>
>
>
> On Wed, Jan 14, 2015 at 2:32 PM, Boris Zbarsky <bzbarsky@mit.edu> 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?
>
> 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?
>
> ...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.
>
> 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.
>
> There is no way to directly query the WindowProxy.
>
>
> It doesn't matter.  The user sees the WindowProxy, not the Window. After
> you navigate, you still have the same WindowProxy (e.g. .contentWindow
> returns something that is === to the thing you had before you navigated).
> But properties it claimed to have that were non-configurable are now gone.
> That is precisely a violation of the invariants.
>
> To all intents and purposes, it's not a real object.
>
>
> It looks like an object and quacks like an object.  Sorry, but it's an
> object as far as all consumers are concerned; they have no way to tell it
> apart from an object except _maybe_ via these invariant violations. But
> then you've entered circular argument territory.
>
> 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.
>
> -Boris
>
>
>
>
>
> --
>
>     Cheers,
>     --MarkM
>