Develop Reference

Necessary and sufficient conditions to run Java applets and JWS applications in browser?

I have already asked this and was heavily downvoted. Unfortunately, I still can't solve it. I don't know what I do, but sooner or later I loose an ability to run java applets and java web start applications in all browsers.
Here is an example what is happening.
I am opening page with applets http://csis.pace.edu/~bergin/Java/applets.htm and getting the following picture:
with signs plugins were blocked. I am trying to unblock
which causes another dialog
after OK I have another
next
if clicked
And so on.
Applet doesn't run.
After dancing with PATHes, Java updates and so one, once I can have applet run. But sooner or later I will stuck in this position again.
I would like to know, is it possible to exclude this situation in principle?
I mean I don't want to disable security at all, but I mean that in case my explicit permission everything should run. Is it possible to do that?
UPDATE
First of all, I don't understand, why can't I run applet on outdated java if I want?
I am a human and robots should obey me! :)
Suppose I wish to debug my applet on old version of java, why not?
Second, there is no information about what version it thinks I have and what version it wants?
Without this information it is possible that there is just a bug in version detection mechanism.
I have multiple versions of Java in Program Files since I am a Java developer. Then how can I know which one it uses?
UPDATE 2
I have updated my Java from 1.8.0_20 to 1.8.0_25 and now situation have changed, but applets are sill impossible to run.
The proof I have "latest" java:
The proof I have added the site above to exclusions list:
The effect of applet run:
(applet not runs)
Clicking details result:
(no any details in fact)
So, what to do?
UPDATE 3
This site is not working: http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2012VP113;orb=1;cov=0;log=0;cad=0#orb
(show orbit diagram)
Reloading/restarting browser does not help.

I looked at your html source and realized you're using the .class file directly instead of wrapping it in a jar file. This is what you have:
<applet code="GSort.class" width=700 height=400>
I think applets no longer work when using .class files directly due to new security requirements. They have to be wrapped in jar files because you need to add some security settings to the meta-inf folder of the jar file. Here is how oracle recommends deploying an applet:
https://docs.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html
Edit:
I tried again with adding the site url to the Java security exception list and this time I got it to work! It looks like chrome stays in memory after exiting so changing Java security doesn't affect it unless you shut down chrome completely and restart it. Easiest way is to use Internet Explorer. Try it with Internet Explorer and it should work (assuming that you still have the site added under java security exception list).

Update client computer using web application

I am developing an e-commerce web application, and in that ads from other giants pop up. I figured out that this is done by PriceFountain, which is actually a spyware. I found the steps to remove that from my laptop. more found here.
but the problem is my clients can also have this adware. I want to programmatically do following or either of them, on the client side:: (and if it is not possible at least inform the user to do so)
If, PriceFountain is present, uninstall it from their system. If it is an add-on, remove that.
Activate the pop-up blocker (deactivation can be achieved through javascript and jquery). But I want to activate. My site does not need pop-ups.
Alter the registry of user for the contents of PriceFountain.
I know this is somewhat an unethical hack, but can this be achieved and if so, how?
More of that, it is just my curiosity can we affect client site settings.?

You used to be able to do that (with jscript/vbscript) in IE if and only if the user added your site to his trusted sites (and allowed pretty much everywhere there), or if it was the intranet-site with relaxed permissions.
Back in the old day's I had such a thing for the intranet-help-site where users could browse through the faq and click on the 'execute solution' button for the common 'problems' (previously solved and added to DB).
For rather obvious security-reasons this is no longer the case (although one can still pull some stuff in legacy IE environments).
The point is: you can't do this on other browsers then IE (unless maybe you'd develop separate plug-ins for them and ask your users to install something that will essentially give you access to their whole machine). Realize that effectively what you are asking for is a way to fully control the user's machine. Would you install such a browser (on your parents pc)?
The best course of action would be to face-up, inform your users on your main-website (enter-page) that something bad spread throughout an ad-network and guide them through the steps (that you already found) necessary to relieve them from their problem.
Even if what you asked was possible, you'd still need the user's cooperation somewhere along the way, even if you'd were to write an application for this that the users could download and run (administrative/elevated)..
Good Luck!
EDIT: for the registry you might try something with the answers in this question: read/write to Windows Registry using Java
Still, you'd still need the user's co-operation.

java is insecure message when running some applets

I have Java 1.7 installed. We have a web site with two applets. When one of them is loaded I receive the following dialog. When the other is loaded I don't. Why is it that some applets cause this security warning and others don't?
Is there something in particular that causes this warning?
Dialog text in searchable form:
Do you want to run this application? Your version of Java is insecure and an application from the location below is requesting permission to run.

Is there something in particular that causes this warning?
Code that is not digitally signed. See Java 7 Update 21 Security Improvements in Detail .

After further investigation I discovered the cause of this warning. This is apparently a new security feature of Java 7. When you execute an applet a call is made home to Oracle to see if your Java is up to date. If it is not up to date you receive this new dialog letting you know so. The primary risk identified in the dialog is that there is a new patch for Java. If you update Java you will no longer receive this dialog until the next update comes out.

What is the purpose for Java JNLP requiring a signature?

I have only a limited understanding of security basics and things like digital signatures. I understand, for example, how digital signatures are useful in public key cryptography. I do not, however, understand why signing my JNLP is necessary, or what maliciousness it prevents against, nor can I find this info readily available.
I have found that deploying unsigned JNLP's is allowed, but things like disk and network access are restricted. However, let's assume I am a malicious person who makes a Java application that will do something malicious to the content of your disk (and I disguise it as something else). I can easily sign this, deploy it, and you can come to my website, unsuspecting, and launch the app and have your disk attacked. In a case like this... what did the signature accomplish?
More to the point... if anyone can simply sign an application with hardly any effort required... then what's the point?
I'm sure I'm missing something painfully obvious... please enlighten me.

You cannot just sign something - not if you want the browser to execute it without restrictions. The certificate that you use to sign your software must be signed using another certificate, and so on, until the chain of trust reaches a root certificate that has been installed in your browser.
While there have been a few less than diligent Certificate Authorities occasionally, you cannot generally get such a certificate without providing some proof of your (network) identity. That means that malicious people have to provide some sort of identification, little as it may be. Even more important, CAs are expected to revoke certificates that have been used for malicious activities, or otherwise compromised, thus limiting the extent of the exposure.
To get to your point, if you use a CA-signed certificate in your site and that certificate is used to distribute malicious software, the CA will revoke your certificate sooner rather than later. If, on the other hand, you use a self-signed certificate, the browser will ask the user to confirm its use. If the user goes through with it despite the warning, well, it's their own fault, ain't it? There is no general countermeasure to either stupidity or ignorance, after all...

This question does raise some valid points and thkala provided a good defense for the value of CAs that are issued from a trusted authority.
But why do we need a CA for a JNLP and not for a regular execuatbale JAR file? I think the reason is that JNLP is meant to be launched from a browser. JNLP files are a replacement for applets that run withing the browser in a sandbox - theoretically secured away from doing any harm on your computer. A user may launch a jar file running in an applet simply by visiting a page. Likewise, a JNLP may be launched by simply clicking a button. In Chrome I get asked to first save the JNLP. But in IE or Firefox, I see a launch button or regular web link - it looks like any other button or link in a web page - and with a click the program runs. This is a bit more seemless than downloading an executable and then running it.
On the other hand, an executable JAR file can be installed or just run a number of ways. For instance, they are often packaged on CDs along with MRIs since some MRI viewing software runs on the JVM and the patient or doctor needs to launch the custom software to view the MRI. But this software doesn't get "installed." You simply run it from the CD.
A JNLP on the other hand can work more like an installer than a stand alone program. I've been able to get them to create desktop shortcuts and do file associations. From the users perspective, my JNLP app feels like a native program with it's own icon and file type. Since it runs so seemelessly from the browser and has unfettered access to the client PC, having it "signed and trusted" can make users feel more secure in running this.
Historically, I believe this is why JNLP and applets get signed. I believe the practical value of this signing has expired.
First of all, signing your app from a CA costs hundreds of dollars so many companies skip this. There are some cooperate apps that run self-signed code and the users just know to click the "accept" button after the browser gives the warning.
More importantly, the recent security updates for Java have centered around patching back doors that allow unsigned code to get out of the sandbox and do everything that a signed applet or JNLP can do. It seems that every time Oracle patches a way out of the sandbox, someone finds a different way out. The best solution is to have the runtime always prompt the user for permission to run a Java applet or JNLP file. Not only can a self-signed JNLP file gain access to the local file system and the LAN, but an unsigned JNLP can as well. If the user has the very latest security update from Oracle (of course, most do not) and before the next clever way to slip out of the sandbox is discovered, then the sandbox model is really working as intended. But for most users, most of the time, the sanbox model has not been working as intended. I think it's time for all JNLP files to ask for permission to run and just given them all the same access that a regular JAR file has.
Then I won't have to re-create my security certificate every 6 months.

What Applets Can and Cannot Do

I'm going to develope some Applets, And I was wondering What an Applet can and cannot do.
I know that an Applet can't write in the Registry or Windows folders.
Do you know other things ?
Thanks

Official docs http://download.oracle.com/javase/tutorial/deployment/applet/security.html
Much of it depends on whether you signed it or not.
There is one omission i know of in that....
Java AWT Robots are tricky since they give keyboard/mouse access to the applet. You can do it, but trust from the user alone doesnt cut it.
In this case you need to set your own custom security manager to grant permission to create a Robot
Edited for correctness based on comments, thanks guys

Actually a signed applet can access the Windows registry through JNI calls.
For more info on the applet capabilities get a look at http://en.wikipedia.org/wiki/Java_applet