Applets-Security System

  The first thing to realize is that although Java works on every platform, it's not the same-from a security perspective-in every browser. Netscape's Navigator has much more estrictive security rules than does Sun's HotJava browser. That's probably because UNIX users-HotJava's audience-are generally more familiar with security issues and computers in general than typical Mac or pc users. As a result, the current versions of Navigator hardwire more security limitations than are required by the Java security baseline. Because the various security restrictions are rapidly changing, the following list covers the various types of restrictions your customers are likely to encounter when trying to run Java applets:

• Cannot read or write files on the local machine. This can be loosened by allowing the user to define a specific directory on his own machine which contains files that can be written or read. The objective is to prevent trashing of your files or the installation of a virus. Netscape currently (version 3.0) does not allow an applet to read or write any files on the local machine. You can use the Java/JavaScript link to write data to a cookie, though.
• Cannot delete user files.
• Cannot rename files.
• Cannot create new directories.
• Cannot list the contents of directories. You wouldn't want applets to be able to snoop through your files and report back.
• Cannot get file information (such as modification date, size, or type).
• Cannot make a network connection to any machine other than the one that originated the applet.
• Cannot run any programs on the user's machine.
• Cannot work with any ThreadGroup other than its own.
• Cannot load native methods. Clearly, if an applet could load native C++ code, all security would go out the door.
• Cannot avoid warning banners on any windows your applet creates. This prevents an applet window from pretending to be something else, such your AOL signon dialog asking for your password. The banner is automatically added so you don't have to worry about it.
• Cannot create its own SecurityManager subclass.

Unless you're doing something fairly unusual, all of the security restrictions boil down to these two rules:

• You can't work with files on the user's machine unless he lets you.
• You can't connect to anything on the network other than the machine that originated your applet.

These restrictions are designed to ensure that an applet, no matter how malicious its developer is, can't cause you significant difficulty. The security rules prevent an applet from reading or modifying your file system and making network connections to sites other than the one that the applet came from. This prevents the sending of forged e-mail or the transfer of data from machines behind firewalls. Of course, if you use a browser that gives you more security control, you can overcome some of these protections. For example, if your browser lets you authorize writing of files and you accidentally include your root directory as an allowed place to write, an applet could then write files anywhere with potentially significant results.

One last thing is that, even with all of these restrictions, one class of attacks is still possible. Either through malicious intent or incompetent programming, an applet can execute what is called a denial of services attack on the user's computer. Such an attack consists of the applet using large amounts of system resources, thereby preventing you from doing anything else. This could be accomplished by opening several windows or initiating tons of threads. Although this is annoying, the worst it can do is force you to reboot your computer.

Of course, all of this assumes that Java is properly implemented. There have already been a number of bugs found in versions of Java prior to 1.0.2. Until Java settles down and the implementations are found to be bug-free on all platforms, there will always be a risk of security breaches due to implementation errors in Java itself. But since Java is designed to be secure, it's reasonable to expect that once the bugs are ironed out, Java will be very secure.