4 ms·

"In very brief terms: machine code is much faster, but bytecode is more portable and secure." Does anyone else have trouble with that statement? Maybe it shou

"In very brief terms: machine code is much faster, but bytecode is more portable and secure." Does anyone else have trouble with that statement? Maybe it should read "bytecode is more portable and is easier to secure." ? Java is what, 20 years old and based on bytecode and despite Sun/Oracle's efforts still has security problems.

dikei 13y ago
Machine code is over 50 years old and still has security problems.
girvo 13y ago
Java applets, Java is just a language/VM. Applets as an implementation is the issue. But yeah, your main point stands.
pjmlp 13y ago
> Java is what, 20 years old and based on bytecode and despite Sun/Oracle's efforts still has security problems. Sun/Oracle's implementation has security problems. There are lots of Java VMs and compilers to choose from.
- fredsanford 13y ago
  The point is bytecode does not automatically make something more secure as the article, somewhat, implies.
  - pjmlp 13y ago
    In that regard you are right. Although bytecode does simplify validation if you look at all the research work has been done in Assembly validation.
crntaylor 13y ago
I think you need to parse it as more (portable and secure) rather than (more portable) and secure
- anonymfus 13y ago
  portable and securable
perlgeek 13y ago
The interesting part is that most of the bytecode-level security problems in the Java world come from the JIT compilation, where it stops being bytecode again. But yes, bytecode isn't magic pixi dust that makes things secure; it can be a tool to make things more secure though, with effort.
Someone 13y ago
Write a plugin that downloads arbitrary x86 or arm code from the internet and jumps into it, install it on half the world's browsers, and wait a few months. You could say that that new plugin has only one security issue: it downloads code and executes it, but in practice, its security issues will dwarf those of the Java plugin. It's just very hard to build something that can do arbitrary useful stuff at good speed, yet protects you from those attempting to misuse it. Could that be done better? Nowadays, it probably could, as we can afford to run have in a separate process, and add extra layers of code between the JVM and, for example, the DOM, the filesystem, etc.

dikei 13y ago

Machine code is over 50 years old and still has security problems.

girvo 13y ago

Java applets, Java is just a language/VM. Applets as an implementation is the issue. But yeah, your main point stands.

pjmlp 13y ago

> Java is what, 20 years old and based on bytecode and despite Sun/Oracle's efforts still has security problems. Sun/Oracle's implementation has security problems. There are lots of Java VMs and compilers to choose from.

fredsanford 13y ago
The point is bytecode does not automatically make something more secure as the article, somewhat, implies.
- pjmlp 13y ago
  In that regard you are right. Although bytecode does simplify validation if you look at all the research work has been done in Assembly validation.

crntaylor 13y ago

I think you need to parse it as more (portable and secure) rather than (more portable) and secure

anonymfus 13y ago
portable and securable

perlgeek 13y ago

The interesting part is that most of the bytecode-level security problems in the Java world come from the JIT compilation, where it stops being bytecode again. But yes, bytecode isn't magic pixi dust that makes things secure; it can be a tool to make things more secure though, with effort.

Someone 13y ago

Write a plugin that downloads arbitrary x86 or arm code from the internet and jumps into it, install it on half the world's browsers, and wait a few months. You could say that that new plugin has only one security issue: it downloads code and executes it, but in practice, its security issues will dwarf those of the Java plugin. It's just very hard to build something that can do arbitrary useful stuff at good speed, yet protects you from those attempting to misuse it. Could that be done better? Nowadays, it probably could, as we can afford to run have in a separate process, and add extra layers of code between the JVM and, for example, the DOM, the filesystem, etc.