Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

David Bruant bruant.d at gmail.com
Tue Jan 22 12:09:48 PST 2013


Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
> 2013/1/22 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     Just realizing now, but how does the membrane do the symbol
>     unwrapping if private symbols pierces it?
>     2 contexts A and B share a symbol, the symbol initially has to go
>     through a public channel (get trap with a string name for
>     instance) and if A created a symbol a, the membrane can provide a
>     symbol b to the B context, but when A does "someObject[a] = 2" and
>     B does "someObject[b]", both accesses pierce proxies, so the
>     membrane can't do its unwrapping job.
>
>
> The membrane doesn't need to unwrap. Evaluating "someObject[a]" in A, 
> and "someObject[b]" in B will result in different values.
>
> In the context of membranes, "someObject" is actually a "Harvey 
> Two-Face" type of object (its split across two worlds, one in A, and a 
> proxy representation in B).
Indeed, sorry, using "someObject" in both cases was a confusing shortcut.

> Symbol-keyed indexing on the A face is distinct from symbol-keyed 
> indexing on the B face. But that's OK: it's the job of the membrane to 
> separate the A and the B face in the first place.
I don't think that's ok. A goal of the proxy mediation is to gives A and 
B the impression they communicate with one another like if there was no 
mediation (but keeping the right to revoke all communications when 
necessary). That's why the membrane faithfully forwards primitive values 
and preserve object identity equalities in other cases than private symbols.
If you created A and B and started to make them communicate, it's 
because you wanted them to collaborate to achieve something for you. If 
A and B share a private symbol, it's in order to communicate using it. 
If the membrane changes the symbol, then A and B don't communicate as if 
there was no mediation anymore. It's even possible that they won't be 
able to work together if their mutual collaboration relied on 
communication via the private symbol they expected to share.

>     Also, in some cases, the membrane can't switch a value.
>         // in context A
>
>         var s = new PrivateSymbol()
>         var o = Object.freeze({s:s});
>         // send o across the membrane
>
>     In B, invariants checks make that the membrane can't answer
>     anything else than the original symbol when b retrieves the "s"
>     property
>
>
> This is independent of private symbols. The same issue occurs if s 
> were a String. That's what requires the shadow-target work-around in 
> membrane proxies in general.
Good point.

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


More information about the es-discuss mailing list