July 26, 2012 TC39 Meeting Notes
bruant.d at gmail.com
Thu Aug 2 11:23:02 PDT 2012
2012/8/2 Tom Van Cutsem <tomvc.be at gmail.com>
> 2012/8/2 David Bruant <bruant.d at gmail.com>
>>> To follow-up on that part, here is a gist with the difference between
>> what the current proposal is and the alternative proposal . [...]
>>  https://gist.github.com/**3232772 <https://gist.github.com/3232772>
> Thanks for writing up that gist. Sometimes a piece of code says more than
> a 1000 words ;-)
I had it clear in my mind, but felt my explanations weren't conveying it,
so writing the code sounded like the right solution :-)
> Your proposed alternative is something to consider, although I'm still
> uncomfortable with the WeakMap.prototype.has.bind mechanic.
I have to admit that it's a bit specific as a constraint. The problem is
that for security reasons we can't have isPrivateNameKnown to be any
function, because an attacker would just set a function and wait for it to
be called with the private name. A bound function would guarantee security.
Certainly there are other directions to explore. The goal is to have a
proxy-scoped (in "space") and potentially infinite-scoped (in time) shared
knowledge of what private names a proxy knows. The knowledge is to be
shared with the engine and no one else.
We should also reconsider the simplest alternative of just not trapping
> private names on proxies.
You mentionned that if private names aren't trapped, it pierces membranes,
so when you want to prevent access to objects in the membrane, you can't
for private names.
A softer option in the direction of "not trapping" would be to have a
privateNameSink for known and unknown names. It leaves the opportunity to
not pierce membranes (but I don't know if it's detrimental to other use
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss