Security Manager, are meant to be defined by application authors (including browser vendors) through subclassing. The rules that Web browsers enforce make up the security policy defined by a particular vendor. Ultimately, Netscape could decide to implement different rules than Microsoft.
Of course, every browser's security implementation depends entirely on the rest of the security model being properly defined. Critical pieces of the Java environment directly affecting security include the Java VM, and the built-in libraries. If any of these pieces have errors, the entire security system will break, regardless of which vendor does the other parts.
All Netscape Navigator versions subsequent to 2.0 are Java enabled. All Microsoft Internet Explorer versions subsequent to 3.0 also include Java. It is, however, very easy to disable Java in both kinds of browsers as long as you can find the right dialog box (see Chapter 4). There is a toggle switch for the entire Java environment. In both Netscape Navigator and Internet Explorer, Java is enabled by default.
The two browsers' security policies are, at the present time, very similar. Both are somewhat strict. The following rules apply to all untrusted applets running under Netscape Navigator and Internet Explorer:
We can see a split among vendors happening already with the 4.x versions of Netscape Navigator and Internet Explorer. Both products offer complex security models based on digital signatures and partial trust. Although the models are quite similar to each other and to the model defined by Java 2, there are many detailed differences that annoy developers and users.
One side effect of the common ground between different vendors' Java security implementations was that early on in Java's history, security holes often cut across all Java implementations. That is, the same problem would be exploitable in all Java VMs, regardless of the browser. These days, it is more common for errors to be relegated to one browser or another. We have more to say about vendors, implementations, and security holes in Chapter 5.
Copyright ©1999 Gary McGraw and Edward Felten.