By default, and for security reasons, Java applets are contained within a "sandbox." This means that the applets can't do anything which might be construed as threatening to the user's machine (e.g. reading, writing or deleting local files; putting up arbitrary message windows; communicating with arbitrary other machines; or querying various system parameters). Early browsers had no provisions for Java applets to reach outside of the sandbox. Recent browsers, however (Internet Explorer 4 on Windows, and Navigator 4 on all its platforms), have provisions to give "trusted" applets the ability to work outside the sandbox. For this power to be granted to one of your applets, the applet's code must be digitally signed with your unforgeable digital ID, and then the user must state that he trusts applets signed with your ID.
Digital IDs are in effect statements signed by a Certificate Authority saying "This person is who he says he is, and this CA vouches for him."
A digital ID has two parts: your public certificate and your private key. The private key is what you use to sign your code; the public certificate is what other people use to verify your code was signed with your private key.
Yes, this is a very sketchy description. For more info, see
A Certificate Authority (CA) is a trusted company that sells digital IDs. What makes a CA "trusted"? Well, a CA is trusted if its CA certificate is installed in your customers' browsers, ready to vouch for digital IDs it has distributed. In other words, for a browser to understand a digitally signed applet there must be two digital IDs involved: the one used to sign the applet, and a second one installed in the browser that verifies the first one's authenticity. (The assumption is that it's very difficult for nasty people to sneak their CA certificates into other people's browsers.) VeriSign's CA certificates are pre-installed in current versions of both Internet Explorer and Navigator, as are Thawte's (and others' as well), so both browsers can handle applets signed with IDs from these companies. (Of course, the user must still say that she trusts you based on your certificate.)
If you don't want to use a public CA you can buy software and become your own CA. If you do this, you'll be "trusted" if your customers install your CA certificate into their browsers. This is very feasible if you're producing work for in-house use, but won't work at all if you hope to have the general public use your signed products.
Your last option is to create test certificates. These are free (good), but won't be recognized unless you prepare your browser (inconvenient, and perhaps unsecure). For more information, see Creating and Installing Test Certificates.
To make this document clearer I use the CA VeriSign in all my examples, mainly because that's where I got my digital IDs (it was the only game in town at the time). Although VeriSign's services have worked well for me, I've heard good things about Thawte, and I'm sure other good CAs are available as well. Shop around before you buy.
Netscape and Microsoft have different approaches to granting extra powers to applets. Most of the time, Microsoft Internet Explorer's is simpler: all you do is digitally sign an archive containing your applet. When the archive is loaded by Internet Explorer, it will immediately ask the user if she trusts the developer. If yes, then the applet runs with full access to the user's machine. If no, then Explorer tries to load the applet using the individual .class files; if it succeeds, it runs the applet in the sandbox. (For exceptions to this, see Writing code for Microsoft Internet Explorer.)
Microsoft now has a finer-grain permissions system. You can find out more at <http://www.microsoft.com/java/sdk/32/pg/pg_pkgdist_signcode_5.htm>.
With Netscape Navigator (by which I mean Navigator or Communicator), you must add code to your applet that requests permission to do any "dangerous" actions, and then sign an archive containing the applet. Your code will need to use Netscape-specific Java classes called the "Netscape Capabilities API". When the applet is loaded by Navigator it will be constrained by the sandbox. When the applet requests permission to do a "dangerous" action the user will be asked if he trusts the developer; if the answer is "no" then the request fails (but the applet keeps running); if the answer is "yes" then the request succeeds and the applet may use the specified "dangerous" capability.
I describe two separate procedures for signing applets, one for Netscape Navigator and one for Microsoft Internet Explorer. For Navigator, the files must be signed with a Netscape Object Signing ID (creating a "manifest" of the files), and then the files and manifest must be wrapped into a .jar archive. For Explorer, the files must be wrapped into a .cab archive and then signed with a Microsoft Authenticode ID. Currently, Authenticode signing can only be done under Windows (Win95 or later). Netscape Object Signing can be done under Windows (Win95 or later) and a variety of Unix platforms; I only describe how to do it under Windows.
Note: neither procedure below will work with Sun's HotJava browser, which requires a third method of signing altogether. Since I have no experience with this browser I haven't included any information on providing for it. A kind reader has contributed the procedure for signing for the Sun Java Plugin: you can find it here.
There's one further wrinkle in the process. Digital IDs are only good for a certain period of time (the default is a year). Once an ID has expired it is no longer valid. However, what about applets that were signed with a then-valid ID, but whose ID has since expired? Should the applet be trusted?
Microsoft and Netscape handle this situation in different ways. Netscape's tools won't let you sign an applet with an expired ID. However, Navigator will treat an applet signed with a currently-expired ID the same as an applet signed with a still-valid ID. Microsoft's tools allow you to attach an unforgeable timestamp to your archive. Archives which were timestamped and signed with valid IDs will be treated as secure even after the ID expires; archives that weren't timestamped or were timestamped after the ID had expired will be reported as suspect.
Not all versions of Navigator and Explorer understand signed applets. In fact, only the following do:
"That's it???" I hear you cry. Yes, that's it. Internet Explorer on the Mac 4.0, for instance, doesn't understand signed applets. I haven't tested more recent versions, but I assume that hasn't changed. I've tested Navigator 4.0 on the Mac and on Win95, and both understand signed applets; I believe that on other platforms it does as well.
In addition, since the classes and methods that signing an applet frees you to use are on the margins of Java, not all of them are well supported. For instance, Navigator 4.0 on the Mac doesn't implement the FileDialog class, so there's no way for the user to choose a file from her hard disk.
In 1998, I did some research that showed that 60% of users use browsers that understand signed applets, and I'm sure this percentage has increased since then. So, it's not all that bad. Think of it as "Coding for the Future".
Next section: Writing code for Netscape Navigator
|Copyright © 2018 Daniel Griscom||Site design myriadweb.com|