Oracle's got nothing to do with the failure of the Java applet sandbox. The problem with the applet sandbox is simple: it was designed before anybody really understood modern secure C programming --- integer handling, memory lifecycle, concurrency.
The major browser projects all host a very similar attack surface --- a programming language with content/attacker- controlled code hooked up to a whole bunch of crazy bells and whistles. The browsers barely, just barely, have a handle on that attack surface. And the modern browsers have all rearchitected in the last 5 years specifically to address the problem, which is something the Java applet maintainers have not done. Who in the world is surprised that doubling the browser attack surface creates problems?
It's long past time we put Java applets out to pasture.
I tend to agree if we're talking about client-side Java served up through a browser. But client-side Java has been going downhill for years. Server-side Java on the other-hand is alive and well.
Given that Oracle now tries to make you install Ask malware (adware? Same thing..) with every "So you want to get security fixes, eh?" updates..
No, the title's totally fine. Oracle sucks balls and killed Java. I'm still having it installed (interested in Clojure, for example), but I actively make sure that people around me Do Not Use It.
Java as a platform on the desktop was killed by the company that is
a) unable to advance the language and platform, to make it 'state of the art' again (right now, it's ... old-fashioned and limited, if you're looking at competing platforms)
b) actively trying to get malware on your machine because .. why not, you're already installing stuff from those clever people, maybe another browser toolbar would be totally fine?
Both Java applets and Java desktop apps are completely irrelevant to Java on the server-side.
A case could be made that Java is also an amazing success in countless devices, from Java smartcards to smartphones / tablets (with, for example, use Java source code compiled to bytecode run on something looking very much like a JVM on Android devices).
Java is an amazing success and neither Java applets nor Java desktop have anything to do with it: on the contrary, these two Java technologies hardly did anything besides giving the Java brand bad reputation.
Both Java applets and Java desktop apps could disappear overnight and the millions (!) of Java devs out there would still have a job. Granted, they'd still need one Java desktop app: the IDE they're using to develop Java apps).
Note that I'm not saying that Oracle is playing nice when, apparently, they're using spammy techniques when you install desktop Java...
Pretty sure Sun was doing Ask Toolbars with Java installs [1]. And Ask Toolbars are not malware, they're not even adware. They don't compromise your computer. The shady thing it does is change your default search engine to an Ask.com search result that has more, and less noticeable ads. That's a pretty shitty thing, not user friendly, but it's not "malware" and it's not "adware." I worked on the Ask Toolbar and there was no tracking information other than your general non-personally identifiable stats gathering like one would use on a website with Google Analytics.
Changing the default search engine in a user's browser when they did not consciously ask for it counts as malicious data corruption in my book. Can you even begin to imagine how much damage and confusion that causes for "old people"?
FWIW, the Ask.com toolbar is only installed on Windows. Installing Java is relatively painless on MacOS and Linux. Not that this makes me any happier about the situation.
There's also OpenJDK as an option, though for some reason there's no official Windows builds for it.
Well... it's certainly killing applets, but applications that run on the JRE are going to have a tough time as well.
I have a few applications that suddenly started popping up warnings that they may stop working in a future Java release, because of a missing property in the JAR manifest (no joke, the warning actually included technical language something like this).
Certainly, though, server-side Java is hale & hearty as ever.
I've never used python for anything serious. I'm shocked to learn about this python functionality that duplicates webstart or applets. Being able to hand out a link that will download an interpreter and then run my script in a secure way (with self signed code no less) is a really slick feature.
That or the author is playing a dirty rhetorical trick.
"While this is great in theory, for java its pointless. The contents of a jar can be extracted just the same as any zip format, signatures removed and resigned all without any issue."
Completely false? Resigning a jar with authenticated signature will turn it into a self-signed jar and will then display the nasty warning as it should. This security measure works very well: if you want to run stuff in the browser, use js+HTML5 (or GWT). If you have legacy java code that you must run in the browser, get it signed properly and it will run. This is universally an incredibly good thing given how flakey java applets are.
Applets were invented at a time when there was competition between language-level sandboxing (Java) versus code signing (Active X).
Today we understand that you need language-level sandboxing, OS-level sandboxing, permissions enforcement, code signing, and a way to revoke bad apps. (Android store, for example.) And it's not really enough.
Most of us have moved on, but I think Oracle deserves some credit for doing something to protect the people who still must rely on applets for some reason (probably legacy apps).
Orcale does not care about the desktop - and Sun never managed to make it user-friendly (e.g. annoying Java Updater popups on every start, trying to install the ask toolbar, etc). However, Java will stay significant on servers and on Android (as Dalvik).
Java in the browser has been dead for years, or should've been. Sure, lots of people are still stuck with it for legacy apps, but no one likes having to use it. Good riddance.
UNsigned applets by default run in the sandbox; signed applets (including self-signed) run with full permissions unless you specify otherwise in the HTML and in the JAR manifest (where you can explicitly request sandbox-only execution).
The major browser projects all host a very similar attack surface --- a programming language with content/attacker- controlled code hooked up to a whole bunch of crazy bells and whistles. The browsers barely, just barely, have a handle on that attack surface. And the modern browsers have all rearchitected in the last 5 years specifically to address the problem, which is something the Java applet maintainers have not done. Who in the world is surprised that doubling the browser attack surface creates problems?
It's long past time we put Java applets out to pasture.