Security Demands Simplicity (was: Private Slots)

Brandon Benvie brandon at
Sun Jan 20 18:58:28 PST 2013

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, and that this
"trap opt-out" on a per property basis should be counted as a feature
instead of a limitation. Making any class/construct automatically
unproxyable upon its first use of a private symbol, as someone said
earlier, fatally wounds the value of proxies. But the more complex
solutions are hacky, as Brendan put it, at best and flimsy/fragile in all
likelihood, The only other viable option is to remove private symbols
entirely or to simply expose them to proxy traps, essentially making them
slightly-less-visible-but-not-entirely-private symbols.

On Sun, Jan 20, 2013 at 9:39 PM, Brendan Eich <brendan at> wrote:

> Allen Wirfs-Brock wrote:
>> This really makes me start to question even more the viability of Proxy
>> based membranes (direct proxies, at least) as an isolation mechanism.
>> Independent of private Symbols,  it isn't clear that it is a practical
>> approach.
> Firefox relies on proxies based on the original spec. They are "viable" --
> we don't have any soundness problems, and we bugfix validity problems until
> zarro boogs.
> Of course, we have not yet implemented symbols, private or public.
> Seriously, why are you doubting proxies? Please give more of an analytical
> argument. Yes, unknownPrivateSymbol as a "throw or do nothing" trap seems
> hacky. We may find a better way. But that's not a problem with proxies or
> membranes so much as private symbols in conjunction with the MOP and the
> integrity properties we want to enforce.
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list