aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes applet security: Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "applet security:" Watch "applet security:" New topic
Author

applet security:

Abhinav Srivastava
Ranch Hand

Joined: Nov 19, 2002
Posts: 349

jdk 1.0
-------
All applets are untrusted, hence all the restrictions.

jdk 1.1
--------
Applets can be trusted (when loaded from local classpath or when signed and keystored).
Once trusted, no restrictions. Untrusted applets are under all restrictions.

jdk 1.2+
--------
Restrictions are enforced thru security manager and policy files alone and the policies can be changed.

Is this understanding correct?

Questions:

Can extra permissions (in 1.2+) only be granted to trusted/signed applets? (I guess NO, they can be granted to unsigned applets as well)?

Is there any privilege that an applet can never have, no matter what the policy file says?

In any java environment, would it make any difference if the applet is signed but is not trusted (i.e. the certificate is not present in the keystore)?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42639
    
  65
Is this understanding correct?

Pretty much, except that in JDK 1.2+, applets can still be signed. Using permissions and policies is the preferred way (and I'm not sure which one takes precedence if both are used), but signing still works fine. Signing is also the more practical way, unless you're in a position to ask all users to change their local policy files (which is something most people would not have a clue how to do).

Can extra permissions (in 1.2+) only be granted to trusted/signed applets? (I guess NO, they can be granted to unsigned applets as well)?

As mentioned above, the two ways are independent of each other.

Is there any privilege that an applet can never have, no matter what the policy file says?

No.

In any java environment, would it make any difference if the applet is signed but is not trusted (i.e. the certificate is not present in the keystore)?

An applet is trusted if it's certificate is accepted by the user. If the user doesn't trust the applet (by not accepting the certificate), then it doesn't matter whether it is signed - it's considered untrusted code by the JVM.


Ping & DNS - my free Android networking tools app
Abhinav Srivastava
Ranch Hand

Joined: Nov 19, 2002
Posts: 349

thanks for clarifying that.

here is an interesting read -
http://keepitlocked.net/archive/2007/10/10/a-brief-history-of-applet-security.aspx

In Java 2, Sun added Certificate Authorities to the Applet specification, so that anyone with enough money to pony up could create a universally trusted Applet. This was tempered by the fact that now the user could create a policy to restrict these signed Applets to a specific set of permissions. So signed Applets ask for permission to run, and are granted AllPermissions, unless there is a specific client-side policy for that Applet
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: applet security: