Security and Restriction:

Java applets are programs which run on a Web user's machine. Anything which could execute code is a potential security risk since of the damaging things which can occur. Viruses could damage a computer's file system and reproduce onto other disks. Even Microsoft Word has been a security risk since of Word Basic-an executable programming language which can be used in conjunction along with Word documents.

Security is one of the primary concerns of Java's developers, and they have implemented safeguards at various levels. A few of these safeguards affect the language as an overall: The removal of pointers, the verification of bytecodes, and other language issues has been elaborate elsewhere in this book.

A few of Java's functionality is not possible whenever programming applets since of security concerns. The subsequent safeguards are in place:

• Applets cannot read or write files on the Web user's disk. The storage of information must be completed on the disk from that the Web page is served if information must be saved to disk during an applet's execution.
• Applets cannot make a network connection to a computer other than the one from that the Web page is served.
• Pop-up windows opened through applets are identified clearly as Java windows. A Java cup icon and text like as Untrusted Applet Window appear in the window. These components are added to avoid a window opened through Java from pretending to be something else, like as a Windows dialog box requesting a user's name and password.
• Applets cannot use shared or dynamic libraries from any other programming language. Java could make use of programs written in languages like as Visual C++ through using a native statement from inside Java. Therefore, applets cannot create use of these characteristics since there's no way to adequately verify the security of the non-Java code being executed.
• An Applets cannot run any programs on the Web user's system.

As you can see, Java applets are more limited in functionality than standalone Java applications. A loss is a tradeoff for the security which must be in place for the language to run remotely on users' computers.

Several users and applet developers understand the requirement for security, other than wish it weren't so strict and inflexible. They say which users should be able to disable or weaken Java's security if they need to. For a large degree, they're right, and you could expect Java applications to have more flexibility in the future.

Java security is not all or nothing. An application could deny or grant access to applets based on a huge variety of criteria: the name of the applet, where it came from, the type of resource it's trying to access, evens the exacting resource. An application could select to let applets read a few files, but not others, for instance.

Flexible, selective schemes include a lot of extra difficulty, and along with complexity come the potential for mistakes. Further, there are subtle, difficult questions surrounding flexible security schemes. For instance, employees might have extremely different ideas about acceptable security than their employer does-how much control should be given to the users and how much to the site security administrator? Faced along with numerous tough questions like that and the people behind Java decided to be careful at first. They are beginning along with an extremely conservative security model that will become less rigid as time goes on. This is possibly a good strategy since a big security scare early in Java's lifetime would have really dampened enthusiasm for the language.

The other problem is in which there isn't yet a good criterion for deciding which applets should be trusted and that should not. The best solution is possibly to trust applets based on who wrote them, but that's hard to verify.