Le dim. 13 janv. 2013 00:43:29 CET, Nathan Wall a écrit :
David Bruant wrote:
Yes and once the membrane has captured N, it has to search again if some
object use in A<--->B communication has an N property... and restart all
over if an object does and has another private name attached.
Theoretically, the membrane can always be one step ahead of the private
communication. Practically, it costs a lot without the
unknownPrivateSymbol trap.
I was under the impression that all objects that were passed from A to
B were wrapped in a proxy by the membrane. If this is the case, then
the membrane simply needs to add N to the whitelist and N can't be
used in B on an object from A without the membrane knowing about it.
True. I guess it simplifies things a lot :-p
So there's no need to search previous communications. The membrane can
learn about any private symbols B can because the membrane is always
watching B's access to objects from A through proxies.
Ok, I'm convinced. This scenario doesn't need the unknownPrivateSymbol
trap after all apparently. Thanks for not giving up Nathan :-)
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)
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
