Converting an existing object to a proxy

Brendan Eich brendan at mozilla.com
Fri May 27 09:12:46 PDT 2011


On May 27, 2011, at 8:10 AM, Sean Eagan wrote:

> I think the separation between proxies and regular objects is too
> much.  I would prefer to think of proxies as just a special kind of
> object.  All objects could be thought of as having a handler (
> [[Handler]] ), and "proxy objects" could be those objects whose
> handler is an actual ES object as opposed to an abstract language
> specification object.

This is a way of thinking about proxies in the context of JS, for sure. Please see this slide

http://brendaneich.com/brendaneich_content/uploads/selective-interception.png

from Tom and Mark.


>  This would be similar to the distinction
> betweeen "data" and "accessor" properties, since you could think of a
> default abstract [[Set]] and [[Get]] implementation for property
> descriptors.  Then fixing a proxy object could just be thought of as
> setting the object's [[Handler]] to an abstract specification handler,
> and Proxy.createFrom can just be thought of as setting the object's
> [[Handler]] to an actual ES object.  The abstract [[Handler]] could
> either be implemented via pseudocode similar to the ES5 spec or by
> actual ES code if a testable / executable object spec is desired.

The problem is making the "VM handlers" (to use the slide's terms) concrete, not abstract. No VM implementor wants that. Nor do security folks -- at least not read/write VM handler access.

When we first started discussing "catch-alls", before Proxies were proposed, TC39 members stopped progress on catch-alls by citing the "climbing the meta ladder" problem. This is where the spec and real code, instead of bottoming out at unspoofable core semantics, trap back into "user code" doing meta-programming of arbitrary objects.

This is why VM implementors object. They can't optimize as well if they have to check more potentially varying "invariants of ES1-5". This is why Proxies are a special kind of object.

The security issue is similar. If an attacker can vary invariants the VM needs to enforce via a built-in handler to preserve integrity or other safety properties, that's a security hole. It may be that frozen and sealed objects being immune is enough, for some operations such as watching gets and sets. As noted, for a non-sealed object, those could be done by wrapping each property in an accessor after transplanting it to an inner object or a peer property with a private name. But intercession at the VM handler layer may be strictly more powerful than get, set, or even delete trapping.


> I've been working on a concept called "object descriptors" which are
> an object level equivalent of property descriptors.  One of the object
> descriptor attributes I'm including is "handler".  Object descriptors
> could also have a "configurable" attribute which could control whether
> an object's "handler" (and other attributes) can be changed.

This helps but the VM implementors may still object to reflecting currently-hidden VM handlers. There may be security issues we are missing. And unless the built-in objects of Clause 15 all have non-configurable handlers, you are talking about climbing the meta ladder in the spec.

/be

> 
> On Fri, May 27, 2011 at 9:21 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> On May 27, 2011, at 3:04 AM, David Bruant wrote:
>> 
>> The idea of permitting this "becomes" operation only for extensible objects
>> with configurable properties is crucial.
>> 
>> Is it? The first time I heard about the "become" operation was in the
>> context of the proxy fix trap. Second time was this message. It doesn't
>> sounds crucial yet to me.
>> 
>> The "crucial" applied to both "only for extensible objects with configurable
>> properties" in that sentence. ;-)
>> The issue as I understand it is not becomes per se (more below), rather that
>> an extensible object with configurable (own) properties could have those
>> properties wrapped by accessors to emulate some of the intercessive power of
>> proxies. From the security point of view, you want frozen and sealed
>> objects, at least, to be immune to proxification because they are immune to
>> such property-by-property wrapping with accessors, today.
>> See Mark's reply on the list dated 7:33pm yesterday.
>> 
>> The motivation is to unify ideas in proxies (in Harmony) with those proposed
>> in http://wiki.ecmascript.org/doku.php?id=strawman:observe.
>> 
>> I hadn't read this proposal yet. Thanks.
>> 
>> I think that this discussion raises the following question:
>> Should all usages of the "become" operation be associated with proxies?
>> 
>> We are not exposing becomes in the language -- certainly not for two
>> arbitrary live objects.
>> In both the proxy fix case, and in this Proxy.createFrom case, one of the
>> two objects is a newborn, not yet accessible. We brain-transplant between
>> the accessible and inaccessible, swapping the objects' data. The identity is
>> preserved but the internal and own properties are exchanged.
>> Questions about the proxify-existing-object case:
>> 1. Won't the proxy want the original "brain", the one transplanted into a
>> newborn proxy (now "become" the regular object)?
>> 2. Will the costs here be acceptable compared to something unstratified
>> requiring no extra object, a la strawman:observe?
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
> 
> 
> 
> -- 
> Sean Eagan



More information about the es-discuss mailing list