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.
I've come around to think that auto-unwrapping may be a simpler idea in
the end. Maybe in complicated use cases it will require some additional
work to not leak private symbols.
As explained above, auto-unwrapping would prevent 2 untrusted membraned
parties to communicate directly through the private symbols, but the
language already provides way enough ways to communicate (public object
properties, arguments/return values in function calls).
I think it was crucially important that each context is consistent and
oblivious to being wrapped and you've explained it could be done
efficiently (1-1 mapping of private symbols) so I guess there is no
problem on that side.
Securing the use private symbols will always require some additional
book-keeping and that's unfortunate, but the cost sounds acceptable.
Probably a library can be provided to help out proxy authors in the
bookkeeping.
As you noted, one crucially important point is that no built-in private
symbol is introduced in the language.
Le 22/01/2013 21:09, David Bruant a écrit :
> Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
>> 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.
I've come around to think that auto-unwrapping may be a simpler idea in
the end. Maybe in complicated use cases it will require some additional
work to not leak private symbols.
As explained above, auto-unwrapping would prevent 2 untrusted membraned
parties to communicate directly through the private symbols, but the
language already provides way enough ways to communicate (public object
properties, arguments/return values in function calls).
I think it was crucially important that each context is consistent and
oblivious to being wrapped and you've explained it could be done
efficiently (1-1 mapping of private symbols) so I guess there is no
problem on that side.
Securing the use private symbols will always require some additional
book-keeping and that's unfortunate, but the cost sounds acceptable.
Probably a library can be provided to help out proxy authors in the
bookkeeping.
As you noted, one crucially important point is that no built-in private
symbol is introduced in the language.
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130124/f623e3ac/attachment.html>
Le 22/01/2013 21:09, David Bruant a écrit :
I've come around to think that auto-unwrapping may be a simpler idea in the end. Maybe in complicated use cases it will require some additional work to not leak private symbols. As explained above, auto-unwrapping would prevent 2 untrusted membraned parties to communicate directly through the private symbols, but the language already provides way enough ways to communicate (public object properties, arguments/return values in function calls). I think it was crucially important that each context is consistent and oblivious to being wrapped and you've explained it could be done efficiently (1-1 mapping of private symbols) so I guess there is no problem on that side. Securing the use private symbols will always require some additional book-keeping and that's unfortunate, but the cost sounds acceptable. Probably a library can be provided to help out proxy authors in the bookkeeping.
As you noted, one crucially important point is that no built-in private symbol is introduced in the language.