Security Demands Simplicity (was: Private Slots)

David Bruant bruant.d at gmail.com
Thu Jan 17 13:13:49 PST 2013


Le 17/01/2013 19:30, Mark S. Miller a écrit :
> On Thu, Jan 17, 2013 at 10:02 AM, David Bruant <bruant.d at gmail.com> wrote:
>> Le 17/01/2013 18:00, Mark S. Miller a écrit :
>>> I still have this position on classes. But I no longer buy that
>>> pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
>>> used by the expansion of classes-with-private. Just 'cause it's on the
>>> top of my head, below I use the old representation of one WeakMap per
>>> class providing access to a record of all the private state. For the
>>> same reason, I'll use the encapsulation of the Purse example without
>>> any of the numeric checks.
>>>
>>> class Purse {
>>>       constructor(private balance) {
>>>       getBalance() { return balance; }
>>>       makePurse() { return Purse(0); }
>>>       deposit(amount, srcPurse) {
>>>           private(srcPurse).balance -= amount;
>>>           balance += amount;
>>>       }
>>> }
>>>
>>> expansion
>> I don't understand the need to expand. This is the class syntax. It creates
>> a constructor. Instances of this constructor have some behavior and
>> characteristics described by the class body. If the class body allows to
>> define something private, implementors will implement that and work very
>> hard on performance. I don't think implementors will expand before compiling
>> and using the class syntax as some sort of macro (implementors are free to
>> tell I'm wrong here).
>> Assuming I'm right, what it expands to exactly does not matter much, whether
>> it's private name or weakmaps or whatever else.
> Regarding what I actually said, you're right. I am being unbelievable
> confusing this morning. After that sleepless night, I should probably
> wait till I'm rested before posting again. Foolishly perhaps, I'll try
> to answer anyway.
>
>
> 1) It remains useful to define the semantics of classes by expansion.
> Then one can reason about classes by reasoning about the expansion.
> This is especially helpful for automated tools. The semantics had then
> better be faithful to the explanatory expansion.
>
> 2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1] (is 
the wiki down? I'm looking at google's cache), I see that syntax for 
private properties is in the proposal and nothing suggests it's postpone 
until ES7. I see in recent notes that the @-syntax isn't fully agreed 
upon, but that's where I'm at. Is there no private syntax at all for 
classes in ES6?

> there will be transpilers that provide actual privacy by other means.
What syntax and semantics will these transpilers use if TC39 doesn't 
reach an agreement?

> 3) Most important, and most unsaid by my previous email: In ES6, since
> there's no built-in class/object privacy mechanism, ES6 programmers in
> general and ES6 class programmers specifically have to achieve real
> privacy by other means -- by engaging in some pattern using other
> constructs. Previous conversations assumed that these patterns would
> be expressed in terms of private symbols. Absent private symbols, the
> pattern shown by my expansion above, as painful as it is, is what will
> be expressed manually. By the time ES7 rolls out, there will be a lot
> of that code.
People who care will use a transpiler (and I personally don't care if 
the generated code is slightly slower than what it could be natively or 
ugly). People who don't care about privacy will go on with their lives 
writing JavaScript as they do in ES5.
That's an ephemeral problem in my opinion and isn't the "most important" 
point. Am I underestimating it?

David

[1] http://wiki.ecmascript.org/doku.php?id=harmony:classes


More information about the es-discuss mailing list