Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

David Bruant bruant.d at gmail.com
Tue Jan 22 10:41:58 PST 2013


Le 22/01/2013 16:13, Tom Van Cutsem a écrit :
> 2013/1/22 Allen Wirfs-Brock <allen at wirfs-brock.com 
> <mailto:allen at wirfs-brock.com>>
>
>     We can probably fix the built-ins with some ad hoc language about
>     them automatically resolving proxies to the target as the this
>     value. Or perhaps we could expand the internal MOP api  to include
>     a resolve proxy to target operation.
>
>     Using private symbols for all of these cases, including the
>     built-ins also seems like an alternative that may work.
>
>
> Let me try to summarize:
>
> The proposal: private symbol access auto-unwraps proxies.
>
> In code:
>
> var s = new PrivateSymbol();
> var t = {};
> var p = Proxy(t, {...});
> t[s] = "foo"
> p[s] // doesn't trap, returns "foo"
> p[s] = "bar" // doesn't trap, sets t[s] = "bar"
>
> Pro:
> - would solve the issue of wrapping class instances with private state 
> stored via private symbols
> - would solve the issue of how to proxy built-ins, like Date, if they 
> are specified to use private symbols to access internal state
> - would get rid of the unknownPrivateSymbol trap in Proxies
> - could maybe even get rid of the private symbol whitelist in the 
> Proxy constructor, which would making proxies entirely oblivious to 
> private names
>
> Remaining issue: private symbols can pierce membranes.
>
> This issue is resolved if:
> - (base case) there are no built-in private symbols in a standard JS 
> environment (i.e. all the built-in symbols are unique)
> - (inductive case) a membrane takes care to detect and wrap any 
> private symbols that cross the membrane, and keeps a 1-to-1 mapping to 
> maintain the identity of the symbols across both sides of the membrane.
Just realizing now, but how does the membrane do the symbol unwrapping 
if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go 
through a public channel (get trap with a string name for instance) and 
if A created a symbol a, the membrane can provide a symbol b to the B 
context, but when A does "someObject[a] = 2" and B does "someObject[b]", 
both accesses pierce proxies, so the membrane can't do its unwrapping job.

Also, in some cases, the membrane can't switch a value.
     // in context A
     var s = new PrivateSymbol()
     var o = Object.freeze({s:s});
     // send o across the membrane

In B, invariants checks make that the membrane can't answer anything 
else than the original symbol when b retrieves the "s" property

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


More information about the es-discuss mailing list