There are three security-related areas in OJI:
For general information about security and applets, see Java Plug-in Security.
Previous to Netscape 6, Netscape had its own security model and its own signing 
  method called Netscape 
  Object Signing. The Object-Signing Tools could be used to sign a Java applet 
  so that it could be executed in the JVM. Netscape also provides a set of Java 
  classes, netscape.security, that is used by the applet to enable 
  security in the browser. 
In Netscape 6, two mechanisms may be used for applet signing:
In Netscape 4 an applet must call into the netscape.security package 
  to enable a privilege  even if the applet is signed. If it does not, it 
  will be treated as untrusted. Thus applet signing and granting of privileges 
  are treated separately.
In Netscape 6, signed applets are directly supported by the Java Plug-in. When the browser encounters a signed applet, a security dialog is automatically popped up. The applet does not have to call any method to enable privileges; privileges are already enabled.
However, so that Netscape 4 applets will continue to work in Netscape 6, a 
  stub class for the netscape.security package has been included. 
  The stub class does nothing other than allow the applet to load into Java Plug-in 
  as though it were loading in Netscape 4.
With this release of Java Plug-in, HTTPS is completely handled by the browser. Thus, anything related to HTTPS, such as the service certificate, can be configured through the browser.
LiveConnect allows bi-directional communication between Java and JavaScript. But such communication can present security problems. For instance, suppose an applet and a web page originate from different hosts. Without a security policy, the applet might request sensitive information from a page through a call to JavaScript. Since an applet is allowed to connect to any host, it might then send such information out over the network in an irresponsible manner. A security policy has been implemented to prevent such actions from occurring.
Each direction of communication is considered separately below.
In JavaScript-to-Java communication, a call from JavaScript to an applet is allowed only if one or both of the following is true:
UniversalBrowserRead permission is 
    enabled for JavaScript.Without 1 or 2 being true, no call will be allowed from JavaScript to Java.
Given that a call is allowed, then there are two possibilities: JavaScript will have default or all permissions.
Permissions are determined by checking JavaScript signing:
UniversalJavaPermissions, then it will be 
    granted all permissions.UniversalJavaPermissions, then 
    permissions will depend on local Java policy, which is set by the JRE in the 
    browser. Local Java policy will consider the origin of the JavaScript, determine 
    a set of permissions based on origin, then perform actions on the Java side 
    accordingly.Note that to access an applet from JavaScript, the applet tag will need to 
  specify an ID or NAME attribute.
A call from Java to JavaScript is allowed only if the applet and JavaScript have the same origin.
Assuming the above condition is met, the applet is checked for its permissions. 
  If it has all, then JavaScript will perform the requested actions. If the applet 
  does not have all permissions, then JavaScript checks the origin of the applet 
  and the SecurityManager of the browser then determines what actions 
  the JavaScript engine may perform. 
Note that to access JavaScript, Java does so through an instance of the netscape.javascript.JSObject 
  class. For more information, see How 
  Java-to-JavaScript Communication Works in Java Plug-in.
| Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.Please send comments to: java-plugin-feedback@java.sun.com |   Java Software |