Applets & Security
Applications vs Applets
Most of the ideas you have learnt about applications can be applied to applets. One of the key benefits of applets over applications is that they do not have to be installed. If you consider the work that is required to install conventional applications in terms of selecting components and the install directories, you may appreciate the reduced “overhead” of applets.
One of the main areas of difference is security, particularly in accessing local resources. The main restrictions are as follows.
Applets cannot read or write the the file system of the browser user. This means they cannot delete files or test to see what programs you have installed. In contrast to this, some versions of JavaScript in the leading web browsers were able to access the local file system, leading to the possibility of rogue code.
Applets cannot communicate with any network server other than the one where the applet was orignally loaded from. This prevents an applet from attacking another system from the readers system.
Applets cannot run any program on the reader system.
Applets cannot load local programs such as DLLS (dynamic link libraries).
Another consideration is that applets cannot start up new windows in the same way that applications do. If an Applet were to open a new Window, how could you be sure it was on top of the other windows and not hidden behind?
These restrictions are known as the Java sandbox. It is possible to configure applets with a finer grade of security using digital signatures and encryption. With signed applets you are asked if you want to allow the applet greater access to your system than the default and you have to decide if you trust the developers not to violate your system.