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 46

Wednesday 22 November 1989


o ``Play it Again, Yonkers'' -- more election funnies
Steve Bellovin
o Army shuts down computers and goes home due to rain
Rodney Hoffman
o More good news -- Privacy and risks in credit information
Bill Gorman
o Automated Bank RISKS
John Howard Osborn
o Another Foretaste of the Millenium? (corrigenda)
Brian Randell
o Re: Self-trust and computer professionals
Jerry Hollombe
o Re: Congress Finds Bugs in the Software
Franklin Davis
David Gursky
o Info on RISKS (comp.risks)

``Play it Again, Yonkers'' -- more election funnies

Mon, 20 Nov 89 21:54:59 EST
I held off submitting this in the hope that someone who knew the complete story
would post it; that hasn't happened, so here's what I know.

There was a very close, and racially-charged, mayoral election in Yonkers, NY;
the challenger was rather unexpectedly reported the victor by 4,000 votes on
election night.  When the official tally was started, though, the incumbent had
picked up 1,500 votes in just 5 of the 12 precincts.  The count was suspended
for the weekend, with the voting machines impounded; when it was finished, the
original result -- and numbers -- were upheld.

What happened?  It's an old story here, I'm sure.  Before the election, the
tally program was run with test input data.  They forgot to take out the test
data when tabulating the real returns.  From the story I heard, it wasn't clear
if the error was in the official tally or in the early returns; given the
numerical result, I tend to suspect the former.
                                                --Steve Bellovin

Army shuts down computers and goes home due to rain

Rodney Hoffman <>
22 Nov 89 07:52:30 PST (Wednesday)
Roddy Stinson is a columnist for the San Antonio, Texas "Express-News".
Here's one Question & Answer from his column of Nov. 14, 1989 under the

  The complaint desk is open --

  PLAINT:  I am a retired Army sergeant.  My wife just got out of intensive
  care at Brooke Army Medical Center.  I tried to call BAMC to make a medical
appointment for her, and this is the message I got: 'The patient appointment
system cannot operate at this time.  Due to inclement weather, the computers
had to be taken down.  Please continue calling periodically.  Thank you.  This
is a recording.'  That's pitiful.  That's ridiculous.  What happened to
typewriters and phones?  If a rainstorm can shut down the country, we're in big
trouble.  I'll tell you one thing -- rainstorms didn't stop the Army when I was
in it.  They told me to keep marching, and I did.

  [Stinson:] A spokesman for BAMC explained: "This (computer shutdown) happens
every time there is a possibility of thunderstorms because the central
appointments system is linked to a mainframe a mile and a half away, and if
lightning hits the lines, everything on there could be erased."  When I
expressed skepticism, he added: "Believe me, it has happened.  Lightning takes
out our phone system and electricity on a regular basis."  Progress marches on.

More good news -- Privacy and risks in credit information

"W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET>
Mon, 20 Nov 89 13:08:34 EST
     Upon doing a routine, periodic inquiry of the local credit bureau to make
sure they have things reasonably straight on my credit report, I made a rather
disturbing discovery. The report issued to me, and presumably to whatever
business (or person representing themselves as a business) contains not only
the expected credit information, but THE NAMES, CREDIT LIMIT, ISSUERS, AND CARD
NUMBERS OF ALL MY CREDIT CARDS AS WELL! It might pay others on RISKS to find
out if this sort of thing is SOP, or merely the result of the incompetence of
our local bureau.

Automated Bank RISKS

John Howard Osborn <>
Tue, 21 Nov 89 14:41:21 CST
My bank, First Interstate, has recently implemented a handy new service.  Using
any touch-tone phone, bank customers may get information about the status of
their account at any time.  Normally, to get an account balance, the customer
must enter the amount of his latest deposit.  This provides, I feel, at least
some measure of security.  The problem is that the system also allows merchants
to check a check.  That is, will a check, for a certain amount, from a certain
account, clear at this time?  There is no security for this procedure.  The
merchant simply dials, enters the single digit code "6 - Validate a check" from
the vocal menu, enters the account number, and finally the amount.  The
computer will then return a boolean clear/no-clear.  Computer Science students
will recognize this for what it actually is: a medium for a binary search.  (At
this point I refer the interested reader to _Sorting and Searching_ by Knuth.)
The potential for abuse is obvious: Given the account number, it becomes
trivial to find the account balance.

My only shock is that the designers of the system were so casual about the
RISKS involved.

John H. Osborn, University of Texas at Austin Comp. Sci. Dept.

Another Foretaste of the Millenium? (RISKS-9.45, corrigenda)

Brian Randell <>
Tue, 21 Nov 89 10:12:20 BST
   [Brian sent me two versions of the MTS saga, part of one of which ran in
   RISKS-9.45 -- but without the explanation indicating that the MTS message
   was not from Brian but rather from someone else.  The surrounding text is
   given below, in case anyone thought that the "We apologise ..." message
   was originally Brian's.  I apology to Brian in case anyone was misled.  PGN]

The university computing service here runs MTS (the Michigan Terminal System)
on an Amdahl mainframe, which crashed mysteriously today, as did various other
MTS sites in North America, some time later. The explanation is given in the
following message which I have just received from one of the systems
programmers here.

> We apologise for the unexpected system shutdown ... [see RISKS.9-45 for text.]

I hadn't realised that there was this disadvantage to living on this side of
the Atlantic! Ah, well, it makes up for various advantages :-)

Brian Randell

Re: Self-trust and computer professionals (Fagan, RISKS-9.45)

The Polymath <hollombe@ttidca.TTI.COM>
22 Nov 89 02:49:58 GMT
}... A computer professional, on the other hand, doesn't trust them
}*because* he or she *does* understand them (and their limitations).  This also
}lead me to realize that ours is one of the few fields where we wouldn't
}necessarily trust our "product" with our lives.  That is, doctors generally
}will trust other doctors to operate on them, auto designers probably drive cars
}(8-)), etc.  Yet, a programmer probably wouldn't trust a computer-controlled
}plane or car very much (for good reason, in my opinion).  I'm not sure exactly
}what this says, except that it is still a very immature field.

One of my oldest friends is an anesthesiologist.  She put off having a
hysterectomy until she was nearly incapacitated because she knew all the things
that could go wrong during the operation.

I'm a licensed aircraft mechanic (and pilot).  If you knew what I know about
mechanics you'd think twice about getting into an air liner (though I do fly
when necessary).  I stay away from helicopters, except for emergency
situations, because I know just how complex and fragile they are.

I wonder how many other experts in life-critical systems could scare us with
their specialized knowledge.

The Polymath (aka: Jerry Hollombe,,
Citicorp(+)TTI 3100 Ocean Park Blvd., Santa Monica, CA 90405

Re: Congress Finds Bugs in the Software

Franklin Davis <fad@Think.COM>
Wed, 22 Nov 89 11:47:37 EST
In RISKS 9.45 David Benson quotes from a Science article by M. Mitchell
  ... But flexibility is precisely what the spell-it-out-up-
  front procurement culture lacks, says the report.  In addition,
  the bureaucracy balks at the big up-front investment in problem
  definition that must be made when the evolutionary approach is used.

These two sentences seem inconsistent to me.  What's the difference between
"spell-it-out-up-front" detailed specifications, and a "big up-front investment
in problem definition?"  There's some fuzzy thinking going on here.

I agree that it is impossible to precisely specify a large software system when
the hardware environment and functional requirements aren't frozen.  In those
situations it may be necessary to prototype the system in order to understand
the problem.

But I don't believe the software development community has reached consensus
about tossing out the waterfall method.  My feeling is that it is our inability
or unwillingness to document requirements and specifications rigorously that is
the source of most fiascos.  Maybe the government requires the wrong kinds of
details in its specifications, and doesn't adequately review them for sanity.

How will switching from "specifications" to "problem definitions," and then
hacking together a prototype which is then "evolved" solve any problems?  This
is the old method of software development that modern software engineering
methods are trying to get us out of.  Only if you throw away the prototype
might there be hope you can then specify the system correctly.

--Franklin Davis            Thinking Machines Corporation

Risks 9.45/Gov't bugs

Tue, 21 Nov 89 07:43:45 EST
  In Risks 9.45 David Benson discusses bugs in government software and
discusses some of the causes/reasons behind them.  I'd like, some day, to
actually see two notes in the forum at the same time in a scenario like: David
discusses problems with detailed up-front procurement specs and someone else
discussing the problems with less-than-complete procurement specs causing
problems.  It seems to be a no-win situation. Those up-front specs didn't come
out of nowhere. They were Congress', watchdogs', politician's etc. attempts to
solve a problem.  In typical Congressional ways, they use atomic weapons to
kill flies(!).  Each line in those regulations was probably the result of some
(comparatively) trivial screw up.  It has since cost us multiple orders of
magnitud more to "fix" the problem than to let it alone.

  David's suggestion to abandon the waterfall approach to software
design is good, but it carries the rather large risk that if it
doesn't happen to work ONE TIME, you might get a "Golden Fleece" award
and have your career dead-ended.

  As an interesting aside, I found issue 9.45 to have more meat in it than many
in a long time.  David's discussion, and the discussion of technology vs.
policy is what this forum needs more of.  Maybe the recent chastisers have had
a good effect.  Thanks.

Re: Risks in RISKS???

David Gursky <>
Tue, 21 Nov 89 07:37:31 EST
I noticed the following gem in David Benson's (dbenson@cs2.cs.WSU.EDU) posting
about Congress finding bugs in software...

> the Hubble Space Telescope of the B1-B Bomber, for example ...

Now I neither do work on the HST, or the B1-B, but I know something of both
systems.  I would suggest to Congress, Mr. Benson, or the author of the AAAS
article (which ought to know better), that mounting the HST on the B1-B (I
would guess as a bomb sight, having no other conceivable purpose by my guess)
is, uh, overkill?  ;-)

   [The original _Science_ article by M. Mitchell Waldrop of course says
   "the Hubble Space Telescope or the B1-B Bomber, for example ..."  PGN]

Please report problems with the web pages to the maintainer