Security zones allow a system administrator to manage groups of sites using the same level of trust for a whole group. Administrators can set nonrestrictive security options for trusted areas and, at the same time, set very safe (restrictive) security options elsewhere. Predefined zones exist for categories such as the Local Intranet and the Internet. Security zones relieve administrators of having to list every trusted applet and its permissions, and they help administrators avoid the risk of leaving too many detailed decisions to end users.
There are five default security zones defined in the trust-based security for Java implementation in Microsoft® Internet Explorer 4.0. These zones correspond to the most commonly used types of sites:
My Computer
This zone includes most classes stored on the local machine. Because this zone is completely trusted, few or no security restrictions apply.
Local Intranet
This zone includes content that is known to be reliable (typically located inside the firewall or obtained using a secure sockets layer [SSL] connection).
Trusted Sites
This zone includes responsible Internet sites that are allowed to run with increased permissions, but not with the powerful permissions allowed to the Intranet zone.
Internet
This zone includes all other sites, including scratch and development areas inside the firewall, and untrusted parts of local drives. This zone would typically be set to the standard applet permissions.
Restricted Sites
This zone includes potentially harmful sites to which severely restricted permissions apply. For these sites, you may want to define "sandboxes" that are even more restrictive than the standard Java sandbox.
Network administrators can configure three different sets of permissions for each zone. The set that a permission is placed in determines whether or not the user will be presented with a dialog box that shows requested permissions.
Permissions granted without user intervention
These permissions are granted to applets from the specified zone without querying the user. These permissions can be separately specified for signed and unsigned applets.
Permissions granted with user intervention
These permissions can be determined directly by querying users with a list of the permissions being requested; in this case every permission not mentioned is assumed to be denied.
Permissions that are prohibited
These permissions are considered too dangerous to allow under any circumstances. They are automatically denied.
If an applet uses only permissions granted without user intervention to its zone, it will run without user intervention. If it uses any explicitly denied permissions, it will automatically be prevented from running. Otherwise, the user will be presented with a single dialog box listing all the permissions being requested and their associated risk. The user can then make one decision about whether to trust the applet that has that set of permissions.
An applet that does not receive the additional permissions requested will still be permitted to run, but will be prevented from exercising those permissions by security exceptions. The applet can catch the security exceptions so that it can take alternate action, perhaps continuing to run with more limited functionality.
The administrator can define a set of permissions that is assigned to all unsigned classes and scripts. This set defines the permissions of unsigned applets.