Security Demands Simplicity (was: Private Slots)

Mark S. Miller erights at
Thu Jan 17 14:24:11 PST 2013

On Thu, Jan 17, 2013 at 1:50 PM, Mark S. Miller <erights at> wrote:
> On Thu, Jan 17, 2013 at 1:13 PM, David Bruant <bruant.d at> wrote:
>> Le 17/01/2013 19:30, Mark S. Miller a écrit :
>>> 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 don't know, but seems down for me too. But the classes accepted for
> ES6 are "maximally minimal" and contain no field declarations of any
> kind.

Back up. Maximin is at

>> 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?
> Correct.
>>> 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?
> I believe you are. For abstractions with small numbers of methods and
> no interesting inheritance, I find the objects-as-closures pattern +
> weakmaps for class-private instance variables, as in our recent paper,
> to be more pleasant than the likely ES7 class syntax anyway; and much
> simpler to understand. And it's way more pleasant than the maximin
> classes accepted for ES6. We will see a lot of code manually using
> WeakMaps in this way.
>> David
>> [1]
> --
>     Cheers,
>     --MarkM


More information about the es-discuss mailing list