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