I like how "I don't use it" converts so easily into "no one uses it".

I'm afraid people do use it; of course the banks and so on (who probably can migrate to better solutions fairly easily); personally, I have a site that's pretty active this time of year, with music theory training applets which can capture MIDI and microphone input in-browser.

I could spend a year to rebuild what I can in JavaScript and HTML5 (there's nothing out there besides Java that'll give me MIDI input, of course), if I had a year to burn, which I don't.

Should I shut down the site entirely (and block thousands of users) because there are security issues appearing in OLD versions of Java, that many browsers don't even let you run anymore? Or should I just encourage browsers to keep refining their control over when applets can run -- so applets can be (again) simple to run by people who actually want them?

I'm leaning towards the latter.

An unmaintained sandbox is worse than no sandbox at all because it gives a false sense of security.

The few who have to use it can keep using the old version and it being deprecated would put pressure on the websites that still use it to stop doing so.

Do you mean the Java browser plugin? If so, I agree with you, but this is still a serious issue even if you just have Java installed for desktop applications.

EDIT: To elaborate on jokc's reply (who appears to be shadowbanned), it seems that this exploit is only a problem for applications that use Java's sandboxing features, and the browser plugin is the best example of this -- but desktop applications can use these features too.

No other desktop apps are commonly sandboxed, so that's a minor issue, if an issue at all.

If they aren't sandboxes you don't need the vulnerability. Then the only question is if you can run untrusted code. Which is going to depend on the application.

If you're downloading an application and running it, it's pretty much immaterial whether it's Java-based or not; there's no vulnerability required to trash your computer at that point.

Sandboxes only apply in the browser, as far as I can think of -- Java code all executes in the context of a security manager, but does anyone actually set a custom security manager for running untrusted Java applications? (Maybe I'm just missing an example you know of...)

Unfortunately people do still use it. Including some online banking sites.

Her in Norway most banks have gone together and made a common id system known as "Bank ID" that uses Java. It is used for many online transactions, not just banking. Many can't buy things like movie tickets or online goods without using it.

A total nightmare from a security perspective.

Same system in Sweden unfortunately. Not as widely adopted though (movie tickets, wow...)

Movie tickets, airline ticket, most online stores. Being Java it of course also doesn’t work on mobile phones, pads, etc.

They are starting to roll out a version for mobile phones now, but it requires that your operator supports it and many will need a new sim card so it takes time.

In the meantime if you are out with your friend and you finds out you want to see a movie, you will have to walk to the theater or call a friend with a pc to buy a ticket. You can't just do it online from you iPhone (some movie theaters may have a app for that, but not where I currently live :( ).

It feels especially bad because it wasn't always like this. Before the massive adoption of Bank ID you could do almost anything online from your phone.

The Android version of BankID seems to work well on the sites that has enabled it.

No, you are talking about a different system.

Norway: https://www.bankid.no/

Sweden: http://www.bankid.com/

The Swedish one uses native apps for Windows, Mac and Linux rather than java. Still trivial to attack from a trojan though.. :/

The old applet can be used for that, but it should no longer be included in new JVM releases.

Oracle's cash cow enterprise software products like Oracle ERP (Enterprise Resource Planning) are largely Applet-based.