Security Demands Simplicity (was: Private Slots)
bruant.d at gmail.com
Sun Jan 20 17:42:42 PST 2013
Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
> Hopefully. I think an important characteristic of the current class definition syntax is that it conceptually desugars to more primitive features of the object model that are exposed to the language. If you don't like the class syntax or want to extend it you can use functional definitional forms or write a transpiler that produce identical runtime structures to what is produced by class declarations.
> If class definitions exploit capabilities that are only available to them, then we would loose this characteristic.
> 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.
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.
More information about the es-discuss