We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS: - direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fin…
Out of curiousity, why did it have to run in the browser?
Why not? - "we did not want to write a desktop app just for these features"
Let's say this update does everything advertised and more, the perception remains that Java is just not usable in the browser--it's just too dangerous. Away from testing purposes, the only reason we use IE in the office is so that we can use Webex without Java.
So you rather use the ActiveX plugin instead?! Talk about security.
Is ActiveX more dangerous than Java applets? If so, that's news to me, but I'm all ears.
So now all applets will have to be signed, and users will be trained to accept running the signed applets with that horrible GUI for confirming it. Did you know that popup about running a signed applet also confirms you're OK with running the applet outside the sandbox? So from now on, all applets will by default run outside the sandbox? How is this an improvement?
It's an improvement because all applets will by default not run at all , and most users don't need to use any applets and thus will not in fact be trained to agree to run applets. Basically, it acknowledges that the Java sandbox is as leaky as a sieve and that securitywide, running an applet not much different from downloading and running a regular executable file, so you should only do it if you trust the source.
It's a shame if poorly written applets end up being signed cluelessly.
At least the sandbox used to prevent accidents, if not malicious code. Plenty of things like "lights-out" server admin tools seem to ship with semi-dodgy applets for KVM stuff etc.
We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS: - direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fin…
Why not an HTTP server running on localhost that provides these things?
We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS: - direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fin…
Why not an HTTP server running on localhost that provides these things?
Yes, we thought of that too, but the installation of the server on every client was a lot more work than writing an applet. But it was a valid alternative if the clients using the app where few.
Let's say this update does everything advertised and more, the perception remains that Java is just not usable in the browser--it's just too dangerous. Away from testing purposes, the only reason we use IE in the office is so that we can use Webex without Java.
I think bromium.com includes a hw-virtualization option that enables one to use java in the browser safely.
I agree, it's a local exploit, not a remote exploit (I've debated this with people as well), but in the end Java sandbox bypass exploits are (or were) the most effective local exploit possible. And they're arguably far more valuable than the vast majority of remote exploits out there. Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of peopl…
An interesting aspect of the whole Java pluigin fiasco is that, as you write, there were very few exploits until a couple of years ago - but the plugin was widely deployed for over a decade before that, and there is no reason to believe that it was somehow more secure before. So why the recent increase?
Could be a combination of many factors, but probably in part due to security researchers and black hats alike truly realizing the potential damage Java sandbox exploits could cause, in comparison to exploits for Flash or Adobe Reader, which are much more fickle, not cross platform, etc.