It's only a special way to package executable native code, with limitation of what said code can do. If a bug in the official libraries enable an attacker to steal encryption keys from other apps, this is still going to put your bank's e-banking applet at risk, no matter if said applet runs on an uncrashable Mozilla OdinMonkey VM or the official Oracle JVM.Īnd Google recently developed an efficient sandbox called NaCl, so why not follow them? They could even run Java inside NaCl to add another layer of security. But then you're again running the original java with all the original bugs, only on a different platform. Ant then re-use the opensourced classes from IcedTea and co. The only possible solution, is implementing only the bytecode execution itself (transcode Java bytecode into ASM.js - like pluging GCJ to LLVM to emscripten to odinmonkey, for example). Whereas Gnash only breaks on some stupid casual games and video player for cute kittens (and pr0n), a Java-reimplemented-in-the-browser would probably break business intranets and core business applications.
Given the current market for java (bazillions of inhouse applet in businesses) it is going to be hard to test every case. So you'll end with something as good at running Java as currently Gnash is at running Flash - more or less works broadly on theory, but breaks on lots of specific cases. In practice, Java is a huge pile of complicated mess, and thus lots of applications end-up being highly dependent on Sun/Oracle/IcedTea Java and not run well on any other implementation (like GCJ), mostly because of missing classes or whatever. In theory, it should be possible to create a process which recompiles java byte-code into ASM.js and feeds it into the VM for nearly-native speeds. Not only JIT, but even more so for specially crafted javascript called ASM.js (it standard Javascript, that only use those features which translate nicely into machine code: doesn't use dynamic typing, only uses safe typing, etc.) enabling near-native speed for some code. In fact they already have a VM they use for javascript (the whole -Monkey family), and their VM is even able to compile to native. I guess they can even run javascript inside the same VM, so a unified approach. As a tower defense game addict Flash is just a necessity for a long while still. As long as my bank is not compromised and serving malware through Java vulns that should be ok.Īs for Flash, many people seem to think that HTML5 video support can replace Flash, but then you are not aware of the huge amount of popular Flash games out there.
I have Chrome set up with my bank as only trusted site where the Java applet is activated, for all other sites it is deactivated.
They are working on moving away from it, but for now being able to do online banking is a pretty key requirement for most users. Same Java-based id/login system can be used for many public services and for web shop payments. Most online banking systems in Scandinavia use Java applet. So anyone, please correct me if I'm wrong by providing other examples. Not wanting to speak for the whole world, but at this point, I can't imagine this being a huge problem. In each of those cases, I am very comfortable making those explicit exceptions. Webmin (optional) controls for telnet/ssh and file management. An older HP print server "web interface."Ĥ. Business/Office web based apps (Documentum in my case)ģ. Who does that any more? There are four places where I see that:ġ. Yes, while I tend to agree with that notion, I also have to remind that this is web Java applets we're talking about.
0 kommentar(er)
