So far, programs have been able to read from files, to write to files, and to call methods (such as System.exit) that behind the scenes make system calls, i.e., calls to routines of the underlying operating system. Using some of the APIs that have not been considered, it is also possible to write Java source code that communicates with other computers. Although it is reasonable for these sort of activities to be performed by Java source code that is a program, i.e., a Java application, is it appropriate for these activities to be performed by Java applets?

To be more specific: if you visit a WWW page, and the author of that WWW page causes your WWW browser to execute some bytecodes produced by the author, are you happy for these bytecodes to write to files on your computer, or to read any of your files?

The designers of Java took the view that it is not necessarily appropriate for these activities to be performed by Java applets that have been downloaded from the Internet. So, the environment of an applet is controlled by the user of the WWW browser. For example, there is no access to local files from Netscape's Navigator, whereas HotJava users can configure which files can be read from and which can be written to. More details about these restrictions are given at http://java.sun.com/sfaq/.

This approach is often called the Sandbox approach. This was Sun's first attempt at controlling what an applet can do. With later revisions of the Java Platform, Sun have been providing ways in which an applet can be allowed to perform these activities. It is now possible to add to an applet a digital signature authorized by a certificate obtained from a certificate authority. If you download this signed applet and you allow your WWW browser to accept its certificate, the applet is said to be a trusted applet. There are more details about how to execute signed applets at http://java.sun.com/security/signExample12/.

Sun's main WWW page on security restrictions is http://java.sun.com/security/.