Security Demands Simplicity (was: Private Slots)

Brendan Eich brendan at mozilla.com
Sun Jan 20 18:35:16 PST 2013


David Bruant wrote:
> Le 20/01/2013 21:53, Brendan Eich a écrit :
>> Allen Wirfs-Brock wrote:
>>> We we were going to talk about adding support for addition semantics 
>>> to  classes we should start at the level of the object model.  Not 
>>> with syntax. ES6 class syntax is good because it is defined in terms 
>>> of the object model and more basic operations that are defined in 
>>> the language.  You don't have to use class syntax to define a class 
>>> equivalent. So, if we are going to introduce private object state 
>>> the first step is to define how it works at the object model level.
>>
>> Cutting there to dodge the controversy over private-in-class based on 
>> weak maps, to divide and conquer in the meta-discussion with David.
>>
>> Here I agree with you, and we have talked in the past of the perils 
>> of "Scenario Solving" by adding just-so syntax with novel semantics, 
>> which is not decomposed into orthogonal primitives. You saw that in a 
>> past life (VB5, cough) and it made messes, even though the intentions 
>> (serving developer problem-scenarios) were good.
> I'm too new to the programming language world, so I don't have this 
> context, but I'm curious. Do you have links or further explanations on 
> this topic?

Take the Scheme Report intro paragraph, for example:

"Programming languages should be designed not by piling feature on top 
of feature, but by removing the weaknesses and restrictions that make 
additional features appear necessary. Scheme demonstrates that a very 
small number of rules for forming expressions, with no restrictions on 
how they are composed, suffice to form a practical and efficient 
programming language that is flexible enough to support most of the 
major programming paradigms in use today. "

Contrast with a language such as VB in the context of MS COM:

http://www.roblocher.com/whitepapers/oletypes.aspx

I recall Allen mentioning mutable value types (!), multiple array and 
date types, and a rising tide of non-compositional types and features.

If we make class-with-private-syntax bespoke and custom, we raise the 
risk of creating some spec-internal new semantics (extending the ES5 
kernel). Besides the loss of ability to mix-and-match functions and 
objects using APIs, as Allen noted, all else equal the odds of loss of 
compositionality go up.

You're right to stress, as Tom and Mark have from the start, that 
private symbols must not pierce membranes (or else a side channel hazard 
exists). That risk exists with bespoke (internal-weakmap-based) 
private-in-class syntax and semantics too. There's no free lunch. Yes, 
weak maps inside the spec avoid this hazard, but they could leak through 
the spec abstraction -- and even if they don't, the lack of 
property-in-object-named-by-private-symbol leaks.

We should stick to the minimize-kernel-semantics plan, and take the 
Scheme Report's intro to heart.

/be
>
> Thanks,
>
> David
>


More information about the es-discuss mailing list