Whitelist WeakSet

Tom Van Cutsem tomvc.be at gmail.com
Mon Sep 24 22:49:59 PDT 2012

2012/9/25 Waldemar Horwat <waldemar at google.com>
> Yes.  This was bothering me during the meeting and (as far as I know)
> didn't get resolved.  What if someone passes in a proxy to a WeakSet
> instead of an actual WeakSet?
> A.  Allowed.  Then the security protocol is utterly broken.
> B.  Disallowed.  Now we have a class that can't be proxied.
> Neither sounds good.  What am I missing?

I intended option B. The whitelist can't be proxied.

It's not that WeakSets can't be proxied in general (they can), but for the
specific use of a WeakSet as a whitelist, the proxy needs a genuine
WeakSet. This isn't all that different from DOM methods requiring genuine
DOM elements, etc.

I also don't see how membranes would require proxied whitelists: it would
be weird to construct a Proxy whose whitelist must be a membraned object. I
think of a newborn Proxy and its whitelist as being part of the same
abstraction. It makes little sense to separate them by a membrane.

I previously mentioned the alternative of making the WeakSet entirely
hidden and introducing two built-in methods to manipulate them
(Proxy.addName(proxy, name) and Proxy.removeName(proxy, name)). Then the
problem of proxied whitelists goes away, but it precludes easy sharing of
the same whitelist among multiple proxies, which seems like a reasonable
thing to do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120925/dc1b12e3/attachment.html>

More information about the es-discuss mailing list