Netscape 3.0

Netscape was the first company to develop a web browser that included the Java runtime engine for applets. Microsoft also is currently developing a Java-enabled browser. After the initial interest in the Java environment, Sun decided it would need to define a common class library to which all programs intended to be executed in the context of the World Wide Web would have access no matter what browser they were running under. The Applet API includes many classes for displaying all of the standard GUI objects, along with support for sounds and images. This Applet API is the API being supported by Netscape in its 3.0 Navigator browser (see fig. 13.7). Several other companies have licenced Java, including Quarterdeck and Microsoft, and will most likely have Java enabled browsers either by the time you read this or in the near future.

Figure 13.7  The opening Netscape 3.0 screen.

There is little you must do to use Netscape to view Java applets. In fact, Netscape is set up to run Java applets as its default behavior. If you wish to disable Java applets in Netscape, choose Options, Network Preferences, and you should see the dialog box in fig. 13.8.

Figure 13.8  Netscape’s Security Preferences dialog box.

Netscape limits the loading and functions of applets to ensure tight security. Netscape, for example, will not load applets or native code from a local hard disk. Thus, if you wish to test applets you have written with Netscape, you need to place them on a web server and call them by using the standard HTTP protocol. Using File, Open File will not allow an applet to load.

To test Netscape, point it to a site that uses Java applets such as Sun’s own online page:

http://java.sun.com/

An animated cup of coffee should be at the bottom of the page. The status bar at the bottom of the Netscape screen provides information about the status of applets being loaded from pages. It will provide information about the status of any applets that are loading. As the individual images are loading, the applet places a message in this area while Sun’s Java page is loading. For more information about the execution of Java applets in Netscape, the Java Console can be used (see fig. 13.9). Any runtime errors encountered will be placed here. In order to see the Java Console, choose Options, and check the Show Java Console option. Be sure to then choose Save options from the same menu in order for your change to remain between sessions.

Figure 13.9  The Netscape Java Console.

The current level of security in Netscape is somewhat more restrictive than that provided with the Appletviewer tool furnished with the JDK. In the Beta 3 release, for example, applets that use sockets will not run because this is considered a security risk. Additionally, access to native methods on a local disk or any applet at all is forbidden. Netscape, however, will possibly loosen these restrictions in the final release of Netscape.

Other Issues in Using Java Programs

In addition to the settings available to restrict what Java is able to do on the client side, and the security features built into the Java environment, it is important to discuss how Java affects other issues relating to the Internet such as the following:

•  HTTP. The primary use of Java is over the HTTP service implementing the distribution of World Wide Web service over the Internet. However, it does not really affect this service in any way. Just like an inlined image, sound, or movie, the HTTP server merely sends the file that holds the Java class. HTTP already has its own secure implementation including SSL and SHTTP, and the safe transport of Java files over the Internet would fall under these protocols and the programs implementing them.

•  Firewalls. Java does not really affect the way in which firewalls are employed in a networked environment. Because HTTP is used as the transport mechanism, it is affected in the same way by a firewall as any other HTML document or inline.

•  Sockets. The implementation of sockets in the applet API does not include any security features that would protect the information being transported using a socket. Therefore, information being passed in this way should be considered unprotected. Any interaction a socket would have with a file on the client computer would fall under the normal restriction of file access that all file access is covered under.

•  E-mail. As of now, no e-mail client supports Java applets, although integrated browsers/e-mail clients such as Netscape Navigator 2.0 could readily implement such a feature. As with the HTTP protocol, e-mail would merely be the transport medium, and any applet delivered in this way would be restricted just as any applet loaded through an HTML page. Again, the security of the applets being transported is just like any file attached to an e-mail document.

•  Encryption. As mentioned previously, version 1.1 of JDK enables signing of classes, although Sun’s HotJava browser is the only one capable of using this feature. This way, class files and data could be encrypted and verified before use. Therefore, any of these files being moved across the Internet depend upon the security implemented in the transport mechanism being used.

Presently, most of these topics are non-issues, but it is important to be aware that this is the case, and to recognize when this changes. As with any new technology, it is extremely important when trying to maintain a high level of security to keep abreast with the current information available on the Java environment. The best place for this is at http://java.sun.com/ where there are several documents relating to security and the current implementations of Java. Also be sure to keep up on the current status of the client-side browsers you want to use, because any problems with the browser’s implementation of Java could lead to security holes. The Java implementation is a program itself and can have the same problems as any other major software release. Be sure to test any software before implementing it in a secure environment—this goes with the Java-enabled browsers as well.