Thread: Running unsigned (Java) applications like this will be blocked in a future release

can't open the ChartApplet.class file because it's a third-party sourced applet.

Ask the third party to verify that file.

What is in the <applet tag in the html?

site isn't programmed to use the Jar

Its not the site, its the html that controls what the browser asks for. That's why I asked you to post the <applet tag code from the HTML page.

There is NO reference to a jar file there. You need to research how to write the <applet tag to use a jar file.

Glad you are making progress.

Let us know how it goes in January when Oracle changes all of this.

Take a look at this thread: http://www.javaprogrammingforums.com...a-changes.html

As well as reply #19 to this thread.

Sorry, I didn't realize you already paid for a certificate. In that case, you should be fine.

But yeah, it's a real shame for novices and hobbyists who can't afford certificates. Deploying with Java has always been a bit of a mess, and this is a nail in the coffin for applets.

I think it's criminal what Oracle is doing. Keep in mind that not all commercial certificates are even natively recognized by java. Some of them will still require you to get your end-user to do something in order to "download" the certificate onto their machine. Basically, the only out-of-the-box commercial certificates will be the ones that Oracle decides are worthy. On top of that, operating systems and/or browsers might have their own list of "approved" CAs, so the "Write once, run anywhere" mantra might not be true if a CA which Oracle doesn't already approve of is not used.
I think you should be fine with Comodo, but I do not know for sure.

Also, while I understand where you are coming from when you say paid certificates will deter exploiters, java already provides the security warning about unknown publishers and self-signed applets. From then on, it's up to the user whether or not they should trust the developer. It certainly shouldn't be Oracle's fault if a user chooses to run a program from an unknown publisher and gets a virus or something, it is the user's fault. This new update only hurts the development community by adding unnecessary expenses for novice, open-source, and/or nonprofit programmers.

I do think this is all related to the security exploits.

Basically, Java is (or at least used to be) set up to allow code to run in one of two modes- in a "sandbox" or not. Code run in a sandbox is not allowed to do things like access your hard drive, which makes that kind of code relatively harmless.

In the past, applets were run in the sandbox by default. This made sense, because you don't want arbitrary code accessing your hard drive every time you visit a new website.

But some code (games, for example) need to run "out of the sandbox" for legitimate reasons. Maybe to save a file, maybe to use the gpu, whatever. In the past, that kind of applet popped up a box asking the user to run the applet with the specified permissions, and only then was it allowed out of the sandbox.

This was also good, as you knew when you were running potentially "dangerous" code. If you didn't know why the box was popping up, you could refuse. If you knew you were trying to run a program, you could accept it.

(this glosses over the fact that those popups were already user-unfriendly, as most people still don't know the difference between a sandboxed program and a "normal" one)

Then came the Java exploits. Basically, what they do is allow "dangerous" non-sandboxed code (writing to the hard drive, executing other programs, etc) to run as an applet- without popping up the dialog asking the user if they really wanted to run the code.

I actually got nailed by this Java exploit. I went to a website that loaded an applet inside an advertisement. This happened silently, so I didn't know an applet was running. The exploit allowed "dangerous" code to be run, which locked up my hard drive and forced me to reformat.

Oracle has been fighting these exploits for months (years?), and every time they fix one, two more seem to pop up. Oracle then made it so a popup displays every time any applet is run, including completely sandboxed applets. I thought this was a pretty reasonable solution, even though it was pretty unfriendly to end users.

Even though that solution seems to have been working, their end solution seems to be disabling applets for everybody except people who pay for certificates. The thinking is that virus writers aren't going to spend any money on a certificate that will be revoked the first time somebody reports them.

This is a real shame for novices or hobbyists just learning Java. They can no longer throw an applet on a webpage to show off their work, which I think is really going to hurt front-end Java. Why go through these hurdles if I can just use JavaScript or Unity or html5? (there are answers to that question, but I'll save that for another rant)

But that's just it- think about it from Oracle's perspective. They don't really care about front-end Java. All of the focus is on server-side Java, and that's where Oracle is going to spend their resources. That leaves user communities to deal with the front-end side of Java (JavaFX being the exception, and I'm very interested in how that plays out). And here we are.

Keep in mind that none of the "dangerous" code is special to Java. Any real language can do things like access your hard drive and really screw your system over. The problem with Java is that applets let this kind of code run in the browser, and the exploits let this code run without the user knowing it. It seems a little funny to me that the "solution" to the problem is to have end users downloading .exe files, which have absolutely no security attached to them whatsoever. But the thinking is that the user has to /know/ they're running the file, so they're less likely to run harmful code. We'll see.

I read an article from a few months back where the author was claiming that Oracle was attempting to destroy the java sandbox.

Oracle then made it so a popup displays every time any applet is run, including completely sandboxed applets. I thought this was a pretty reasonable solution, even though it was pretty unfriendly to end users.

Minor inconvenience, in my opinion. Given the upside of doing it, it never bothered me much.

If Oracle really gave a crap and still didn't want to change much, they would take the same approach that Google took to potentiality dangerous apps on the Android system: instead of a general "sandbox or all" permission system, require the developer to specific the exact system functionality the app will require, and present that information to the user. For example, if you go to the Android app store and download an app, you are told everything that app requests permission to do (monitor phone calls, access internet, use cell data, ect.).
This provides the end-user enough information about the potentiality dangerous code to make an informed decision on whether or not they want to run it.

You can already specify individual permissions. You still have to sign a jar that specifies individual permissions.

The change means that self-signed jars, even ones that specify individual permissions, will no longer run unless the end-user futzes around in their control panel. This is bad because most end-users don't know anything about Java, let alone how to change their security settings. They'll just know "it doesn't work!" and give up.