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

Tom Van Cutsem at
Tue Jan 22 07:13:56 PST 2013

2013/1/22 Allen Wirfs-Brock <allen at>

> 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"

- 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.

It's worth noting that revocable proxies (those created using
Proxy.revocable) would also stop forwarding private symbol access when

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list