[[Extensible]]and Proxies (Was: Proxy.isProxy )

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jul 15 11:16:43 PDT 2011

On Jul 15, 2011, at 3:51 AM, Tom Van Cutsem wrote:

> Hi Allen,
> While proxies are definitely designed to emulate some of the peculiar behavior of host objects, that does not necessarily imply that proxies should be as powerful and free of restrictions as host objects. If any JS script can create a proxy, and a proxy can violate invariants that do hold for built-in Object or Function values, the logical implication is that Javascript code, in general, can no longer rely on those invariants. Code that does can then more easily be exploited.

My view is that intercession is useful in that it supports the implementation of object semantics that differ form the base language.  It actually seems to me that the property attributes are part of those base object semantics that might be reasonably modified by intercession.  But I guess that is really the base question here.  What are the base invariants that must be maintained at all costs and what are secondary invariants that may be useful but not essential.
> Consider a non-configurable, non-writable data property. The binding of such a property for regular objects is guaranteed to be immutable. Immutability can be used for caching purposes, but is equally useful to not have to adopt a defensive coding style (as a point in case, take Mark's implementation of the structured clone algorithm in JS. Such defensive coding would be unnecessary when dealing with frozen objects.) In a security context, immutability may be used to determine whether or not to allow some third-party code to access an object.

The immediate issue was about [[Extensible]] not about the broader issue of Object.freeze.  I think they are probably separable issues  and that part of the disagreement is that they have been conflated.

> In short, if proxies could violate the semantics of e.g. frozen objects, then it seems to me that the usefulness of that concept is severely crippled. Where Object.isFrozen would have been a test for guaranteed immutability (of an object's structure), it merely becomes a test that hints at it, but cannot be relied upon.

But can't a Proxy based object do all sorts of nasty back channel stuff even while it maintains the apparent object freeze invariants?

More generally, it seems like what you really need to defend against is objects that are implemented via untrusted Proxy handlers. I have no problem with "your" defensive subsystem rejecting my non-extensible proxy based array because you don't trust my proxy handler.  But to tell me that I can't even create such an object for my own purposes because you are are afraid I might pass it to you  seems to be putting your use case ahead of mine.

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

More information about the es-discuss mailing list