<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 15, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 15, 2011, at 3:51 AM, Tom Van Cutsem wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">Hi Allen,</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; min-height: 15px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">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.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; min-height: 15px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">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.</div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; min-height: 15px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">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.</div></blockquote><div><br></div><div>But can't a Proxy based object do all sorts of nasty back channel stuff even while it maintains the apparent object freeze invariants?</div></div></div></blockquote><div><br></div><div>Duh, of course a frozen object really isn't a Proxy any more as currently defined. But is has also lost all useful intercession  derived semantics.</div><div><br></div><div>BTW, if <a href="http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties">http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties</a> was extended to support Object.preventExtensions we might not have anything to argue about except perhaps performance issues. </div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div>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.</div><div><br></div><div><br></div></div>Allen</div>_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>https://mail.mozilla.org/listinfo/es-discuss<br></blockquote></div><br></body></html>