Are Private name and Weak Map the same feature? and the Assoc API

David Bruant bruant.d at gmail.com
Fri Dec 16 15:09:56 PST 2011


Le 16/12/2011 22:03, Brendan Eich a écrit :
> From: "David Bruant" <bruant.d at gmail.com>
>> ** if I trust a proxy, I share a: 
> Stop right there. You don't know whether another object passed to you is a proxy or not. You cannot tell, in general. Nor should you have to care!
I made a mistake when I talked about "trusting a proxy". It's not about
trusting a proxy. It's about trusting an object, object which, in the
"worst" case is a proxy, hence my use of "proxy".
While I agree you should not have to worry which object is a proxy and
which is a regular object, being aware of which objects you trust and
which you don't is an exercice you already do when you program in an
ocap style. That's my understanding at least.

> Requiring you to care in order to avoid leaking private names is incredibly error-prone.
So is requiring you to care in order to avoid leaking the public ->
private map. It's no more, no less dangerous or error-prone.
If I have to be careful about who I hand a reference to the public ->
private dictionary, how is it more dangerous or error-prone to be
careful about who you hand the private name to? It's the exact same work.

I think the difference lies in the habit we have in ES5 that "o[n]"
would not disclose a secret. Also, in ES5+private names "o[n]" does not
disclose a secret. My impression is that '.public' in an attempt to
preserve this property with proxies.

I propose to take the other approach which is to accept that "o[n]" may
disclose 'n' if 'o' is a proxy. I agree this is a big change in how we
think objects.

> Again, private-named properties are "in" and "own", so proxies' handler traps should see something corresponding to them as property names. But leaks must be ruled out by design.
In some of his presentations, Mark Miller lists 4 ways for an object to
have access to another object: introduction, parenthood, endowment and
initial conditions.
If 'o' is a proxy and if "o[n]" shared 'n' to 'o', then it would just be
a case of introduction. You decide to hand a reference of the private
name to 'o'. It doesn't look like the usual case of introduction
(passing as function argument), but that would be another instance.

Maybe we just need to change the way we think of objects and get used to
consider "o[n]" is an introduction. As much as "o.doWhatYouWant(n)".

You call sharing 'n' in "o[n]" a "leak", I call it a feature and like
all features, we should be aware of potential threats. For sure it will
affect as we program... equivalently to like defining a public ->
private map and give access to it will affect as we program. No more no
less.

> You can think of the p.public idea as analogus to public key encryption. By itself the (unique identity of the frozen) public key object discloses nothing and is not useful. Only if the proxy can access the private name and map from its .public object reference back to the private name can the proxy "decrypt".
I fully understand and agree with this paragraph and I claim that there
is no more security in the additional "mapping" than there is in passing
directly the private name to the proxy.

David


More information about the es-discuss mailing list