Proxying built-ins (Was: [[Invoke]] and implicit method calls)

Brendan Eich brendan at mozilla.com
Thu Sep 26 12:18:03 PDT 2013


> Anne van Kesteren <mailto:annevk at annevk.nl>
> September 26, 2013 5:44 AM
>
> Probably does not matter much, but the cross-origin case might become
> proxy objects long term due to process isolation.

Backward compat says it doesn't matter, but process isolation really 
wants async APIs. Some browsers currently, e.g., make window.open 
cross-process more async than other browsers.

Something to pin down, and more important: provide promise-based modern 
(and sane) equivalent APIs.

/be
>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> September 25, 2013 9:22 PM
>
>
> This goes back to the dawn of JS. You can set location on a reachable 
> frame or window, even if not same-origin.
>
> There's no revocation in the Revocable Membrane sense going on. 
> Rather, the membraning has to distinguish gets and other operations 
> from sets, and throw or unwrap |this| accordingly.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Boris Zbarsky <mailto:bzbarsky at MIT.EDU>
> September 25, 2013 7:26 PM
> On 9/25/13 5:33 PM, David Bruant wrote:
>> This line looks very WebIDL-ish. Does the web really need that to work?
>
> The web doesn't need anything involving getOwnPropertyDescriptor to 
> work.  I just picked a simple example.
>
> The web _does_ in general rely on being able to apply methods from 
> some built-in (including DOM) prototype in one realm to objects from 
> another realm.
>
>> What are the other such cases that require this check?
>
> Which "this check"?
>
> -Boris
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> David Bruant <mailto:bruant.d at gmail.com>
> September 25, 2013 2:33 PM
> Le 25/09/2013 22:00, Boris Zbarsky a écrit :
>> On 9/25/13 3:47 PM, Mark S. Miller wrote:
>>> Hi Boris, I don't understand what you mean by "in general". I think the
>>> SpiderMonkey use of cross-realm membranes is a great use case for
>>> membranes, and I don't understand why they need any special logic at 
>>> all
>>> -- beyond the logic expressed by their handlers, which must include
>>> revocation.
>>
>> Mark,
>>
>> The issue is that if I have access to a different-realm Location 
>> object called "loc", say, then:
>>
>>   Object.getOwnPropertyDescriptor(Location.prototype, 
>> "href").get.call(loc)
>>
>> should throw if the "loc" is not same-origin with me.
>> But:
>>
>> Object.getOwnPropertyDescriptor(Location.prototype, 
>> "href").set.call(loc, "whatever")
>>
>> should perform the set.
> This line looks very WebIDL-ish. Does the web really need that to work?
> Isn't it a case of WebIDL being overzealous?
>
>> (There are actually some more complications here for the specific 
>> case of Location, but let's ignore them for now.)
>>
>> What that means in practice is that the membrane isn't actually 
>> "revoked": it needs to be unwrapped to the real underlying object in 
>> some cases, but not others.
>>
>> The way we implement that, again, is with a way to unconditionally 
>> unwrap a cross-realm membrane, and a way to ask a cross-realm 
>> membrane whether it's ok to unwrap it.
> What are the other such cases that require this check?
>
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Boris Zbarsky <mailto:bzbarsky at MIT.EDU>
> September 25, 2013 1:00 PM
>
>
> Mark,
>
> The issue is that if I have access to a different-realm Location 
> object called "loc", say, then:
>
>   Object.getOwnPropertyDescriptor(Location.prototype, 
> "href").get.call(loc)
>
> should throw if the "loc" is not same-origin with me.  But:
>
> Object.getOwnPropertyDescriptor(Location.prototype, 
> "href").set.call(loc, "whatever")
>
> should perform the set.  (There are actually some more complications 
> here for the specific case of Location, but let's ignore them for now.)
>
> What that means in practice is that the membrane isn't actually 
> "revoked": it needs to be unwrapped to the real underlying object in 
> some cases, but not others.
>
> The way we implement that, again, is with a way to unconditionally 
> unwrap a cross-realm membrane, and a way to ask a cross-realm membrane 
> whether it's ok to unwrap it.  Some of the methods/getters/setters 
> involved use the former, and some use the latter.
>
> Note that in this case the actual property getter/setter is gotten 
> without any interaction with membranes at all.  The only question is 
> when a membrane around the thisArg to a function can be pierced to get 
> to the thing the function actually knows how to operate on.
>
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list