5 ms·

I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.

geofft 11y ago
The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance. Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine. And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does. (To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)
- mike_hearn 11y ago
  The Java plugin's mistake was to have a crap auto update mechanism, and be politically unpopular because it wasn't open source. That's it. Both Firefox and Chrome ship massive numbers of security fixes with a high degree of regularity, but nobody cares, because: 1) It's the web, and The Web is close to religion for many people. 2) Their auto update mechanisms are pretty good, for Chrome, best in class, so people get the bug fixes. The JVM sandboxing mechanism itself isn't the issue. The design is sound. All sandboxes have escapes especially where native code is concerned, and JavaScript sandboxes have proven no different in this respect. The issue boils down to auto update (lack of).

The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance. Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine. And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does. (To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)

mike_hearn 11y ago
The Java plugin's mistake was to have a crap auto update mechanism, and be politically unpopular because it wasn't open source. That's it. Both Firefox and Chrome ship massive numbers of security fixes with a high degree of regularity, but nobody cares, because: 1) It's the web, and The Web is close to religion for many people. 2) Their auto update mechanisms are pretty good, for Chrome, best in class, so people get the bug fixes. The JVM sandboxing mechanism itself isn't the issue. The design is sound. All sandboxes have escapes especially where native code is concerned, and JavaScript sandboxes have proven no different in this respect. The issue boils down to auto update (lack of).