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

On 01/15/2015 12:58 AM, Travis Leithead 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…

Gecko and IE follow the spec and Chrome does something else.


>
> *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 <mailto: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
>

Received on Wednesday, 14 January 2015 23:02:11 UTC