Are Private name and Weak Map the same feature? and the Assoc API
bruant.d at gmail.com
Mon Dec 19 04:52:59 PST 2011
Le 19/12/2011 11:03, Tom Van Cutsem a écrit :
> With the new direct proxies API, there is potentially another solution
> to combining proxies with private names:
> private name property get/set could bypass the proxy entirely and be
> forwarded unconditionally to the target, just like |typeof|,
> |Object.getPrototypeOf| and [[Class]].
> - no leakage of private names, no need for .public conversion
> - works when composing proxies
> - proxies can no longer intercept private names even if they were
> allowed to
If private name bypass the proxy entirely, what will we have to invent
to intercept private names? ;-)
There are use cases for intercepting private names (either directly or
> Independent of the above, this discussion does lead me to think that
> we should at least consider separate traps for getting/setting private
> names. The current proposal abuses the name parameter of the get trap
> (of type String) to encode private names. But can an implementation
> guarantee that ToString(privateName.public) does not correspond to any
> other user-generated String? If not, there is potential for confusion.
> Separate getPrivate/setPrivate traps would avoid this confusion:
> var n = Name();
> proxy[n] // triggers handler.getPrivate(target, n.public);
> proxy[n.public] // triggers handler.get(target, ToString(n.public));
> Under the current proposal, both of the above would trigger the get
> trap. I think this could actually confuse a proxy that has a
> public->private mapping for n to _disclose_ the private name value to
> an attacker that was able to forge the string ToString(n.public). The
> attacker simply has to call proxy[forgedPublicName]. Am I missing
The public part is an unforgeable object (with the same .toString than
the private name), so there is no ambiguity in a public->private map.
You use the unforgeable public object as key in the map, so no collision
issue due to string forgeability.
> In any case, by separating private name access out into separate
> traps, if a proxy writer only implements get/set but not
> getPrivate/setPrivate, then private name access would just be
> forwarded to the proxy target by default, and there would be no need
> for the proxy to maintain a public->private mapping for private names
> it does not know or care about.
If you define a getPrivate/setPrivate trap, does it have access to the
private name directly or its public counterpart? In the former case,
passed directly) and the stealth threat remains, in the latter case, I'm
not sure I see the benefit over the current design.
More information about the es-discuss