Security Demands Simplicity (was: Private Slots)
Tom Van Cutsem
tomvc.be at gmail.com
Mon Jan 21 13:21:30 PST 2013
2013/1/21 Brendan Eich <brendan at mozilla.com>
> Andreas Rossberg wrote:
>> On 21 Jan 2013 17:33, "Tom Van Cutsem" <tomvc.be at gmail.com <mailto:
>> tomvc.be at gmail.com>> 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...
More information about the es-discuss