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

Tom Van Cutsem at
Mon Dec 19 02:03:35 PST 2011

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

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 something?

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.


2011/12/17 David Bruant <bruant.d at>

> Le 17/12/2011 22:37, David Herman a écrit :
> > On Dec 17, 2011, at 4:04 AM, David Bruant wrote:
> >> I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy.
> > This is just a non-starter. Then you can't use private names as private
> names.
> I have read a lot of code that I have written myself and I admit that if
> I wanted to switch to private names, I would make myself vulnerable to
> the attacks mentionned and would be required to use closures anyway, so
> as you say, I wouldn't be able to use private names as private names.
> >> (One good news is that mostly static analysis
> >> can assist us in finding where we may disclose 'n' in this scenario).
> > When you say "static analysis can solve this" you're saying "some
> hypothetical approximation to an undecidable problem will find out all the
> places where the unstated and unwritten intentions of the programmer were
> violated. Also, despite the fact that it's mathematically impossible for
> such a tool to have both no false positives and no false negatives, it will
> still be both safe and useful." I'll believe it when I see it?
> I was careful to say "assist" and not "solve".
> > Besides, we shouldn't knowingly add features that will invite bugs that
> can only be found with (as yet unspecified and non-existent) additional
> development tools.
> I agree.
> >>> And there's no way you can fix
> >>> this, without resorting to some other method of hiding things like
> >>> closures.
> >> I disagree, there is.
> >> In the case where you want the proxy ("worst case", here "proxy" means
> >> "untrusted third party") to have access to the private name, you need
> >> the proxy to have access to a public->private map.
> > You seem to be treating ES6 as being The Ultimate Proxy Language (with
> some additional side features).
> I do not. I'm aware that proxies have benefits and positive things can
> get out of them. As it turns out, they are heavily used in Firefox as
> well from what I heard. It would be interesting to hear from the people
> who have experience with them to know how they feel about private names
> and the ".public"
> > Proxies are not the common use case we are optimizing for, nor should
> they be.
> >
> > The common case we are optimizing for has nothing to do with proxies.
> It's simple stuff like:
> >
> >     let n = Name();
> >     function Stuff() {
> >         this[n] = /* some internal stuff */;
> >     }
> >     Stuff.prototype = {
> >         doStuff: function() {
> >             ... this[n] ...
> >         }
> >     };
> >
> >> If each time I create an abstraction using proxies, I need a
> >> public->private map, it is likely that I (and it's obviously not about
> >> "me", but anyone writing proxies) won't use private names with proxies.
> >> I may just use WeakMaps.
> > Great -- do that! If proxy writers have to work harder to deal with the
> public/private map, so be it! I would much rather tax proxy writers than
> tax everyone else. As cool as proxies are, they are not intended to be
> nearly as common as the usual simple functions + prototypes abstractions of
> JS.
> Have you had a look at my alternative proposal [1]? It seems to solve
> all concerns raised by anyone (including me) in this thread.
> David
> [1]
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list