Re: Orthogonality and Disaster Recovery

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

-----BEGIN PGP SIGNED MESSAGE-----

In <34537A18.9FE77210@sternlight.com>, on 10/26/97 
   at 09:13 AM, David Sternlight <david@sternlight.com> said:

>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.

This is quite silly argument David,

Do all E-Mail vendors need to be cryptologist?? Do all cryptologist need
to be application vendors?? Obviously not. PGP is a tool much like a
database is. The majority of vendors who develop apps that require a
database do not go out and write their own, rather they use a database
engine that is suited to their needs. Betreve doesn't try to develop every
application that may use a database, instead they sell the database engine
and let the application developers make the apps. The same is true for
E-Mail vendors, they integrate PGP into their products. No need for PGP
Inc, to develop their own E-Mail product.

FWIW: I am quite confedent that if Phil wished to write an
E-Mail/NewsReader he is quite capable of producing a better product than
the peice of crap N$ has on the market.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNFObb49Co1n+aLhhAQHdWwP/YS0QqHPxMyQUbElKR/dIcCNDBy1OSIWc
x+LDvth5QXn0676tC++bYyW30aw4Wc/PX2WkGJ4uDwmvRg+sPzPwtX2gTvEsPlO9
XiNg7vBaJbewUf2vfKEPFaj7YVZEG1en0lN6WLpQeN6Movb7kJNM9wyPJeS0qVNM
IuKKOIN2VHU=
=4aZI
-----END PGP SIGNATURE-----

William H. Geiger III wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In <34537A18.9FE77210@sternlight.com>, on 10/26/97
>    at 09:13 AM, David Sternlight <david@sternlight.com> said:
> 
> >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.
> 
> This is quite silly argument David,

Not at all. See below. You give yourself away by starting out this way.

> 
> Do all E-Mail vendors need to be cryptologist?? 

If the client's e-mail is to be secure, yes. But let's be accurate here. Phil
is not, nor has he ever been a cryptologist. He's a programmer who learned a
few things about crypto algorithms and copied existing work. His unique
contribution, if there was a technical one, was in key management. I haven't
studied enough cryptology to know if "web of trust" was copied too.

> Do all cryptologist need
> to be application vendors?? Obviously not.

Now that IS nonsensical because cryptology is a wide and deep art only a small
part of which has to do with mail applications themselves. In contrast, mail
applications to be secure must use encryption. There's some very muddy
thinking going on in your post.

> PGP is a tool much like a
> database is. The majority of vendors who develop apps that require a
> database do not go out and write their own, rather they use a database
> engine that is suited to their needs. 

Except for the occasional password protection, databases don't need encryption
to the extent e-mail does.

>Betreve doesn't try to develop every
> application that may use a database, instead they sell the database engine
> and let the application developers make the apps. The same is true for
> E-Mail vendors, they integrate PGP into their products. No need for PGP
> Inc, to develop their own E-Mail product.

You miss the point here. And you miss the many worked examples. RSA is selling
lots and lots of toolkits for lots and lots of money for in-line integration
into applications, not for pre- and post-processing. The former is the way to
go; the latter a kludge until something better comes along.

> 
> FWIW: I am quite confedent that if Phil wished to write an
> E-Mail/NewsReader he is quite capable of producing a better product than
> the peice of crap N$ has on the market.

You are losing it. First of all I doubt very much that Phil could do this. If
you look at the development time and staffing for good e-mail applications,
this is simply beyond his capabilites and he's never claimed otherwise. Second
of all, it's clear that you've not checked out the current Communicator mail
module if you call it a "piece of crap". You simply don't know what you're
talking about. Same for Internet Explorer, whose mail module has gotten rave
reviews and the best mail program yet and caused reviewers to switch from
Eudora. It, too has integrated crypto.

David