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

Tom Van Cutsem tomvc.be at gmail.com
Tue Jan 22 11:05:22 PST 2013


2013/1/22 David Bruant <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). 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.


> 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.

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


More information about the es-discuss mailing list