5 ms·

That whole E "security model" is a really annoyingly academic endeavour. It's pretty absurd that they managed to push something into the standard only for the g

by j-pb 4y ago

That whole E "security model" is a really annoyingly academic endeavour. It's pretty absurd that they managed to push something into the standard only for the gain of their own obscure consulting company. Nobody else uses it and no library utilizes it, most people haven't even heard of it. Yet it has expensive ramifications for the rest of the language. Proxies for example are super cripled, and extremely hard to use, e.g. to build seamless database integrations (OOM), and super slow, with an added equality checks and whatnot on every access, because they are supposed to also serve as an API gateways within that security framework.

7373737373 4y ago
Internal encapsulation is essential to be able to import and run (partially) untrusted code, to limit its potential side effects, and it has to be implemented in the language itself. How many more decades do you want to wait before programming languages and with them, actual programming practice, become secure? All major languages have failed us in this aspect - and avoiding their shortcomings won't be possible without these primitives. Until people realize this, the world will have to suffer a million hacks that could have been avoided otherwise. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... It does require a different mindset, perhaps even a conceptual inversion to understand and apply the security model, but that doesn't make it purely academic. Yes, it will remain that way if its logical truths are not implemented, but their applications and the consequences of ignoring them are very real. To suggest that they only do it for their own sake is incredibly presumptuous.
- j-pb 4y ago
  I completely agree that we should aim for more secure languages, and I even concede that IF javascript had pervasive use of these (E based) security ideas both in libraries and culture, that it'd be a good thing. However, I'd argue that the security concept introduced by E is at fundamental odds with the reality of javascript programmers. There are other language construct that would have really improved security, such as persistent data structures, good functional programming capabilities that focus on pure functions, even E's actors could be used as isolated execution contexts that communicate via said persistent data-structures. Having just one isolation mechanism, and making it very hard to use wrong, would really address existing security concerns, instead of just throwing a bunch of security primitives that are easy to misuse at a community that neither has the capacity to use them correctly, nor really cares.
  - 7373737373 4y ago
    I agree that hoisting these onto an existing language, especially such a "mutable" one as Javascript is difficult and introduces unfortunate complexity. The intuition (and perhaps hope) that Javascript already has such a large install base and that, once the changes are available in all major browsers, a cultural change is possible through it seems to be the main motivator for them to focus on this language. Even if the syntax of the language cannot be adapted to it, and people won't create constructs themselves with these primitives, there may be a chance that programmers who do not know the fundamental concepts of the theory can still enjoy its security properties by using third party libraries (heh) like SES that provide higher level primitives, e.g. to isolate other imported libraries. I'm still skeptical myself if the focus on Javascript is the right approach, but i'd prefer their intuition to be right on this. Creating a new language will always be cleaner, but adoption is where E failed.
exyi 4y ago
freeze is used quite often (for immutability). Proxies are there for security? It wasn't mentioned in the article and I don't see how it providers security, it only makes things easier to use, right?
- j-pb 4y ago
  Freeze is completely inadequate for immutability, persistent data-structures are really what you want for immutability most of the time, and they give you the nice security properties for free. Most people think of proxies as JavaScripts "method-missing", but that's really not what they are for. They are an isolation primitive to build stuff like membranes [1][2][3]. [1]: https://tvcutsem.github.io/js-membranes https://tvcutsem.github.io/js-membranes [2]: https://tvcutsem.github.io/membranes https://tvcutsem.github.io/membranes [3]: https://www.youtube.com/watch?v=sClk6aB_CPk&ab_channel=JSConf https://www.youtube.com/watch?v=sClk6aB_CPk&ab_channel=JSCon...

by j-pb 4y ago

7373737373 4y ago

Internal encapsulation is essential to be able to import and run (partially) untrusted code, to limit its potential side effects, and it has to be implemented in the language itself. How many more decades do you want to wait before programming languages and with them, actual programming practice, become secure? All major languages have failed us in this aspect - and avoiding their shortcomings won't be possible without these primitives. Until people realize this, the world will have to suffer a million hacks that could have been avoided otherwise. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... It does require a different mindset, perhaps even a conceptual inversion to understand and apply the security model, but that doesn't make it purely academic. Yes, it will remain that way if its logical truths are not implemented, but their applications and the consequences of ignoring them are very real. To suggest that they only do it for their own sake is incredibly presumptuous.

j-pb 4y ago
I completely agree that we should aim for more secure languages, and I even concede that IF javascript had pervasive use of these (E based) security ideas both in libraries and culture, that it'd be a good thing. However, I'd argue that the security concept introduced by E is at fundamental odds with the reality of javascript programmers. There are other language construct that would have really improved security, such as persistent data structures, good functional programming capabilities that focus on pure functions, even E's actors could be used as isolated execution contexts that communicate via said persistent data-structures. Having just one isolation mechanism, and making it very hard to use wrong, would really address existing security concerns, instead of just throwing a bunch of security primitives that are easy to misuse at a community that neither has the capacity to use them correctly, nor really cares.
- 7373737373 4y ago
  I agree that hoisting these onto an existing language, especially such a "mutable" one as Javascript is difficult and introduces unfortunate complexity. The intuition (and perhaps hope) that Javascript already has such a large install base and that, once the changes are available in all major browsers, a cultural change is possible through it seems to be the main motivator for them to focus on this language. Even if the syntax of the language cannot be adapted to it, and people won't create constructs themselves with these primitives, there may be a chance that programmers who do not know the fundamental concepts of the theory can still enjoy its security properties by using third party libraries (heh) like SES that provide higher level primitives, e.g. to isolate other imported libraries. I'm still skeptical myself if the focus on Javascript is the right approach, but i'd prefer their intuition to be right on this. Creating a new language will always be cleaner, but adoption is where E failed.

exyi 4y ago

freeze is used quite often (for immutability). Proxies are there for security? It wasn't mentioned in the article and I don't see how it providers security, it only makes things easier to use, right?

j-pb 4y ago
Freeze is completely inadequate for immutability, persistent data-structures are really what you want for immutability most of the time, and they give you the nice security properties for free. Most people think of proxies as JavaScripts "method-missing", but that's really not what they are for. They are an isolation primitive to build stuff like membranes [1][2][3]. [1]: https://tvcutsem.github.io/js-membranes https://tvcutsem.github.io/js-membranes [2]: https://tvcutsem.github.io/membranes https://tvcutsem.github.io/membranes [3]: https://www.youtube.com/watch?v=sClk6aB_CPk&ab_channel=JSConf https://www.youtube.com/watch?v=sClk6aB_CPk&ab_channel=JSCon...