On Jan 20, 2013, at 5:42 PM, David Bruant wrote: > Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit : > > >> On Jan 20, 2013, at 11:12 AM, David Bruant wrote: >>> "complicated" was an expression. Either proxies don't work with class >>> instances, making them vastly pointless or classes need to publicize their >>> private symbols (or maybe expose something like "myClass.acceptProxy" which >>> is marginally better), thus ruining their own encapsulation. >> Actually this whole discussion makes me question the validity of the current >> Proxy design rather than that of private Symbol. I may be on the road >> towards getting on the NotificationProxy train. > If there is time to make that big of a change, Mark's idea of action proxies > could be considered too. I've only expressed reluctance on the list, because > it allows to do weird things when badly used, but for all use cases I've had, > it would be fine. Tom expressed reluctance regarding the cost of action > proxies, but I'm not entirely sure it's founded. > Although Notification and action proxies are good to get rid of the > invariants cost, I'm not entirely sure they can help to reduce the complexity > when it comes to private symbols. > > >> (...) >> >> This suggests a possible generalized solution to the Proxy/private symbol >> exposure problem: >> >> The [[Get]] and [[Set]] (and probably some others) internal methods of a >> proxy never call the corresponding trap when the property key is a private >> Symbol. Instead, they trace the [[Target]] chain of the proxy until a >> non-proxy object is reached (call this the "ultimate target"). It then >> invokes the ultimate target's [[Gett]]/[[Set]] using that same private >> Symbol key. The result of that operation is then returned as the value of >> the original [[Get]]/[[Set]]. >> >> The "private" state access is applied to the correct object and there is no >> exposure of the private symbol! > It can work for built-in private state (and could work for private class > syntax too), but not for user-generated or obtained private symbols: > Let's say 2 untrusted parties are in 2 membranes. They share a private symbol > and each has access to a proxy wrapping a common target. With the private > symbols semantics you're describing, these 2 untrusted parties have an > unmediated communication channel.
How did they originally come to share the private symbol? Don't they have to have some common point of origin with visibility of the symbol or have both been provided the private symbol by some third party. In either case couldn't they have closure captured references to each other and use those references for direct communicate? > An unmediated communication channel defeats the purpose of having put the 2 > untrusted parties in membranes in the first place. > The semantics of user-generated or obtained symbols has to go through proxy > mediation because of this use case, hence the whitelist and the > unknownPrivateSymbol trap in the current proxy design. This really makes me start to question even more the viability of Proxy based membranes (direct proxies, at least) as an isolation mechanism. Independent of private Symbols, it isn't clear that it is a practical approach. Also, I think some of the issues discussed in the thread https://mail.mozilla.org/pipermail/es-discuss/2012-December/027246.html have bearing on this discussion. It is probably worth taking a second look. Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
