I'm trying to understand the rationale behind Java Applet development these past few years. Back in the old days, most Applets were unsigned, and the code for these was run in a sandbox where barring bugs in the sandbox itself it could do no harm. If some applet wanted more privileges, the author could sign the code and the user could decide to trust that author and run the applet without the strict sandbox restrictions.

Recently, however, running unsigned code in sandboxes appears to be very hard. In my experience it requires reducing the security setting and establishing exception rules. As a consequence, more and more applets are being signed, since the user experience there is better. So more and more applets are running outside a sandbox, often with no good reason for it except that it's easier to explain to users that they should simply click on “Allow” (as opposed to say adding a domain-based exception rule).

Did I present the development correctly? Or did I just at some point somehow garble my Java setup to a point where it would refuse running sandboxed Applets for me personally?

What's the rationale here? How is running signed applets from unknown people without a sandbox any safer than running unsigned applets from these same people in a sandbox? Is the sandbox really that buggy?


The Java Sandbox was bypassed a lot in the last years and Java established itself as one as the major attack vectors in drive-by-downloads. To mitigate the problem Oracle decided to only allow applets signed by a trusted CA (i.e. no unsigned or self-signed), since this is at least increases the efforts needed by the malware author. Also, certificates used for signing can be revoked to limit the impact of a certificate used for signing malware. This change to the platform was done in 2013 with Java 7u21.

This does not mean that all these applets run outside the sandbox. To cite oracle:

As of 7u21, signing no longer automatically equates to privileged execution, ..

Thus if the applet uses privileged execution depends on the exact way it was embedded and on the permissions it implicitly or explicitly requests. With Java 7u51 further restrictions were added and all applets must now contain the list of permissions they need.

Apart from that it is recommended to remove tje Java plugin completely for security reasons or at least make applets click to play, which is the default in several browsers now.

  • Thanks! The quotation in particular was something completely missing from my understanding, and with this signed-but-sandboxed alternative in place the whole thing does indeed make a lot more sense. I guess I should pay attention to that distinction in the future, and from developers I don't know or trust only accept to run sandboxed applets. – MvG Dec 2 '15 at 10:59

How is running signed applets from unknown people without a sandbox any safer than running unsigned applets from these same people in a sandbox?

It isn't. Anyone can buy a code signing certificate. It is just meant to digitally sign your app and the users can check the signature and see if if is the signature of the official developer.

Is the sandbox really that buggy?

There were always critical vulnerabilities in the JVM in the past which allowed apps to break out and so on but were fixed. Theoretically there can be 0days which abuse a new unknown vulnerability in the sandbox or specific classes.

Digital signatures are just to verify that the downloaded and used app comes from the original developer / author who has the private key for signing his apps but no other person.

The basic concept is described here: https://docs.oracle.com/javase/tutorial/security/sigcert/index.html

Digital Signatures

The basic idea in the use of digital signatures is as follows.

  1. You "sign" the document or code using one of your private keys, which you can generate by using keytool or security API methods. That is, you generate a digital signature for the document or code, using the jarsigner tool or Security API methods.
  2. You send your signed document to your recipient.
  3. You also supply your recipient with your public key. This public key corresponds to the private key you originally used to generate the signature.
  4. Your recipient uses your public key to verify that your document came from you and was not modified before it reached him/her.

A recipient needs to ensure that your public key itself is authentic before he/she can use it to verify that your signature is authentic. Therefore, you will usually supply a certificate that contains your public key together with the key of a Certificate Authority who can vouch for your key's authenticity. See the next section for details.

Also malware can be digitally signed, this is not uncommon.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.