Le 15/01/2013 17:16, Kevin Smith a écrit :
The variable was called "s" standing for secret. The example I
gave was dummy, but examples in the wild are legion. Take your
favorite node library. Anytime it defines a _property, this is
where there should be a private name.
Again, that's arguable. Certainly it would be better expressed with a
symbol. But private? Are most node authors attempting to write
"secure" code? Of course not!
People writing Java code do use the private keyword. I think if
encapsulation wasn't that hard to achieve, people would do it. I'm
looking forward to see people use classes and modules without putting
more effort that they do currently and yet write more secure code by
default.
Node (by itself) does not provide a secure environment for untrusted code.
What I know of Node makes me think it's not that much worse than any
other platform and from experience, at least much better than anything
I've played wit in PHP.
One of the goal was that no one had access to the "s" part of the
state. You need private symbols for that.
But why? Where is this strict runtime privacy requirement coming
from? What I'm not understanding is the larger context in which
mutually untrusting code supposedly shares raw (non-proxied) objects.
The reason you can't write code in any blog comment these days is that
people have given up on securing untrusted code. Likewise for emails.
HTML is used for emails, but scripts aren't executed, because email
client (web-based or not) have given up on the idea of securing email code.
Where is the real world code doing this?
I think iGoogle does this. Otherwise, close to nowhere because people
have given up.
My guess is that they have given up because the language does not make
easy to sandbox untrusted code. As soon as you have naturally written
your code in JavaScript, it's unsafe and it takes a lot of work making
it safe. People give up. Private symbols are one tool to lower the
barrier to writing code secure by default.
For what applications? Really, I want to know! : )
They do not exist unfortunately. That's a chicken and egg problem. As
soon as it'll be easier, people will probably restart thinking of what
they want to do with the new tool they have in hand.
That's what happened when JS engines got faster. Developers didn't stay
still happy that their websites just got faster. Websites just started
to get more and more JS.
In "Crockfordian" design, "name encapsulation" and "security
encapsulation" are indistinguishable. But unique symbols address
"name encapsulation". Is there really a need to address "security
encapsulation" at the *object property level*?
It seems that it lowers the barrier to writing secure code by default.
If that's the only thing to gain, I'll take it.
Thinking more about the loading third-party code, I guess it's
technically doable to do without private names. It comes to the
cost of creating proxies doing the encapsulation for you. You
provide a blacklist of properties that must not be reflected and
the third party never sees them... In essence, you're listing the
private properties and the proxy does the book keeping (details
about non-configurability aside).
Sure - and approaches like this (or simpler - people are clever!) can
be factored away into a neat library, without having to mess with the
underlying object model.
ES6 provides WeakMaps and Proxies. Why not see what people do with
those before introducing private slots?
I wouldn't be opposed to that, but that's just my opinion. Still,
private symbols allow property-like syntax. I haven't followed the
latest developments of how classes and private symbols interact, but I'm
not too worried it goes well. Assuming it does, it makes it easy for
people to use actually private properties in their code, lowering the
barrier to writing well-encapsulated code.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
