PROGRAMMING PARADIGMS

Getting Wired on HotJava

<APP
CLASS="ClassName"
SRC="URL"
ALIGN=alignment
WIDTH=widthInPixels
HEIGHT=heightInPixels
     AppletSpecificAttribute=aValue
.>

The things on the left side of the equal signs are attributes; those on the right are their assigned values. ClassName is the name of the applet's subclass and is the only required attribute. An applet can require zero or more AppletSpecificAttributes. The value for the SRC attribute tells where to find the applet, much as the SRC attribute for the IMG tag tells where to find the GIF or JPEG file, or the HREF attribute for the A tag tells where to find the linked page. In the case of the APP tag, though, the SRC attribute specifies not a static image or page, but executable code, and this makes all the difference. This one tag changes the whole experience of the Web. HTML has its hot links, but the APP tag makes a Web site truly hot.

With HoTMeaL, I've added the Java APP tag and its attributes to the lists of tags you can drop into your documents.

HTML tags in HoTMeaL reside in lists in a library, and you can select which tag list you want to work with today. Each list corresponds to an HTML vocabulary. I've implemented the Java tag vocabulary as one of these lists, so you can decide to work with the Java vocabulary for one project, then click a couple of buttons and be working with basic HTML 2.0 or with the Netscape extended HTML vocabulary for a different project. And if a new version of Java adds new tags, users should be able to upgrade HoTMeaL to use these just by pasting some text into a field.

That's it. That's all I've done. I don't offer any support for programming Java apps (way beyond my poor powers), and although HoTMeaL includes a crude browser or previewer, it doesn't know from APP tags. Clearly, I didn't need to read all the Java and HotJava documentation just to do this. All I needed to read was the page that defines the syntax of the APP tag.

But be warned: Many editing tools will soon be announcing support for Java or HotJava. Some of them may mean as little by this trendy claim as I do.

Sugar or Sweet-n-Low?

Another nifty aspect of the HotJava experience: Every HTML browser has a fixed set of capabilities. HotJava doesn't. Support for new protocols and formats can, in principle, be downloaded. Basic functionality can be extended by grabbing executable content over an Internet connection. This is cool.

HTML browsers come with a certain amount of sugar. You can choose the browser with the sugar you want, but when, say, Sweet-n-Low-enhanced Web pages come along, the old browsers won't be able to handle the new sweetener. HotJava, in principle, will. (Actually, users of my editor can--in principle--download a new HTML vocabulary, but that's only because HTML tags are just text. HotJava lets the user actually change the program's code by downloading.)

All of this downloadable functionality raises some deep questions regarding security. When you import code fragments across the net and execute them--which is exactly what HotJava is all about--you are inviting security problems. Dave Winer's "Aretha" package (formerly known as "Frontier"), which contains a scripting language, and which is currently being Internetified, took some heat this summer for just that. HotJava and Java were both designed with this problem in mind, and have a lot of security features built in. But not enough to prevent a sufficiently talented and motivated cracker from breaching system security, you can be sure.

To be fair, the primary security issue here is probably inherent in the Web itself; HotJava just makes it more obvious. I predict interesting times.

A Pretty Good(TM) Idea

Van Hoff wraps up his DDJ article with something slightly tricky about security: "In the future, Java will also provide features for signing code using public-key encryption. This will allow the secure exchange of Java code with trusted partners over the Internet."

It's the "trusted partners" business that's a little tricky, as I recently had pounded into my head. I just installed a public-key encryption system, in the form of Phil Zimmermann's Pretty Good Privacy (PGP), on my main machine. Anyone who wants to send me secure messages can e-mail me at mswaine@cruzio.com using my public key. It follows.

User ID: Mike Swaine <mswaine@cruzio.com>
Key size: 512
Creation date: 1995/07/25
Key ID: 4CF1F515
Key fingerprint: F0 DA AB 42 77 93 F4 D1 AB
 E2 BB 3E A3 75 A6 22

Publishing your public key in a magazine has disadvantages, but it has one major advantage: keyholder identification. Let me explain.

Somehow, the codesmiths of World War II got along with single-key encryption systems. Such systems don't differ in principle from the letter-substitution ciphers we learned as kids, or the code Sherlock Holmes cracked in The Valley of Fear, in which numbers indicate the ordinal position of the target word in a particular book. In such codes, there is a single key--the algorithm "shift forward one letter," or the name of a book, or a large number used to transform one string of bits into another. The last of these is the idea behind DES, the U.S. Federal Data Encryption Standard. With a single-key system, one key is used to both encrypt and decrypt the message, and the sender and receiver must both have the key.

The catch-22 of single-key systems is, how do you ensure that the sender and receiver both have the key? If a secure channel exists for the sender to send the key to the receiver, then they don't need the key. If there is no secure channel, then how do they communicate the key?

The Advantage of Going Public

Public-key systems seem to solve the problem. These systems use a pair of keys, mathematically generated, with the following nice properties: Any message encrypted with one can only be decrypted by the other, and neither key can be derived from the other. This solves the catch-22 of single-key systems. I can publish my public key to the world, keeping the private key secret. Now anyone can send me a private message by encrypting it with my public key, and only I will be able to decrypt it.

As an added benefit, the public-key system gives you digital signatures. I can encrypt a message with my secret key and send it to you. This gains me nothing in security: Anyone with my public key can decrypt the message. What it does get me, though, is authentication: If you can decrypt the message with my public key, then it has to have been encrypted with my secret key, which I guard as jealously as my automatic-teller PIN number. Therefore, the message must have come from me. Absolute identification. A digital signature. Better than DNA.

Digital signatures and encryption can be combined, so that I can send you a message that only you can read, and that you can be sure could only have been sent by me. The codesmiths of WW II would have loved public-key encryption for solving the catch-22 of single-key systems. Unfortunately, it has a catch of its own.

Yes, I can send you messages and be sure of their privacy as long as I have your public key. Yes, you can send me messages and I can be sure they're from you as long as I have your public key. And yes, you can send me that public key in a message over an unsecure channel. But how do I know the message is from you?

If I had your public key, I could verify that it was from you. But until I have your public key, how can I be sure that you're not somebody else masquerading as you? In short, how do you send me your public key in a way that I can be sure it's yours? Now, if we had a secure channel....

In fact, the best method that anybody has come with yet for certifying a public key as indeed belonging to person X is this: Have somebody who knows X's voice call him or her up and verify the key. That's it. Oh, there are more-sophisticated-sounding systems of certification, but they all amount to the same thing: Somebody who can vouch for the person has to assure you that the key you have is indeed that person's key.

Thus the phrase "trusted partners."

It all seems just a bit crude.

In our situation (yours and mine), you, the DDJ reader, wanting (assuming you did want) to send me, the DDJ editor-at-large, a secure message, it's not so clunky. Unless someone has gone to the trouble of publishing a bogus issue of DDJ and replacing your copy with this counterfeit, PGPassures you that the message you are reading right now is from me, and that the key I've supplied is really mine.

So, to establish that your public key is really yours, all you have to do is publish it in your column in a nationally or internationally distributed magazine. As described, it's a solution of limited applicability, but it is a solution. Generalizing it to the non-magazine-columnist population is left as an exercise for the reader.

You Can Call Him "Zimmy"

Perhaps you know the Phil Zimmermann story.

Zimmermann is a modest man who has written a modest account of his trials and tribulations in developing a piece of software that goes by the modest name of "Pretty Good Privacy." He's a peculiar sort of modest man, though: the sort who would trademark the phrase Pretty Good. A modest man for the '90s. Where he's written this modest account is in The Official PGP User's Guide (MIT Press, 1985). The trials and tribulations he's had probably include the usual ones that beset any nontrivial software-development project, but he doesn't talk about those. Phil has, you see, the additional trials and tribulations that come with being under investigation by the U.S. Federal government for illegal arms exporting. Because, you see, PGP is encryption software, and to the Federal government, encryption software is the same as armaments, and domestic electronic publication is the same as export. And unless you're a Marine colonel, you can go to prison in the U.S. for illegally exporting arms.

An equally engaging section of the PGP manual is the stirring foreword by John Perry Barlow, who in four-and-a-half pages manages to touch on most of the major political and social and cultural issues raised by the universal availability of secure cryptographic software, including the potential to make the paying of taxes optional.

By the way, the manual also explains how to use the product.