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

David Bruant bruant.d at gmail.com
Fri Dec 16 12:38:47 PST 2011


My answer is pretty much the same than the previous message

Le 16/12/2011 21:03, David Herman a écrit :
> On Dec 16, 2011, at 11:52 AM, David Bruant wrote:
>
>> However, I have questions and concerns about the public counterpart. 
>> Why does it exists?
> It exists to prevent unintentionally leaking private names. When you have a private name and you do a property get of another object, if that object doesn't know about that private name, it can't do anything with it. With proxies, simply looking up a private name on an object is implicitly giving away access to the object you're doing the lookup on. This means anyone could intercept a private name by handing a proxy to code that's doing a lookup of a private-named key.
Likewise, what prevents you from unintentionally leaking the public ->
private dictionary. You could hand a reference to it to a malicious
party and you would be in equivalent trouble.

>> (there are very few words on it on the wiki and no link to previous discussion) Is it only to "prevents unintended leakage of the private name [to proxies]" as said in the wiki or is there another use case?
> It's critical for protecting the actual privacy of the names.
My understanding of object capabilities is that the only thing that is
critical to protecting a secret is not sharing it. If you're not sure
you trust an object, create a new name, or do whatever it takes to not
share your secret but collaborate with this object. And either this
object needs your secret to collaborate and it's just a malware or it
can do its work without your secret and you probably should choose this way.

I agree that "o[name]" is easier to write than
"o.shareDictionary(mySecretDictionary)", but it does not make it more
dangerous from a security perspective. As I said in the other e-mail, we
can discuss probabilities, likeliness of programmer mistakes, but then,
we've moved away from the object capability field.

David


More information about the es-discuss mailing list