3 ms·

I am not referring to archive.org as insecure, I am referring to JS as insecure. And it is. Look at the percentage of exploits for FF or Chrome that require JS

I am not referring to archive.org as insecure, I am referring to JS as insecure. And it is. Look at the percentage of exploits for FF or Chrome that require JS and/or are in their JS engines. Trying to write a language that is compiled / JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure. Look at Java. Look at Flash, look at JS.

simoncion 11y ago
I dunno man. Unless you can give me a good technical reason [0] why the presence of a JIT compiler is bound to decrease the security of a project, I'm going to present the Erlang VM [1] as an example of a secure, powerful VM that targets a powerful, compiled language with quick execution. [0] "JITs are not exactly easy." is not a good technical reason. There are many hard problems that have secure solutions. [1] Known as BEAM
- TheLoneWolfling 11y ago
  First off, kindly reread what I actually said, as opposed to what you skimmed :) Secondly, now that you have actually done that, you'll note I did not said JITters are inherently insecure. I said that "Trying to write a language that is compiled / JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure". And the reason is simple. By the time you take a powerful language and add the optimizations necessary to make it be executed quickly, your execution engine becomes complex. (For instance, the v8 engine is, what, 1.4 million lines of code? And the SpiderMonkey engine is over half a million?) And because you need the engine to compile / JIT quickly, you end up writing code that takes advantage of "bare-metal" features. And as such, you have a nasty combination of an absurd amount of code, most of which is "unsafe" (to use the Rust parlance). And from there, simple probability dictates that you will have bugs, and you will have exploitable bugs. Now, is this inherent to JS engines? No. You could, in theory, have a JS engine written in a language that checks the code for you. As you said, Erlang, or whatever. However, that is a moot point. Because there is not a single functional browser that uses a JITter that doesn't have these problems. And as such, here's a good reason, albeit not a technical one: precedent. I am not so... hubristic, shall I say, to assume that even though every current major browser has a large chunk, if not the majority, of exploitable bugs be in the JS engine, that the next one will be any different. I can hope, but I will not rely on it. Especially not as I am talking about now, not some potentially-mythical time in the future. And no, I cannot give you a technical reason. Because I suspect that the moment anyone figures out said technical reason, they will be able to design a language and/or engine that doesn't have said reason.
  - simoncion 11y ago
    I read all five sentences and the single sentence fragment in your statement several times before replying. :) If your thesis is "Complex and/or difficult software is hard to get right.", I agree with it. I don't think any experienced programmer would disagree with it. If your thesis is -as it appears to be- "Complex and/or difficult software is impossible to get right.", I cannot agree with it. It is often difficult and time consuming to create correct complex software, but far from impossible.
    - TheLoneWolfling 11y ago
      Complex software is possible to get right in the same sense that it is possible for all the O2 molecules in this room to move to the other side of this room at the same time. It is technically possible, but improbable enough that, in the absence of direct evidence to the contrary (in this case, a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine), it may as well not be.
      - simoncion 11y ago
        Like I said, correct complex software is almost always going to be expensive as fuck. Unless you're doing interesting work, you're unlikely to run into examples of such software. Because noone _directly_ makes millions of dollars per month from V8, there's no business reason to expend the effort required to make V8 bulletproof. Is the software for an ATM switch that contains more than a million lines of code, runs uninterrupted for twenty years straight, and scales from 10gbit to 160gbit sufficiently complex for you?
        TheLoneWolfling 11y ago
        Considering that is not what I was asking for (I quote, "a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine"), it, although impressive in its own right, is irrelevant. (Not to mention that said software isn't available for public scrutiny, and as such I have to take the assertion that it is bulletproof with a grain of salt. I mean, even NASA has had braindead-stupid moments (failing to convert units properly? A casting error? Running out of space on the filesystem?)))

simoncion 11y ago

I dunno man. Unless you can give me a good technical reason [0] why the presence of a JIT compiler is bound to decrease the security of a project, I'm going to present the Erlang VM [1] as an example of a secure, powerful VM that targets a powerful, compiled language with quick execution. [0] "JITs are not exactly easy." is not a good technical reason. There are many hard problems that have secure solutions. [1] Known as BEAM

TheLoneWolfling 11y ago
First off, kindly reread what I actually said, as opposed to what you skimmed :) Secondly, now that you have actually done that, you'll note I did not said JITters are inherently insecure. I said that "Trying to write a language that is compiled / JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure". And the reason is simple. By the time you take a powerful language and add the optimizations necessary to make it be executed quickly, your execution engine becomes complex. (For instance, the v8 engine is, what, 1.4 million lines of code? And the SpiderMonkey engine is over half a million?) And because you need the engine to compile / JIT quickly, you end up writing code that takes advantage of "bare-metal" features. And as such, you have a nasty combination of an absurd amount of code, most of which is "unsafe" (to use the Rust parlance). And from there, simple probability dictates that you will have bugs, and you will have exploitable bugs. Now, is this inherent to JS engines? No. You could, in theory, have a JS engine written in a language that checks the code for you. As you said, Erlang, or whatever. However, that is a moot point. Because there is not a single functional browser that uses a JITter that doesn't have these problems. And as such, here's a good reason, albeit not a technical one: precedent. I am not so... hubristic, shall I say, to assume that even though every current major browser has a large chunk, if not the majority, of exploitable bugs be in the JS engine, that the next one will be any different. I can hope, but I will not rely on it. Especially not as I am talking about now, not some potentially-mythical time in the future. And no, I cannot give you a technical reason. Because I suspect that the moment anyone figures out said technical reason, they will be able to design a language and/or engine that doesn't have said reason.
- simoncion 11y ago
  I read all five sentences and the single sentence fragment in your statement several times before replying. :) If your thesis is "Complex and/or difficult software is hard to get right.", I agree with it. I don't think any experienced programmer would disagree with it. If your thesis is -as it appears to be- "Complex and/or difficult software is impossible to get right.", I cannot agree with it. It is often difficult and time consuming to create correct complex software, but far from impossible.
  - TheLoneWolfling 11y ago
    Complex software is possible to get right in the same sense that it is possible for all the O2 molecules in this room to move to the other side of this room at the same time. It is technically possible, but improbable enough that, in the absence of direct evidence to the contrary (in this case, a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine), it may as well not be.
    - simoncion 11y ago
      Like I said, correct complex software is almost always going to be expensive as fuck. Unless you're doing interesting work, you're unlikely to run into examples of such software. Because noone _directly_ makes millions of dollars per month from V8, there's no business reason to expend the effort required to make V8 bulletproof. Is the software for an ATM switch that contains more than a million lines of code, runs uninterrupted for twenty years straight, and scales from 10gbit to 160gbit sufficiently complex for you?
      - TheLoneWolfling 11y ago
        Considering that is not what I was asking for (I quote, "a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine"), it, although impressive in its own right, is irrelevant. (Not to mention that said software isn't available for public scrutiny, and as such I have to take the assertion that it is bulletproof with a grain of salt. I mean, even NASA has had braindead-stupid moments (failing to convert units properly? A casting error? Running out of space on the filesystem?)))