Security Demands Simplicity (was: Private Slots)

David Bruant bruant.d at gmail.com
Tue Jan 22 07:04:47 PST 2013


Le 22/01/2013 16:02, Tom Van Cutsem a écrit :
> 2013/1/22 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
>
>         Let's talk through Allen and Brandon's suggestion of
>         auto-unwrapping private symbol access on proxies.
>         If a membrane can intercept all exchanged private symbols I
>         think this could be made to work.
>
>     Agreed. Unfortunately, I think the condition ("If a membrane can
>     intercept all exchanged private symbols") cannot be fulfilled
>     practically. Let's start with:
>
>         var o = {a:{a:{a:new PrivateSymbol()}}}
>         // send o across the membrane
>
>     The membrane has to traverse o to find the symbol. The membrane
>     "can" do it, but it will cost the complete traversal of all
>     objects being passed back and forth which has a cost. An
>     arbitrarily big cost for arbitrarily complex objects.
>
>
> This is not my understanding of how membranes work:
>
> - when o is passed through the membrane, a proxy |op| is created for 
> it on the other side (let's call this the "inside")
> - when |op.a| is accessed inside the membrane, the membrane forwards 
> the operation, and creates a new proxy |opp| for the value returned by 
> |o.a|.
> - when |opp.a| is accessed inside the membrane, the membrane forwards 
> the operation, so retrieves |o.a.a|, sees that the value is a private 
> symbol, and returns a new private symbol instead.
>
> The same argument applies to the other examples you gave: membranes 
> only wrap lazily, and it's only at the point where an actual private 
> symbol value is about to cross the membrane (as argument or return 
> value of a forwarded operation) that one needs to detect (and wrap) 
> private symbols.
True. I'm taking back what I said :-)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130122/bfece741/attachment.html>


More information about the es-discuss mailing list