Launch “policytool” from command-line – this tool allows you to define a policy for applets on the web in general and specific websites – possible to have multiple policies.
This is a called a sandbox – applets have security managers that dictate what they’re allowed to do.  By default, not allowed to do very much.

Applications, by default, do not run in sandboxes, but it is possible to specify that you want them in one.
java -Djava.security.manager edu.cis3023.gui.GUIRunner

This is all pretty useless in most circumstances.  What we want to do is allow users to run our applet on the internet.  We must create digital signatures.

Digital Signature – generate a public/private key pair - keep private key to yourself, give out public key to everyone.  Hash the contents and encrypt this code using the private key.  If someone is able to decrypt the contents using the public key, then you know it was signed using the private key and the contents have not been modified since.   

keytool -genkey -alias signFiles -keypass password -keystore jeffstore -storepass password
Generates a public/private key-pair.  If the keystore has already been created, it uses that one; otherwise, it creates a new one.  Alias is how you refer to the key-pair entry; keypass is needed to access it.

 jarsigner -keystore jeffstore -signedjar sScorched.jar scorched.jar signFiles
Signs a jar using the key signFiles in jeffstore and names it “sScorched.jar”

But how do you know public key actually came from the right person?  Certificate authorities can provide a certificate for someone simply by signing that person’s public key and some information about them.  If you have the certificate authority’s public key, you can decrypt this and know that the public key you’re using on the jar came from the right person.  Getting certificates cost money; usually better (for small-time stuff) to just assure your users that your applet won’t destroy their system.