Private Slots

David Bruant bruant.d at
Thu Jan 17 01:17:54 PST 2013

Le 17/01/2013 07:16, Kevin Smith a écrit :
>     That's what happens with "private" in Java (I don't think most
>     Java devs think that the Reflect API makes their private
>     attributes actually not private). Java devs could make everything
>     public, they choose not to because the cost of putting "public" is
>     the same as the cost of putting "private" and the benefits are
>     known. In ES5, high integrity privacy has a cost both in code
>     readability and runtime, that's why people don't use it. It's not
>     that they don't need it, it's just that getting to high integrity
>     is annoying.
> First, let's point out that Java's private members are for the most 
> part reflectable, and as such they are more akin to unique symbols 
> than private symbols.
Most Java programs do not use reflection (most of the one's I've read at 
least), so Java's private is as much akin to unique symbols as it is to 
private symbols.

> For OO design purposes at least, we don't need high-integrity privacy.
I don't think the debate is about what people need. Most developers do 
not know or think about what they need. Give them only unique symbols, 
they'll use that. Give them only private symbols, they'll use that.
I'm actually willing to bet that most developers won't understand the 
point of unique symbols, because it's easier to stick to strings to do 
what unique symbols enable. Actually, that's a good question, what's the 
benefit of unique symbols over string properties for OO programming? I 
see the downsides, like you can't use the dot notation or that you 
systematically need an extra variable to use them. But I don't see why 
anyone should bother changing their code to use unique symbols.

In my opinion, the only valid use case for unique symbols is 
collision-free extensions, whether it's for @iterator or libraries 
extending the platform (Array.prototype & friends), why not also jQuery 
The awful-but-widely-used Express plugin could make a good use of unique 
symbols, because its "add properties on the req or res object" 
philosophy really is future-hostile. But in that case too, unique 
symbols wouldn't be used as objects properties (in the OO sense), they'd 
be used as collision-free keys on the req and res "maps".

>     Every project of a decent size needs high-integrity privacy. This
>     shouldn't have a barrier to entry. It should just be what people
>     do by default. Security shouldn't be considered as a luxury left
>     to experts. It should be what naturally comes from writing our code.
> I would be willing to admit that every project needs high-integrity 
> privacy, but not without proof.  Volumes of code have been written for 
> the Node platform, which is inherently low-integrity.  Is the lack of 
> security there a cause for concern among developers?
You said something equivalent to: "volumes of code use eval to parse 
JSON string. Is the lack of security a cause of concern among developers?"
The answer is no, it is not a cause of concern and websites we visit 
daily do that. But that's not a cause of concern until a malicious user 
finds out about the eval and abuses it. Then the cost of the mistake 
becomes absurd by comparison to how much it would have taken to fix it.
It's not a concern... until it becomes one.

I don't think our security should be relying on the fact that no one 
will find out about the leaks in our code. I know a startup who did 
that. Some sort of professional social network. I just had to type 
script elements in messages and it would execute them locally, send them 
to the server, distribute them to anyone I was in touch and execute the 
script in their browser. A carefully crafted script could infect all 
users I could reach after transitive closure.
The lack of security wasn't a concern for these developers apparently, 
but I don't think their concern is relevant. I prefer to think they're 
happy I told them about the issue before someone malicious (a competitor 
who'd want to ruin their reputation?) knew about it and could steal 
every users work and password (needs a bit of additional social 
engineering, but not that hard to achieve).

What we agree on is that developers should not have to worry about 
security. The good thing with private symbols is that they can get their 
job done with a tool that's put them in a secure position *by default*, 
so that they don't need to become experts in security. It's our role as 
people who are experts in security (... well, or at least care about as 
far as I'm concerned) to put the secure easy-to-use tools in the hands 
of people so that they keep not worrying about security.

> Let's take your microwave analogy.  There is a clearly defined danger 
> involved with opening the door while the thing is still running: 
>  you'll end up blasting your face with radiation.  Similarly, we need 
> to clearly define the danger of low-integrity abstractions before we 
> can talk about changing the object model to avoid those dangers.
These dangers are known. Low-integrity abstraction goes against POLA 
(Principle Of Least Authority). That's the root danger. Now, maybe no 
one will abuse the extra authority granted by the language... maybe 
someone will. Maybe you'll use the low-integrity features in ways it 
can't be abused, maybe someone else won't and put themselves in danger. 
Maybe no one will abuse the string concatenation you do to craft SQL 
queries. Maybe someone will.
The danger of running with a knife in my hand is low, but it's bigger 
than running without a knife, so, by default, I choose to run without a 
knife in my hands. I don't actually actively think about and the 
low-danger items I could run around with. I just run, because that's 
what I want to do.
Let's have a by-default knife-free JavaScript. If people want to start 
cutting things, they'll find out where the knifes are.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list