[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu May 12 19:18:26 PDT 2011

On Thu, May 12, 2011 at 6:48 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> My understanding was that a major motivation for these operations was  to
> create objects that can be passed to untrusted code while being safe from
> tampering.  The work around in the presences of proxies would seem to be
> don't pass any such buggy proxies or to create your own trusted proxy that
> wrappers the potentially buggy proxy.

> The use case is not always defensive programming, e.g. frozen objects
> facilitate caching without cache invalidation.
> You can presumably still do that cache based upon the implied invariant. A
> failure to respect the invariant within the proxy is a bug that you might
> want to have a test case for but probably shouldn't cause you to change your
> design.   Just like most of the other  object invariants that proxies don't
> guarantee but your program probably depends upon.

This is equivalent to saying that attacks can choose to be nice to
defenders. If attackers aren't nice, then their code is buggy, so problem

> W.r.t. non-configurable properties: at this point I am convinced that
> Sean's API is better than the current design of outright rejecting
> non-configurable properties. Surely there will be cases where proxies will
> need to emulate non-configurable properties. Also, the fact that the default
> forwarding handler can't straightforwardly delegate getOwnPropertyDescriptor
> calls to its target (since it has to change the property's configurability)
> is a bad smell.
> I don't like Sean's API because it requires the trapping infrastructure to
> build and perform validation against a potentially large data structure (per
> object table of all property names that have been set non-confgurable).
> That's the sort of complex invariant maintenance that I don't think belongs
> at the implementation level of a dynamic language.  Consider as a use case
> the ES5 String object.  String objects have a "virtual" property foe each
> character of their underlying string value.  Each of these character
> properties is non-configurable but the String object itself is extensible.
>  A string value potentially has millions of such character properties and
> they routinely have thousands of them.  Using Proxies to implement this
> style of virtual properties over some fixed data source seems like a great
> use case. It should be possible and it should burden the underlying runtime
> with the overhead of validating a complex invariant that is practice would
> likely only fail during debugging of the Proxy.
> Building on an earlier idea proposed by David ("inheritance-safe proxies"),
> a compromise could be as follows:
> - allow proxies to emulate/intercept non-configurable properties without
> checking
> - introduce an "ESObject" abstraction such that if h is a user-defined
> proxy handler, ESObject(h) creates a "safe" proxy handler that checks
> conformance of the handler w.r.t. the above ES5 Object semantics. This can
> be useful for catching bugs, or preventing misbehavior, depending on your
> POV.
> This seems like a reasonable approach.
> I've come to view the "native object" semantics defined in ES5 section 8 as
> simply one of many possible object semantics that can be supported by the
> core ES language constructs.  Most of the ES built-in object types implement
> some sort of dialect of the "native object" semantics.  DOM objects have
> even greater divergence and arbitrary host objects in some implementation
> can diverge from "native object" semantics in even more ways.  I thing
> Proxies needed to be view as being closer in power to host objects then they
> are to "native objects".  Given this, it would be great to have a ESObject
> implementation that programmer can refine for the situations where they
> intend to make not or only minor variations form the standard semantics.
> In terms to the core semantics of Proxies, I think we should restrict
> ourselves to the semantics that are required to support the individual
> statements and operators of the core ES language. These are the same
> semantics that are needed to make those statements and operators operate the
> current range of native, built-in, host objects.
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110512/bd3285c0/attachment-0001.html>

More information about the es-discuss mailing list