Security Demands Simplicity (was: Private Slots)

Brandon Benvie brandon at
Sun Jan 20 20:23:16 PST 2013

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.

>  and that this "trap opt-out" on a per property basis should be counted as
>> a feature instead of a limitation.
> I don't know what you mean by this clause.

What I meant was that it'd be a useful feature to have a method of
selectively making properties non-proxied. For example, say Date was
implemented using the @@DateValue private symbol. As the implementor of
Date, I'd have no problem with Date instances being proxied, but I'd want
to continue having guarantees about just that one property. I'd want
guarantees that it will *not* throw unexpectedly and leave my object (the
actual proxy target) in a broken state. I think it'd be really useful to
have this guarantee as a feature of private symbols (with the other benefit
that it drastically simplifies the proxy/private.symbol story).

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

More information about the es-discuss mailing list