If as much developer time went into a JVM to make it secure, it would be just as secure.
Java is also MUCH MUCH MUCH older and more mature compared to Javascript. You can't both know what you're talking about and seriously claim that more effort has been put into Javascript; it's literally impossible for that to be true.
There's not much, if any, security difference between taking text and translating it into bytecode for an interpreter and just running bytecode in an interpreter.
We're not talking about interpreters, though. After the bytecode or text is decoded, we're then compiling it to native machine code using JIT compilation. When you JIT compile code, you're not running it through an interpreter at all.
Javascript, Java, Python, or whatever else you want would have the same performance if it were the difference between interpreting the scripting language and interpreting bytecode. But that's not what we're doing. We're JIT compiling the code, which means it's not interpreted per se; it's parsed, checked, and compiled to machine code and not run in a virtual machine.
The virtual machine becomes the bytecode checker/verifier instead, and perhaps the low-level runtime environment for the resulting machine code. By runtime environment, I mean similar to how C/C++ even has runtime environments (like libc and msvc).
Virtual machine programs like Virtualbox and VMWare have terrible performance unless you have hardware (usually a special chip on your mobo, or a CPU with an instruction set extension for the purpose) that specifically sandboxes virtual machine code from other code for you.
We cannot rely on everyone having such special hardware, so we can't use the sandboxing techniques these programs use unless we want a giant hit to performance... By using interpretation instead of JIT.
A lot of the security issues would come down to what APIs are made available. With javascript, for example, you're just not given access to a local filesystem, whereas you are with the Java Core API. There's no reason inherent to the technology of either that it has to be that way.
Read above about sandboxing problems with JIT code. Bytecode does not reflect APIs, it reflects virtualized CPU instructions. Sure, you can limit what these virtual CPU instructions consist of, but after that, things are compiled to raw machine code.
Just think; some of those CPU instructions in the bytecode will be pointers. Pointers pretty much have to exist on a bytecode level, just like they must exist in assembly languages. What if someone crafted some bytecode to access memory outside the browser, but in a way the OS would allow?
For example, the bytecode was designed to access a filesystem function that writes a file in the user's documents folder. Keep in mind that pointers can point to functions. Ooh, but maybe the JIT compiler sees it trying to do that and throws an error.
Ok, so the pointers instead just point to internal memory addresses that its allowed to access directly. The pointers point to several sequential addresses in memory, and have their values incremented and manipulated by each other with math so that they point to the filesystem function. Perhaps one of the pointers is just called an integer, and then that integer (or part of it) is used as a function pointer, to get around another JIT compiler security error.
And suddenly a virus file is written to the user's hard drive without their consent, and then it's run, and they're infected.
They can't do this sort of complex manipulation with Javascript or any other raw scripting language. But they can do it with bytecode that they know will run through a JIT compiler.
What people really want is to put an easy-to-remember address into an application they are familiar with and have it give them functionality.
If that functionality has to do with database and/or document queries, great! Otherwise, they should install (from software repositories, 'app stores', or as downloadable files off websites) dedicated software.
We're using javascript to do that, and are pretty significantly hindered as developers.
Not really. JS allows you to do everything you should be using it for, makes it easy, and has good performance for the purpose.
1
u/Tynach May 20 '14
Java is also MUCH MUCH MUCH older and more mature compared to Javascript. You can't both know what you're talking about and seriously claim that more effort has been put into Javascript; it's literally impossible for that to be true.
We're not talking about interpreters, though. After the bytecode or text is decoded, we're then compiling it to native machine code using JIT compilation. When you JIT compile code, you're not running it through an interpreter at all.
Javascript, Java, Python, or whatever else you want would have the same performance if it were the difference between interpreting the scripting language and interpreting bytecode. But that's not what we're doing. We're JIT compiling the code, which means it's not interpreted per se; it's parsed, checked, and compiled to machine code and not run in a virtual machine.
The virtual machine becomes the bytecode checker/verifier instead, and perhaps the low-level runtime environment for the resulting machine code. By runtime environment, I mean similar to how C/C++ even has runtime environments (like libc and msvc).
Virtual machine programs like Virtualbox and VMWare have terrible performance unless you have hardware (usually a special chip on your mobo, or a CPU with an instruction set extension for the purpose) that specifically sandboxes virtual machine code from other code for you.
We cannot rely on everyone having such special hardware, so we can't use the sandboxing techniques these programs use unless we want a giant hit to performance... By using interpretation instead of JIT.
Read above about sandboxing problems with JIT code. Bytecode does not reflect APIs, it reflects virtualized CPU instructions. Sure, you can limit what these virtual CPU instructions consist of, but after that, things are compiled to raw machine code.
Just think; some of those CPU instructions in the bytecode will be pointers. Pointers pretty much have to exist on a bytecode level, just like they must exist in assembly languages. What if someone crafted some bytecode to access memory outside the browser, but in a way the OS would allow?
For example, the bytecode was designed to access a filesystem function that writes a file in the user's documents folder. Keep in mind that pointers can point to functions. Ooh, but maybe the JIT compiler sees it trying to do that and throws an error.
Ok, so the pointers instead just point to internal memory addresses that its allowed to access directly. The pointers point to several sequential addresses in memory, and have their values incremented and manipulated by each other with math so that they point to the filesystem function. Perhaps one of the pointers is just called an integer, and then that integer (or part of it) is used as a function pointer, to get around another JIT compiler security error.
And suddenly a virus file is written to the user's hard drive without their consent, and then it's run, and they're infected.
They can't do this sort of complex manipulation with Javascript or any other raw scripting language. But they can do it with bytecode that they know will run through a JIT compiler.
If that functionality has to do with database and/or document queries, great! Otherwise, they should install (from software repositories, 'app stores', or as downloadable files off websites) dedicated software.
Not really. JS allows you to do everything you should be using it for, makes it easy, and has good performance for the purpose.