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
"plugins".
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
