[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
solved.




>
>
> 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
>
>


-- 
    Cheers,
    --MarkM
-------------- 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