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

Mark S. Miller erights at
Mon Jan 28 11:42:32 PST 2013

On Mon, Jan 28, 2013 at 11:10 AM, David Bruant <bruant.d at> wrote:

> Hi Tom,
> Thanks for this summary.
> About the first proposal and getting rid of the whitelist, indeed, the
> whitelist was here to tell about known symbols to avoid leakage. If private
> symbols pierce proxies, the whitelist has no purpose any longer.
> I don't understand why problem B isn't solved with the first proposal.
> Since the proxy is pierced, access to private symbol'ed properties don't
> trap and the proxy can't throw on access (since it's not trapped).
> If I'm misunderstanding the proposal, could you show an example, under the
> unconditional forwarding proposal in which the problem B can be reproduced.
> The second proposal reminds me a bit of an evolution of the first proxy
> design in which each proxy would have its own storage for invariant checks.
> Since a forwarding proxy was the main use case and already had a storage
> area (the target), this led to the second design "direct proxy" in which
> both storages would be merged in the target.
> By analogy, the natural evolution of the second proposal would be the
> first proposal.

The natural evolution of the second proposal is to use WeakMaps where we
would otherwise use private symbols, and get rid of the notion of private
symbol per se.

Modulo naming, Kevin's unified proposal is equivalent to this. To illustrate

function KevinsSymbol() {
  var result = WeakMap();
  result.__proto__ = null; // no own properties and inherits no properties
  return Object.freeze(result);

(Given) var call =;

var kevinsGet = call.bind(WeakMap.prototype.get);
var kevinsSet = call.bind(WeakMap.prototype.set);

> David
> Le 28/01/2013 19:45, Tom Van Cutsem a écrit :
>  I just wrote up a strawman on the wiki to summarize the recent debates
>> about the interaction between proxies and private symbols:
>> symbol_decoupled<>
>> The page actually lists two proposals, out of which I prefer the second
>> one.
>> If I forgot some benefits/drawbacks of either approach, please speak up.
>> Thanks.
>> Cheers,
>> Tom

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

More information about the es-discuss mailing list