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