Le 13/01/2013 01:27, Nathan Wall a écrit :
I'm still reluctant to give up on the unknownPrivateSymbol trap, because
doing so means giving up on mediation for one case.
In this case, we were able to capture every single private symbol passed
back and forth, but in another situation, maybe we didn't create A and B.
Someone else created them and just shared with each the same private
symbol and then handed off access to A and B so you can work with them.
You share an object through a membrane, they cooperate to do what you
ask them to (without using their shared secret), then, you'd like to cut
the communication? You revoke the membranes. But sharing a common object
(or a least different proxies to a common target) is all they need to
continue communicate since they have a private symbol you're oblivious
to, so they can still communicate.
In that scenario, the only way to actually cut the communication is the
unknownPrivateSymbol trap (admittedly, the scenario has been crafted to
that end, but is realistic anyway)
Is this scenario unique to private symbols? Can't I replace the word "private symbol" in
your scenario above with "WeakMap" (or really just any object) and you have the same
problem?
Yes or no. That's what we're debating. Private symbols and Weakmaps have
a lot in common. One major difference is how they are thought and used.
In how they are being used, they should be associated with strings (when
used in the context or property name).
Also, if the creator of A and B cares about how and whether they can
communicate, it can send a wrapped weakmap and revoke the access to the
shared weakmap anytime it wants. That's not an option with private
symbols without the unknownPrivateSymbol trap.
If A and B are created by someone else, and both A and B are given a shared
WeakMap and then they are passed off to a membrane which tries to cut
communication, can't A and B continue to communicate behind the scenes through
their shared WeakMap?
The contract of whoever created A and B may be just that it shared a
private symbol with them (maybe because it's using this symbol with
them). Maybe even specifically so that it can cut the communication latter.
I think if A and B are known directly to anyone before the membrane, they can
build a backdoor to communicate, `unknownPrivateSymbol` trap or not.
If A and B are known directly to one another, it's pointless to try to
separate them indeed. However, it can be in the contract of any other
party that they can make communicate A and B but only in a revokable manner.
The problem with private symbols without the unknownPrivateSymbol trap
is that it put in the language a way to provide an unrevokable ability
to communicate, making private symbols inadequate for a lot of
situations situations where you need to revoke it. Obviously, you can
work around with wrapped WeakMap, but suddenly, you've reduced what's
allowed in the language for untrusted code, elsewhere known as feature
starvation.
I think feature starvation is acceptable when you try to retrofit
proxies into existing APIs that weren't designed with proxies in mind
(DOM as an example). However I don't think it's acceptable for features
being worked on.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
