Security Demands Simplicity (was: Private Slots)

Brendan Eich brendan at
Sun Jan 20 12:40:25 PST 2013

David Bruant wrote:
> Le 20/01/2013 18:59, Brendan Eich a écrit :
>> David Bruant wrote:
>>> I disagree with Brendan when he says "to use weakmaps for class 
>>> private instance methods/variables"... well... it depends on what 
>>> "use" means:
>>> The spec is allowed to /use/ anything it needs to make the class 
>>> private syntax work. If the spec says that private properties are 
>>> like properties but aren't enumerated in Object.gOPN calls, fine. If 
>>> the spec says that private properties require a lookup to some 
>>> object -> value map, fine (but misleading, I agree). 
>> I don't think we disagree.
>> If there were no observable differences at all between weak maps and 
>> private symbols, we would have only one. Since there are, and since 
>> you propose to map private-in-class syntax onto weak maps in part on 
>> account of these differences (viz, proxying and whitelist population 
>> without privacy-leaks), here we are.
> I don't understand, this paragraph went too quickly.
> I understand that you're saying that the proposal I defend (which 
> includes getting rid of private symbols) relies on the differences 
> between private symbols and weakmaps and hence both are necessary?
> Am I fully misunderstanding?

I think you are misreading, and we're going off track. You did not agree 
with my use of "use". I'm not sure why, but my second reply about 
wanting to minimize kernel semantics in the spec, and thereby support 
desugaring/trans-compilation, may shed light on the deeper issue (if 
there is one).

In none of this did I try to make a case for private symbols and weak 
maps. That case has been made but I'm not going to rehash it, and your 
argument predicated on private-in-class for weak maps is a fine argument 
to make (assuming the predicate condition, which is not true for ES6 -- 
no private syntax in class syntax yet!).


More information about the es-discuss mailing list