direct_proxies "problem"

David Bruant bruant.d at gmail.com
Sat Jan 12 15:10:44 PST 2013


Le 12/01/2013 23:54, Nathan Wall a écrit :
> David Bruant wrote:
>> Leaking the information that the node is actually a proxy is due to a
>> DOM API issue (which is way way too late to fix obviously).
>> If you want proxied node to go in the tree, you'll need to find an
>> answer to the issue Boris Zbarsky brought up about selector matching
>> [1]. I've given up [2], but I'm curious to know if there is a decent
>> solution.
> I have an idea, but I'm going to think through it some more and possibly post it as a separate reply later to keep this reply more focused.
I'm looking forward to it :-)

>> Thinking a bit more about how A and B can share things, I'm realizing
>> that anytime they want to share a private symbol, they have to do it
>> through a "capturable" channel (set trap value argument, etc.). So if A
>> and B are in touch, the membrane could capture all private symbols going
>> from one side to the other and add it to the membrane whitelist. This
>> way, anytime there is a communication attempt via private symbols, the
>> private symbol is known and the non-unknownPrivateSymbol trap is called.
>> In theory, it makes the unknownPrivateSymbol not absolutely necessary
>> for this use case.
>> In practice, to capture all communication, anytime the membranes
>> intercept a new symbol, it needs to make sure it wasn't used on any
>> other object previously shared between both parties and that means
>> traversing entire graphs of objects which may be an enormous amount of
>> work degrading performance.
>> I'm also not a big fan of retroffiting control afterwards.
> Ok, I think I understand now.
>
> Here's how I'm imagining it: So if A shares object O with B, the membrane may wrap O in proxy P. O may have a private symbol properties M and N, where the property for symbol M actually points to symbol N:
>
>      let O = { },
>          M = new Symbol(true/* private */),
>          N = new Symbol(true/* private */);
>      O[M] = N;
>      O[N] = null;
>
> When A shares O with B, the membrane will not be able to see either one of these symbols.
Exactly.

> Let's assume no `unknownPrivateSymbol` trap.
>
> The objects cannot yet communicate without the membrane knowing because B does not know O's private symbols.
>
> Later if A shares private symbol M with B, the membrane will intercept the symbol and add it to the whitelist before passing it along. Now the membrane knows about M but it can only learn about N by searching all previous communications for M. The membrane could in theory discover N by searching previous communications for M and finding N in O.
That's the scenario I had in mind.

> I agree with you though that this is a pretty huge overhead for the membrane to have to do, so let's look for another way.
>
> If the membrane fails to search O for M, then B can discover N under-the-hood -- that is, B gets access to a private symbol that the membrane doesn't have on its whitelist.
Yes. And suddenly A and B can communicate together in ways they aren't 
supposed to.

> However, what if the membrane, instead of passing along M, creates a new private symbol M2, and this is the actual symbol shared with B. Now if B checks O for property M2 it will not be able to uncover the symbol N.  The membrane adds M2 to its whitelist and anytime B tries to send M2 back to A, the membrane converts it to M (and vice versa). Therefore, A always sees only symbol M and B always sees only symbol M2.
>
> Does this work and allow us to do without `unknownPrivateSymbol`?
I don't think this work. It's important to share the same private 
symbol, very much like it's important that if O has a "foo" property, it 
has a "foo" property in both A and B contexts and not "fooa" in one and 
"foob" in the other.

> (An even easier alternative is that the membrane could prevent sharing private symbols.)
I don't think that's an option because there are legitimate use cases of 
private symbols with proxies.

David


More information about the es-discuss mailing list