Dunno why I got this since I'm not on the cypherpunks list, but I found it interesting and worth responding to. (Tim--please repost to the list if my attempt to do so fails.) Robert Hettinga wrote:

--- begin forwarded text

X-Sender: tcmay@mail.got.net Mime-Version: 1.0 Date: Sat, 25 Oct 1997 13:52:05 -0700 To: cypherpunks@algebra.com From: Tim May <tcmay@got.net> Subject: Orthogonality and Disaster Recovery Sender: owner-cypherpunks@cyberpass.net Precedence: bulk Reply-To: Tim May <tcmay@got.net> X-Loop: cypherpunks@cyberpass.net

One of the themes of modern computing I strongly support is that of "orthogonality," or clean functionality. A browser should not also try to be a money management program. A word processor should not also try to be an accounting program.

This is a sensible criterion when the functions are indeed independent. There are small leakages even there--thus an on-line money management program which can send inquiries about incomplete transactions to a bank and receive replies needs a small e-mailer and certainly an Internet interface. The argument has, however, become polarized for self-serving purposes by Microsoft. They have linked their Internet Explorer with the OS, claiming the desktop as the place of commonality. That permits them to require bundling of the two. They have apparently threatened vendors who don't bundle THEIR browser on the desktop with pulling their Windows license. They have refused to allow vendors to remove their browser icon from the desktop on grounds it then "doesn't present the complete 'Windows experience' to the user". What's next-integrating Word with the desktop to drive out competing word processors; integrating Access to drive out competing data bases. The matter is currently under challenge by the Federal government, whose definition of orgthoganality seems to be that a particular application has (in practice) or has had a separate market--been sold separately.

Failure to observe this rule of thumb has led to spreadsheets which can run MPEG movies in spreadsheet cells (I'm not kidding), and to Web browsers which take 20 MB of free memory to run reliably because they also contain mediocre news readers, mediocre mailers, and lots of bloatware cruft.

Under the Federal definition as long as a news reader or a mailer have been sold separately they are separate product. But in this case there is important common functionality. Netscape Communicator integrates not only the mailer and newsreader, but provides a near-identical interface to the two and lists newsgroups as a continuation of your list of mail folders. The model feels a little artificial (and their newsreader doesn't yet have filters so it's inconvenient), but one can see some sense in it. Similarly, one often wishes to mail pages one is browsing. Integration of the mailer and the browser are thus quite convenient. It is true one can use the passing of events and the clipboard to do it with separate applications but that's both inelegant and a source of inefficiency and problems. The fundamental problem with the modular approach is configuration control and that is a big enough mess as it is with control panels and extensions, as any user can attest. A small industry has sprung up which reports inconsistencies there, and programs which test for such incompatibilities (and are quite time-consuming) also exist (at least on the Mac), illustrating the reality of the problem. In such cases strong central control and integrated operation is best. It is, in fact, the root of the Mac metaphor, where Apple's Human Interface Guidelines have forced a common user interface on all "Mac-like" applications, making for a short learning curve and the famous lack of a need to RTFM for most Mac applications. Windows has a long way to go but is heading in a similar direction (one hopes). Meanwhile, the "modular" approach of many Windows applications leads to remarks like anything other than changing a file name wiil likely require a reboot. (There's a grain of truth in every satire.)

Much of the strenght of Unix has obviously come from the philosophy that a function or utility should do some small set of things well and cleanly, with chaining of these clean tools to accomplish more complicated tasks.

It is also the reason why Unix is arcane, complex, and difficult for most novices and why poor imitations of Mac windowing and the Mac finder have sprung up. The value of Unix isn't that modularity. It is the robustness of the kernel. In fact modern operating systems use a Unix Kernet under a Mac-like user interface (Rhapsody, Be, etc.).

A crypto program like PGP is intended to encrypt messages between a sender and a recipient, or to provide authentication through signatures, or to encrypt files on a storage medium. These are the classic, well-documented, oft-discussed functions of crypto. Look in textbooks under "crypto" and there won't be much talk of how to supply MIS with emergency backdoors, or ways to monitor employees.

This seems to be a defense of a major failing of PGP. Rather than being a complete package for a user function (encrypting and signing mail, for example) it is a pre- and post-processor which requires a separate mailer and newsreader. In fact this whole argument may be viewed as an attempt to defend that failing of PGP. The failing is understandable since Phil wanted to get something out there quickly and hadn't (and probably still doesn't have) the resources and talents available to do a complete PGP mailer/newsreader--much less be able to compete successfully with those who DO do such mailers and newsreaders. By the way, if one's world-view is PGP-centric there's another argument for combining a mailer and a newsreader--both need to be able to sign traffic and process signed traffic; to pass signed and perhaps encrypted files.

If properly modularized and orthogonalized (so to speak), such crypto programs can then be used as building blocks for other tasks, like remailers, data havens, and so on.

A defense of the obsolete, in my view. Like most "bright ideas" I believe this notion of modules and plug-ins will eventually collapse of its own interface management weight except in cases of both very tightly defined sandboxes, and open-ended/niche needs (such as in an OS or a do-everything text editor such as BBEdit) which the vendor hasn't the personnel and time to fill. Don't be misled by the need for such niche tweaks into thinking there's a fundamental principle at work here.

But there is a growing tendency, as seen in the bloatware examples of browsers and spreadsheets mentioned above, to throw in all kinds of "wish list" and "wouldn't it be nice" stuff. PGP is headed for bloatware. ("It's not just a crypto program, it's also a tax preparation and disaster planning program!")

Netscape has really been moving toward a multi-purpose Net/Web OS for some time. That's why it has a browser, mailer, newsreader, web page maker, conferencer, and push-traffic channel handler. If done well (there's the rub) it is both more convenient, more consistent of user interface, and more integrated, providing user benefits. It is true there are those who prefer some other module (Eudora or Claris e-mailer; Newswatcher) either out of habit or desire. To accommodate them Netscape has unbundled the browser. But that's simply an accomodation to a sub-market of relatively sophisticated users and not a mainstrem strategy. Remember that Netscape is used by about 25 million out there (give or take), and most of them haven't the time, patience or expertise to manage several non-integrated modules. They want another of the Mac's basic philosophical principles (regardless of OS platform)--plug and play. Here, too, Microsoft is just beginnning to catch up but that's the clear direction they're going in.

I'm quite certain that the Security and MIS directors at various companies asked PGP, Inc. to include message recovery features. Not so much to handle the very rare (almost nonexistent) cases where a piece of mail sent at some time in the past has to be recovered because Alice was hit by a truck, or similiar unlikely events (*), but because Security and MIS folks would like the option of "monitoring" e-mail traffic.

Anyone who has been exposed to industrial espionage knows that one needs such features in a corporate environment, not only for micro-disaster recovery but also for investigatory purposes.

(* I have heard no plausible scenarios under which transient communications, which are presumably stored in the form composed (plaintext) on the sender's machine or in the for received and read (also in plaintext) on the receiver's machine, need to be recovered from the *transit* state. We know why the FBI wants access to communications keys--because access to the transit state is what they get when they wiretap or sniff a communications line--but there is no plausbile explanation of why a company would not simply ask Alice for the plaintext, or ask Bob if for some reason Alice is unavailable. The idea someone floated, that he needs to go in and decrypt his employee's mail in emergencies is far-fetched.

Not in any real company where much daily design, negotiation, and dynamic interaction exists only in e-mail until things are finalized by the attorneys or a design review board.

But are such bloatware crypto programs even good for disaster recovery? I say they are not. I say e-mail will be a tiny, tiny portion of the recovery strategy if Alice gets hit by a truck, for example. Far more important will be recovery of her hard disk and related files.

And if Alice is a contract negotiator doing it via e-mail? There are many other examples where your assertions break down.

(No, I am _not_ proposing anything be added to PGP to deal with this disaster planning. Nor am I proposing that PGP enforce plaintext storage, or anything else for that matter. These are all matters _orthogonal_ to the basic function of a crypto program, and a crypto program cannot enforce crypto hygiene any more than a spreadsheet can enforce good tax planning hygiene.)

A better example would be a money management program with a tax module. They are linked and one's money management strategies have tax consequences and vice-versa. You can always find inappropriate examples where little synergy exists, but there are plenty of examples where strong synergy DOES exist. See also my examples above.

I am also not terribly interested in convoluted, byzantine schemes for building "CDR" and such into crypto programs, as some are proposing. Again, this is trying to make a crypto program into a disaster preparation product, and trying to (partly) solve backup and disaster problems best solved in other ways. Not something PGP should worry about (either the program or the company).

You are trying to refute a valid argument by labelling. The issue isn't labels such as "disaster recovery program" but functionality and synergy. You can always create distinctions that would try to make your case, but you do so only by ignoring other, important distinctions. I think this is enough to deal with the fundamental issue, so I'm going to pass on the rest of the side-issues such as "What if Alice forgets her key." The main issues dominate such side issues. David