Looks like there are plans to block all Java Applets on Mozilla Browsers in order to protect users against the BEAST attacks.
I’m sad for those who use applets 
I hope Mozilla won’t do this. I assume Java Web Start is not concerned.
From what I’ve read so far, it seems like a poor attempt on Mozilla’s part to pin a mainly JavaScript and wrong policy setting problem on Java. Chrome for example fixed the issue without any change to the Java Plugin.
Somebody’d better write and tell’ em then 
I couldn’t care less though. Applets are still utter shit, even now.
Cas
I can’t remember where, but I’m pretty sure it was on here, that I said Applets are blocked in Chrome, and will probably be blocked in Firefox too in the future.
Looks like I was right.
The problem lays with Sun, and now Oracle. Applets just haven’t moved on over the last 10 years. We could have had 3D before people had even coined the name ‘webGL’, but we didn’t.
Bugger 3d, we could have had seamless, instant startup like Flash first…
Cas
??? JOGL has a very fast brand new NApplet. It is a bit late but it works.
A few minutes ago, I wrote to Tristan Nitot (president of Mozilla Europe).
Edit.: I contacted Oracle and kappa wrote something there in bugzilla:
I’m glad to hear JOGL is doing more to make 3D easier. It worked pretty well in Applets, but it was a lot of hassle to work out how to get it going (especially how you used to need to do a lot of work to get it running both with and without JNLP file support). But applets appeared in 1995, and Java 3D in 1998, so the idea of having 3D via a Java applet is nothing new. It’s just between then, and now, there has been almost no official work for making applets easier to use, faster to start up, look less buggy (like offering to update the users JRE rather then crashing when you get version issues), and seamless 3D support. I don’t see why all of those issues couldn’t have been solved at around the early 2000’s. If it had, I think the web scene today would be very different, and things like canvas and WebGL might have even become the norm earlier.
IMHO updating Java should be mandatory and behind-the-scenes in exactly the same way Chrome updates. With the same sort of release schedule.
Cas
According to Sven, you just have to use the provided JARs, some of them contain the native libraries. The NApplet tries to load the natives from these JARs if they are in the same directory than jogl.all.jar and if you haven’t set the flag used to disable this mechanism. If you don’t use AWT, the applet gets started almost immediately, it seems promising. I won’t use it because I prefer Java Web Start and my game is already too big (whatever I use, the installation requires at least one minute).
Edit.: The plugin hang detector kills Java applets taking more than 15 seconds to load. In my humble opinion, it does not allow any consistent game using large models to work.
Er, I think that’s precisely the problem there. Applets should start up and load in subsecond time even on ancient hardware and be displaying some loading bar. What they do next is load things asynchronously.
15 seconds? Mental. When was the last time you even saw a Flash starting?
Cas
Lots of programmers don’t make the effort to do that when using applets but I agree with you.
Officially, it is not specific to Java and the default value is 45 seconds. The guy who reported this “bug” made wrong decisions in his application, the data from the database should be loaded after the applet is started, not before…
Applets gave java a bad name 15 years ago and the situation hasn’t improved since.
Bravo for browsers killing off that broken and slow interface. Drives more adoption to WebStart.
I fear that if Mozilla blocks the whole Java Plugin, Java Web Start will be concerned too
plugin2 might have problems running webstart as applets in the browser window, yes. But the webstart stuff that launches in another window is simply an association of application/x-java-jnlp-file to the ‘javaws’ executable. No plugin of any sort involved.
Is that vulnerability related to Applet with all permission or even Applet in the sandbox?
Applet with all permission should be killed altogether. It’s so unsafe and anyone can understand why. If you need to ask to your users, ‘‘do you accept to give me the right to destroy your computer if I want’’, to be able to run your applet maybe that shouldn’t be an applet.
You need those permissions for copy & paste. :cranky:
Might be a bit hardcore but I think that is the right decision. There is a difference between copy/paste and a complete access to the content of the clipboard in all time. (I made assumption about how work copy/paste in java because I don’t know how it’s done. Correct me if I’m wrong)
Same way as in any other application.
The issue was always that applets start up without you knowing they’re going to start, which is why they need to ask you permission if they’re going to do anything outside of the sandbox. Honestly I can’t quite see why applet security is such a problem. Has there been an instance of a sandboxed applet escalating privileges?
I wonder how long it’s going to be before Javascript is bedevilled with this sort of stuff. Oh, it already is
Cas