July 26, 2012 TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Thu Aug 2 11:23:02 PDT 2012


2012/8/2 Tom Van Cutsem <tomvc.be at gmail.com>

> [+samth]
>
> 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 [1]. [...]
>>
>> [1] 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
cases)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120802/a1b1752a/attachment-0001.html>


More information about the es-discuss mailing list