Will New Red-Text Warnings Kill Casual Use of Java?

New submitter ddyer writes "Java 1.7.0_40 [Note: released earlier this month] introduces a new 'red text' warning when running unsigned Java applets. 'Running unsigned applications like this will be blocked in a future release...' Or, for self-signed applets,'Running applications by UNKNOWN publishers will be blocked in a future release...' I think I see the point — this will give the powers that be the capability to shut off any malware java applet that is discovered by revoking its certificate. The unfortunate cost of this is that any casual use of Java is going to be killed. It currently costs a minimum of $100/year and a lot of hoop-jumping to maintain a trusted certificate.'"

Comments

Apparently, applets only

[SirGarlon]

TFA says this is for "Rich Internet Applications," that is, Java applets embedded in Web pages. It doesn't seem this would affect Java programs that you execute locally, such as (for example) Eclipse.

Re:Apparently, applets only

[snookerdoodle]

Exactly.

OP doesn't seem to know anything about Java.

This will not affect standalone Java programs, only applets.

It could be argued that they should have done this a long time ago.

Mark

Re:Apparently, applets only

[i kan reed]

It could also be argued that java has no place in browsers given the modern flexibility of javascript. The UI features are worse, the performance differences are negligible, legit code is sandboxed either way. All you're left with as an advantage for true java is threading.

Re:Apparently, applets only

[jonabbey]

This would not affect Eclipse, no, but it does affect locally produced applications that are distributed from an intranet web server with Java Web Start / Java Network Launch Protocol.

Previously, we could just self-sign our app and users could choose to accept the app once and for all and not be bothered so long as the signing cert didn't change. Now, all of our users running Java 1.7.0_40 are given the threatening dialog each and every time they run our internal app, and they can't get rid of it.

We're going to pony up for a code signing cert from a (Java-recognized) certificate authority to make the dialog go away. It's a hassle, but probably still the right thing for Oracle to do at this point.

Re:Apparently, applets only

[i kan reed]

The most advanced you've played has no bearing on the most advanced you can play. WebGL is fine.

Re:Apparently, applets only

[Anonymous Brave Guy]

It could be argued that they should have done this a long time ago.

But it wouldn't be argued by anyone who actually knew what they were talking about.

For one thing, signing a Java applet proves exactly nothing about how trustworthy it is. You can easily get a signing certificate by spending a small amount of money and waiting a small amount of time. The whole concept of granting increased permissions to untrusted software just because it's been signed is absurd.

Secondly, blocking unsigned applets will break numerous existing web-enabled devices, which has been one of the significant remaining use cases for applets in recent years. These are effectively running embedded web servers and serving up the applets from there, so you can't just go in and upgrade them later when your certificate expires (and the longest cert periods you can get from major CAs are only about 2-3 years, a fraction of the normal lifetime of some of these devices).

The craziest thing is that the kinds of device I'm thinking of are typically used by the IT guys in large organisations. Some of them are going to go through months of approval process before they get installed, and when they do it will be in server rooms or data centres, accessed electronically via a separate management network with no connection to the outside world, and accessed physically via biometric security that would make James Bond cry. But in order to keep those applets safe, now they need to be signed too, just in case? Seriously?

Not everyone using applets accesses them from a public web site. They can't necessarily upgrade or replace them on a whim. The kinds of environments still using them are more likely to be exactly the kind of long-running projects where whipping up a quick replacement in JavaScript isn't a sensible option and where backward compatibility really matters.

Also, to anyone who thinks alternative technologies like JavaScript and HTML5 canvas/SVG offer the same flexibility and speed as Java applets, I know a prince in Nigeria who'd like to sell you a classic car from his collection for a great price.

Casual use of Java

[Anonymous Coward]

> The unfortunate cost of this is that any casual use of Java is going to be killed.

You may think you're just a casual user of Java. You may think you just use Java for recreational purposes. Everybody knows Java is just a gateway language for other languages like C#. And we all know what happens to C# programmers.

Casual use of Java was dead 10 years ago.

[stewsters]

I really don't think that there is a casual use of Java applets anymore. Banks and large corporations use it, but when was the last time you ran someone's java app that wasn't your own or a major corporation's? Large players can pay $100 a year for their app without thinking about it. Personal projects you trust and can push continue on. You shouldn't be running java apps from random other sources if you value security.

Re:Applets only

[jasper160]

It would be a welcome gift. I admin for a bunch engineers and a lot of the corporate and gov sites they access still use Java. And even worse some are so crappy they are version specific which makes no sense other than they are lazy.

Bad for science education

[l2718]

Java applets are an essential tool for science education -- as simulators, calculators etc. Are all these research groups supposed to get some authority to digitally sign their applets?

Fundametally, a major aspect of Java security is that, since it runs on a VM, an applet it is inherently encapsulated. Yes, VM bugs can cause problems, but the value of all the free educational applets online far exceeds any possibly security benefits of unptached VM bugs.

I thought the whole point of Java...

[BitterOak]

I thought the whole point of Java is that it runs in a sandbox so applets don't NEED to be trusted. Are they admitting failure here?

Re:Screw java, HTML5 + JavaScript

[Anonymous Coward]

please don't ever type "chive" again

Re:Applets only

[shipofgold]

Java as an idea was great....write a program that compiles once and the binary can run on anything.

<rant>
Java as an implementation has failed miserably for just the reason mentioned by the parent. I have encountered too many apps that won't run unless a specific version of the VM is available.

Then there is Tomcat, evil software container...I have lost too many hours of my life trying to keep that beast happy....just today I got an email from a colleague who wants to restart tomcat weekly because something is causing it to leak file descriptors. More than 1024 files open at the same time...I could probably figure it out, but that would again be more hours lost to java.
</rant>