In the preceding discussion, we assumed that you want to load classes from www.xyz.com and that you want those classes to be trusted, so that they might have some special permission when they execute on your machine. For example, the spellchecking class might need to open up a local dictionary file to learn how to spellcheck names and other data you customized for the spellchecker.
Do not, however, make the assumption that all classes that are authenticated are therefore to be trusted, or even that all trusted classes should necessarily have the same set of permissions. There's nothing that prevents me from obtaining the necessary information and tools so that I can sign and encrypt all of my classes. When you download those classes, you know with certainty that the classes came from me--they carry my digital signature, and they've been fingerprinted to ensure that they haven't been tampered with.
But that's all the information that you know about these classes. In particular, just because the classes were authenticated does not mean that I didn't put a virus into them that's going to erase all the files on your hard disk. And just because you know that a particular Java applet came from me does not mean that you can necessarily track me down when something goes wrong. If you surf to my home page and run my authenticated applet, then surf to www.sun.com and run their authenticated applet, then surf to www.EvilSite.org and run their authenticated applet, and then two weeks later your hard disk is erased, how will you know which site planted the delayed virus onto your machine? How will you even remember which sites you had visited in the last two weeks (or longer)? If you have an adequate set of backups and other logs, it is conceivable that you might be able to re-create what happened and know at whom to point your finger (and whom to sue), but such a task would be arduous indeed. And if the virus affected your logs, the finger of suspicion might point to the incorrect site.
Hence, the role of authentication of Java classes is not to validate that those classes are trusted or to automatically give those classes special permissions. The role of authentication is to give the user (or, for a corporate network, the system or network administrator) more information on which to base a security policy. A reasonable policy might be that classes that are known to come from www.SpellChecker.com can read the user's personal dictionary file--but that doesn't mean they should necessarily be able to read anything else. A reasonable policy would also be that this type of exception to the general rule about permissions given to network classes is only to be granted in very specific cases to only a few well-known sites, and that unknown but authenticated sites are still considered untrusted.
The moral of the story is that authentication does not magically solve any problem; it is merely a tool that can be used in the pursuit of solutions.
 |  |  |
| 7.1. The Need for Authentication |  | 7.3. Cryptographic Engines |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
| This HTML Help has been published using the chm2web software. |