Security Demands Simplicity (was: Private Slots)

Tom Van Cutsem at
Mon Jan 21 13:21:30 PST 2013

2013/1/21 Brendan Eich <brendan at>

> Andreas Rossberg wrote:
>> On 21 Jan 2013 17:33, "Tom Van Cutsem" < at <mailto:
>> at>> wrote:
>> >
>> > 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.
>> I'm not sure I understand what "wrapping a symbol" would actually mean.
>> Are you implying that proxies that target a symbol should actually be
>> usable _as_ a symbol?
>>  I think Tom meant wrapping as in membrane-wrapping, just as any object
> going through a membrane implemented by a proxy would be wrapped. I.e.,
> symbols are not primitive values, they are objects. So membrane-wrapping a
> symbol means making a new symbol that can be mapped back to the original
> when flowing back across the membrane.
> We had the old .public idea in play to do something like this. A proxy
> would never get access to a private symbol, only its "public key". If it
> had been endowed with a map of such back to the private identities, then it
> could unwrap. Otherwise, no privacy leak.
> It seems even simpler to make symbols a distinct class of object (special
> case for property naming) and otherwise let them be membrane-wrapped.
> (Let's defer typeof result value.)

What I meant is that the membrane allocates a new private symbol per
private symbol it intercepts, and keeps a mapping between the two. I didn't
mean to imply creating a proxy for a symbol.

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

More information about the es-discuss mailing list