Security Demands Simplicity (was: Private Slots)

Tom Van Cutsem at
Mon Jan 21 08:33:16 PST 2013

2013/1/21 Brandon Benvie <brandon at>

> On Sun, Jan 20, 2013 at 10:41 PM, Brendan Eich <brendan at>wrote:
>> Brandon Benvie wrote:
>>> Going to the title of this thread, it's my view that private symbols
>>> should just auto-forward to the ultimate target no matter what,
>> Doesn't this allow private symbols to pierce membranes? Or do you mean
>> that each trap would have to check a whitelist and throw on miss.
> Somebody argued a while back, which convinced me, was that if the two
> parties already have access to the same private symbol, then they've
> already got a communication channel most likely. I would argue further that
> a private symbol's primary use case is for holding sensitive internal state
> that absolutely shouldn't be mucked with in most cases. If you wanted it to
> be potentially mucked with, you'd make it a normal symbol.

As David mentioned already, I have previously argued that symbols should
pass through a membrane unwrapped (like primitive values) because the only
useful property of a symbol is its identity, and wrapping an identity with
a fresh identity is pointless.

Given that assumption ("symbols pierce membranes"), Allen and Brandon's
proposal of having private symbol access auto-unwrap proxies is a
non-starter, as David already explained (it would open up a communications

So let's revisit the assumption: if a membrane does intercept and wrap
symbols, then two previously isolated pieces of code can never come to
share the same private symbol. In this case, Allen and Brandon's proposal
might actually work out, in which case we avoid proxy vs private symbol
complexity, and wrapping class instances with private state just works.

If membranes use WeakMaps internally to ensure that they always generate
unique wrappers for their objects, then wrapping private symbols might just
work (because passing the same private symbol back and forth across the
membrane will preserve the symbol's identity).

The remaining assumption is that there are no built-in, well-known private
symbols in the global environment by default. I.e. all "well known" symbols
such as @@iterator should be unique symbols. Otherwise it's trivial for two
isolated scripts to get access to the same private symbol, and pierce the
membrane that separates them.

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

More information about the es-discuss mailing list