Whitelist WeakSet

[Waldemar Horwat]

On 09/24/2012 01:24 AM, David Bruant wrote:
> Le 24/09/2012 10:04, Tom Van Cutsem a écrit :
>> 2012/9/24 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>>
>>     Le 23/09/2012 22:04, Herby Vojčík a écrit :
>>     > Hello,
>>     >
>>     > maybe I missed something, but how will you secure the whitelist
>>     > itself? Malicious proxy knowing righteous one can steal its whitelist,
>>     > afaict.
>>     I'm sorry, I don't understand what you're saying here. Can you be more
>>     specific and provide an example of an attack?
>>
>>     As far as I'm concerned, I consider the design secure, because it's
>>     possible to easily write code so that only a proxy (or it's handler to
>>     be more accurate) has access to its whitelist and nothing else.
>>
>>
>> Right. Perhaps what Herby meant is that the proxy might provide a malicious whitelist to steal the names being looked up in them. This will be prevented by requiring the whitelist to be a genuine, built-in WeakSet. The proxy will use the built-in WeakSet.prototype.get method to lookup a name in that whitelist, so a proxy can't monkey-patch that method to steal the name either.
> True. I think a lot of that part depends on how WeakSet/Set are spec'ed. It might be possible to accept proxies wrapping WeakSets (which is likely to be helpful with membranes) and perform the check on the target directly, bypassing the proxy traps. Or maybe consider the built-in WeakSet.prototype.get method as a private named method on the weakset instance and only call the unknownPrivateName trap.

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?

     Waldemar