The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 9 Issue 60

Monday 15 January 1990


o The C3 legacy: top-down goes belly-up recursively
Les Earnest
o Dispatchinate Computerized Cab Service
o Risks of manual page formatters and inserted text
J. Eric Townsend
o Re: What hung the computer?
Dave Platt
o Perils of not planning for errors
Ted Shapin
o Wrong 800 numbers
Steven W. Grabhorn
o Password Sharing
Dave Bafumo
o Call for papers for computer security foundations workshop
John McLean
o Info on RISKS (comp.risks)

The C3 legacy: top-down goes belly-up recursively

Les Earnest <LES@SAIL.Stanford.EDU>
10 Jan 90 1200 PST
After more than 30 years of accumulated evidence to the contrary, the U.S.
Defense Department apparently still believes that so-called command-control-
communications (C3) systems should be designed and built from the top down as
fully integrated systems.  While that approach may have some validity in the
design of weapon systems, it simply doesn't work for systems intended to gather
information, aid analysis, and disseminate decisions.  The top-down approach
has wasted billions of dollars so far, with more to come, apparently.

I noticed the citation in RISKS 9.52 of the article, "The Pentagon's Botched
Mission," in DATAMATION, Sept. 1 1989, which describes the latest development
failures in the World Wide Military Command and Control System (WWMCCS).  The
cited article indicates that they are still following the same misguided "total
system" approach that helped me to decide to leave that project in 1965.  I
confess that it took me awhile to figure out just how misguided that approach
is -- I helped design military computer systems for 11 years before deciding to
do something else with my life.

In RISKS 9.56, Dave Davis and Tom Reid observe that current C3 development
projects seem to be sinking deeper into the mire of nonperformance even as the
plans for these systems become more grandiose and unrealistic.

Please understand that I am not arguing against top-down analysis of
organizational goals and functions.  It is clearly essential to know which are
the important responsibilities of an organization in order to properly
prioritize efforts.  Based on my experience, attempts at aiding analysis and
decision-making tasks with computer applications should begin with the lowest
levels and proceed upward IN THE CASES THAT WORK.  Contrary to some widely held
beliefs, many such tasks do not lend themselves to computer assistance and the
sooner one weeds out the mistakes and intractable tasks the faster one can
improve the areas that do lend themselves to automation and integration.

A great deal of time, effort, and money can be save by approaching development
in an evolutionary bottom-up way.  It is essential to shake-down, test, and
improve lower level functions before trying to integrate at a higher level.
Trying to do it all at once leads to gross instability that takes so long to
resolve that the requirements change long before the initial version of the
system is "finished."  Each time one moves up a level it is usually necessary
to redesign and modify some or all of the system.  It is much faster to do that
a number of times than it is to try to build a "total system" the first time
because that approach almost never works.

Someone (Karl von Clausewitz?) once said that people who don't know history are
condemned to repeat it.  A modern corollary is that people who do know history
will choose to repeat it as long as it is profitable.  Unfortunately, the
Defense Department's procurement policies often reward technical incompetence
and charlatanism.  I will support this claim with a few "peace stories" that
would have been much more atrocious "war stories" if any of the systems that we
designed had been involved in a real war.  Fortunately, that didn't happen.

The presumption that computer-communication system development should be done
on a grand scale from the outset is just one of many bad ideas that have taken
root within the military-industrial establishment.  The reason that this
misconception has persisted for decades is that there is no penalty associated
with failure.  On the contrary, failures are often very profitable to the
contractors -- the bigger, the better.  The bureaucrats who initiate these
fiascos usually move on before the project fails, so if anyone tries to point
fingers they can say that it was the fault of the subsequent management.

While the "total system" approach is one of the more persistent causes of
failure in C3 development, it is by no means the only misconception afloat.  In
subsequent segments I will review some other causes of historical fiascos.  All
of this will be ancient history, since I got out of this field about 25 years
ago.  Of course, many of the more recent fiascos are protected from public
scrutiny anyway by the cloak of national security.

(Next segment: a SAGE beginning.)

    -Les Earnest (

Dispatchinate Computerized Cab Service

"Peter G. Neumann" <>
Mon, 15 Jan 1990 12:33:13 PST
Yellow Cab in San Francisco is using a dash-mounted computer in each taxicab to
facilitate dispatching and supposedly to prevent dispatchers from favoring
particular drivers.  However, the system ($800,000) ``remains plagued by
breakdowns and by drivers grumbling that foul-ups mean a loss in income.''
"When the system is on line, it works well," said Leon Collett, first vice
president of the cab firm.  "But we have had transmitter problems, hardware
problems, software problems."  ...  [Computer Snarling Yellow Cabs in S.F.,
Maitland Zane, San Francisco Chronicle, 15 Jan 90, p.A2.]

J. Eric Townsend <>
Sun, 14 Jan 90 22:27:49 CDT
There's no horror story to go with this, we wised up in time...

Recently, we aquired two Sun SparcStation-1s.  We only bought 1 100Mb
drive for each from Sun and we're (still) waiting on shipment of our CDC
drive.  To save space, I only installed the basics: /, /usr, development
tools, and a couple of other goodies.  I did *not* install the man pages,
as they took up around 6Mb of badly needed space.

Then I had an idea:  Mount /usr/man from our DECstation 3100 as /usr/man
on the sparc-1s.  It worked, and I sent mail to all accounts saying that
the man pages were from Ultrix/BSD, and probably shouldn't be trusted
in critical apps; they were just there for ease of remembering things like
which ls(1) flag does what.

The next day there's mail telling me I've screwed up.  There *are*
man pages for the sun, and I've mounted DEC3100:/usr/man pages over
them.  I typed "man ar", and sure enough, there were man pages with

Sun Release 4.0         Last change: RISC                       <pagenum>

at the bottom of each page...  I was astounded.  Luckily, the ar commands my
prof needed must have been the same, as no data was lost, and everything
worked.  I dismounted all nfs, and looked at /usr/man -- nothing was there.
"man ar" returned an error about not finding the man pages.

A little experimentation shows that the SunOS 4.0.3-4c man command
inserts the above line in the formatted man pages.

I think it's presuming a little too much to go ahead and cite the
source/version of a manual page from within the formatting program...

J. Eric Townsend, University of Houston Dept. of Mathematics

Re: What hung the computer?

Wed, 10 Jan 90 16:10:54 PST
    ... It takes more than minute
    for this particular CDROM to come online, during which time the
    Macintosh is busied out, thus the inexplicable delay....

    Part of the blame for this confusion can be laid squarely on
    Apple.  Their own Human Interface Guidelines specify that the
    pointer should be replaced with a watch for a "lengthy
    operation" (Inside Macintosh p.I-37). They often follow their
    own guidelines, but not in this case.

This is probably one of those cases in which an implementation in one
part of a complex system (the CD-ROM drivers) invalidated a simplifying
assumption which had been made in another part of the system (the Finder).

During normal operations, it takes very little time for the Mac operating
system to process a "disk mount" event.  The current application (the Finder,
in this case) calls MountVol(), which reads in the volume information
and adds the necessary entry to the drive queue.  The delay is usually
less than a second, and so the Finder's author didn't consider it a
"lengthy" operation which required putting up the stopwatch-cursor.
There are a couple of circumstances in which this assumption turns out
to be invalid, though.  One of them is when the volume being mounted
is a CD-ROM which adheres to the ISO 9660 standard.

The Mac operating system keeps track of the number of files available
on each volume, and the Finder can display the counter.  However, ISO
9660 CD-ROMs don't store this value in their headers.  So, when you
mount a new CD-ROM, the Mac's "Foreign File" code quite politely
calculates the file-count, by stepping through the disk's directory!
As you've noticed, this can take a loooooong time!

Unfortunately, there's no practical way for the Finder to tell that
it's about to mount an ISO 9660 CD-ROM until _after_ it has done so.
>From the Finder's point of view, the MountVol() call is an atomic
operation... one which takes a long time to return, it's true, but
one which is not divisible into a look-first/do-it-now couplet.  Hence,
the Finder can't tell that it should [have] put up a stopwatch, until
it's too late!

Fortunately, this issue will probably be moot when the new version of
the ISO 9660 Foreign File code is released by Apple. I've heard that
Apple has eliminated the scan-the-directory-and-count-the-files process;
it's too much work to do, for a small bit of information which is rarely
used or useful.

Presumably, the new driver-code will be available through Apple dealers at no
cost.  It would be adding insult to injury for Apple to tell users that they'd
have charge this Fur'in File code on their Apple Fee Line.

Dave Platt, Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303                                             (415) 493-8805

Perils of not planning for errors

Ted Shapin <>
Fri, 12 Jan 90 10:36:55 -0800
A large computer manufacturer (which my friend prefers remain anonymous) laid
off 7% of its employees just before Labor Day.

My friend, who works there, and who I will refer to as 'Pat', was told he/she
was not in the group to be terminated.  However, when Pat called Saturday to
get phone mail, Pat found his/her phone mail box no longer existed.  Pat also
could not log on to the company computer system. Needless to say, Pat was
worried over the weekend. When Pat went to the plant on Tuesday, the magnetic
badge would not open the computer-controlled door.

After some investigation, it turned out that a data entry operator had made
some errors in entering employee numbers, and indeed Pat along with a few
others in the same boat were still supposed to be employed.

It took 36 hours before all of Pat's computer-controlled privileges could be
restored, (apparently, there was no procedure for correcting errors of this
sort).  Finally, some weeks later, Pat found that all of Pat's accrued vacation
days had been reset to zero!

wrong 800 numbers

Steven W. Grabhorn <>
13 Jan 90 07:09:29 GMT
Here's a short article on the risks of having an 800 number.

The 1/12/90 San Diego edition of the Los Angeles Times had the following
article (first, a little background, Joan Kroc is having trouble finding a
buyer for the San Diego Padres):

     It started with a joking headline on Times sports editor Dave Distel's
column on Thursday: "Have a Credit Card Ready and Call Now! 1-800-BUY-PADRES."
Richard Cole, co-owner of Emslee Products of Cleveland, Ohio, is not laughing.
His company sells sanitary napkins.  Its number is 1-800-BUY-PADS.  "Our phone
has been ringing all day," Cole said. "My secretary can't get any work done,
I'm losing orders, I'm paying 12 cents per minute for every call, what in hell
are you people doing out there?"  [...]

Steve Grabhorn, Code 645, Naval Ocean Systems Center, San Diego, CA, 92152

Password Sharing

Wed, 10 Jan 90 21:36 EST
  It's the careless attitude that a computer password is no different than a
house key that literally opens businesses and government to fraud and espionage.
  The difference between loaning someone your house key and you passwordd is
simple.  You own your house (or the bank does :) ), but your password and the
resources that it protects are not yours, or yours to lend.
  In addition, one loaned password can affect many people, even an
organization, if abused - or misused, for that matter.
  Lending and trust are key concepts in a democratic society, and
important in social interaction.  Yet in the electronic society that we
live in, where a single password can affect people's lives, prudence
and adherence to good security policies are just as important.

         Dave Bafumo

Rochester Institute of Technology   Criminal Justice/Computer Science (Student)

call for papers for computer security foundations workshop

Wed, 10 Jan 90 17:28:31 EST
                   CALL FOR PAPERS

                June 12-14, 1990
            Franconia, New Hampshire

The purpose of this workshop is to bring together researchers and
practitioners in computer security to examine current theories of
security in computing systems, with attention to the system models that
provide context for such theories and techniques for verifying security
as defined by these theories.

The workshop will include paper presentations, panel sessions, and
participation in working groups. Papers and proposals for both panel
sessions and working group problems are solicited in any application of
formal methods from computer science, mathematics, and logic to
computer security.  Possible topics include security models, covert
channel definition and analysis, information flow, access control,
secure protocols, and verification techniques.

Instructions for Participants:  Workshop attendance will be limited to
thirty-five participants.  Prospective participants should send four
copies of a paper, panel proposal, or working group proposal to John
McLean, Program Chair, at the address below.  Submissions must be
received by February 15, 1990.  Participants will be notified of
acceptance by March 15, 1990.  Papers will be published in a
proceedings that will be available at the workshop.

            Program Committee:

      Janice Glasgow    Daryl McCullough    Jon Millen
      Bob Morris    Ravi Sandhu     Marv Schaefer

For further information contact:

    General Chair:              Program Chair:
    Tom Haigh                   John McLean
    Secure Computing Technology Corp.       Code 5540
    2855 Anthony Lane, Suite 130        Naval Research Laboratory
    St. Anthony, MN 55418           Washington, DC 20375
    (612) 782-7145              (202) 767-3852 

            Publications Chair:
            Bill Young
            Computational Logic, Inc.
            1717 W. 6thSt, Suite 290
            Austin, TX 78703
            (512) 322-9951

Please report problems with the web pages to the maintainer