Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))
Tom Van Cutsem
tomvc.be at gmail.com
Wed Jan 23 00:38:11 PST 2013
2013/1/23 Brendan Eich <brendan at mozilla.com>
> Brandon Benvie wrote:
>> It is my opinion that the primary use case for private symbols is for
>> properties that proxies expressly shouldn't be given a chance, in any
>> manner, to corrupt or modify. They are likely used for sensitive internal
>> state that will only be accessed by methods or friend classes created in
>> service of the target.
>> A membrane becomes less valuable if breaking the target is an easily
>> accomplished accidental side effect. This is already visible in practice
>> today when you attempt to use WeakMaps to create private state for objects
>> and they are proxied, since the private state will be keyed on `this` in
>> the constructor which won't match `this` in methods invoked on the proxy.
> ding ding ding ding ding ding....
Let's try to separate the issues here:
1) proxies and private symbols: Brandon strengthens the case that proxies
should be oblivious to private symbols.
2) any sort of private state (regardless of whether it's stored using
private symbols or weakmaps) is always keyed off of the identity of the
3) because of JS's "invoke = get + apply" semantics, by default a proxy
always leaves the |this| value pointing at the proxy.
The combination of 2) and 3) is problematic (as in: not transparent).
Looking only at 3), sometimes this is what you want, and sometimes it
isn't. In the case of membranes I agree the more natural thing to do is to
rebind |this| to the real target, not a membraned proxy for it. I think
membranes can do that already without added cost: the "get" trap already
needs to return a wrapper for the actual function object anyway. That
wrapper, when called, can call the real function with the real target as
the |this| value.
Looking back at the code for an identity-preserving membrane <
I think this membrane actually properly unwraps the |this| value before
forwarding. I haven't yet tried expressing this code using Direct proxies,
but off the top of my head I don't see how the change from proxies to
direct proxies would impact this particular aspect of membranes.
So 3) may be an issue in general, but membranes should be able to avoid it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss