unknownPrivateSymbol trap (was: WeakMap better than Private Symbols? (was: direct_proxies "problem"))

David Bruant bruant.d at gmail.com
Thu Jan 10 13:24:26 PST 2013


[Cc'ing Tom and Mark to be sure there is agreement on what I'm claiming 
in this message]

Le 10/01/2013 22:10, Brendan Eich a écrit :
> Nathan Wall wrote:
>>> Brendan Eich:
>>>> No, not if the symbol is not in the whitelist. Zero information 
>>>> leak is
>>>> required.
>>> That's good news too. Objection withdrawn.
>>
>> Maybe I gave up too easy :). Is the `unknownPrivateSymbol` trap 
>> called? What's the rationale for this trap?
>
> I just wrote that the trap is not even called if the symbol is not in 
> the whitelist passed in when the proxy is created.
No, the unknownPrivateSymbol trap is called when the symbol is not in 
the whitelist, so, as Nathan fears, a malicious proxy could throw and 
cancel the access to the private property.

> The rationale was given clearly by Tom Van Cutsem here:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names
Quoting this very page:
"If the private name is not on the whitelist, the proxy calls a new 
unknownPrivateName(target) trap."
(the "new" refers to the fact that without private symbol interaction, 
this trap wouldn't be necessary)

I've recently posted an example of how proxies interact with private 
symbols and the whitelist [1]. That's at least my understanding.

I'd like to take the occasion of this thread-fork to address a point in 
the proxies_names strawman. Quote:
* If the unknownPrivateName trap is not defined, or the trap invocation 
returns true, the operation is forwarded to the target (the handler 
never sees the name).
* If the unknownPrivateName trap returns false, a TypeError is thrown. 
This is useful for proxies that don’t want to forward operations on 
names they don’t know about (membranes probably want to do this)

I think the return true/false protocol should be replaced by a 
return/throw protocol (return value is ignored). It'd be much more 
explicit this way.

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-January/027951.html


More information about the es-discuss mailing list