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 7 Issue 52

Wednesday 14 September 1988


o Tom Wicker column on computers, Vincennes and SDI
Gary Chapman
o Computer error in vote tallying
Gary Chapman
o Risks of Using Computers in Elections
o Soviet Space Probe
Dave Feldmeier
o Re: "Single keystroke"
Matthew P Wiener
o London Underground problem
Lindsay F. Marshall
o Re: Destructive Remote Controls
William Curtiss
o An ANI Compromise
Mike Linnig
o +++ RISKS Guidelines revisited +++ [<<<PLEASE READ THIS.<>>]
o Info on RISKS (comp.risks)

Tom Wicker column on computers, Vincennes and SDI

Gary Chapman <chapman@csli.Stanford.EDU>
Tue, 13 Sep 88 15:39:05 PDT
Tom Wicker, the famous columnist for the New York Times, has a column in the
Times today about computers, the Vincennes incident, and the SDI.  Wicker
has picked up on a story John Markoff has been working on for some time, on
whether complex computer networks exhibit chaotic behavior similar to the
mathematical phenomenon of chaos found in nature.  Wicker says that "these
two events [the Vincennes and a problem with a TRW computer that John de-
scribed in one of his articles] were unrelated except that they offer a com-
mon warning against too complete reliance upon computers and electronic
systems as substitutes for or multipliers of mankind's innate abilities."

". . . Star Wars will be heavily dependent upon a vast network of sensors,
computers and electronic weapons guidance systems girdling the globe and
only nominally under human control.

"Given the likelihood of breakdown at any of thousands of points in a system so
complex that no one has been able as yet even to design the software, it takes
a leap of faith to believe that the SDI would increase national security
against attack.  More likely, aping the computers at your local bank or an
airline ticket counter, the system would be 'down' when most needed."

Wicker then goes on to speculate on the dangers of an SDI computer system
subject to chaotic behavior.  Wicker quotes a professor of electrical engi-
neering at MIT, William Schreiber, who notes that the Aegis system in the Gulf
was at least responding to something that everyone on board had been trained to
deal with and had probably actually seen, i.e., a commercial airliner radar
signature.  What will happen with SDI or ICBM crews who are presented with
something no one has ever seen before?

"Not only may these high technology systems fail, or degenerate inexplicably
into chaos, and be more prone to do so as they grow ever more complex;
even when they function properly, the responses of the fallible human beings
who may have to interpret their messages can be disastrous--and humans may
be progressively less fit for a job so demanding.

"Thus, as we move inexorably into the world of high technology and control by
computer, the undeniable benefits will not come cheaply.  For mankind's
enhanced capacities, the price may be that we diminish, rather than increase,
what little dominance we have of our own destiny."

Computer error in vote tallying

Gary Chapman <chapman@csli.Stanford.EDU>
Tue, 13 Sep 88 15:24:27 PDT
The New York Times reported today that a computer entry error increased the
vote count for the incumbent Lieutenant Governor of Delaware, S. B. Woo, and
made it appear he had won the election when he may have lost.  The correct
number of votes in one district was 28, but the operator keyed in 2,828 by
mistake.  There will be a recount of the votes statewide.

Risks of Using Computers in Elections

Peter Neumann <>
Tue, 13 Sep 1988 16:31:50 PDT
I noted in the July issue of the ACM Software Engineering Notes that there was
a panel discussion at COMPASS '88 on the topic of computer systems for counting
ballots.  Two of the panelists have written reports that deserve mention here:

  Lance J. Hoffman, ``Making Every Vote Count: Security and Reliability
  of Computerized Vote-Counting Systems'', Department of Electrical
  Engineering and Computer Science, The George Washington University,
  Washington D.C. 20052, 2nd printing, March 1988.

  Roy G. Saltman, ``Accuracy, Integrity, And Security In Computerized
  Vote-Tallying'', Institute for Computer Sciences and Technology,
  National Bureau of Standards, Gaithersburg MD 20899, NBS Special
  Publication, June 1988 (draft). 

These two reports are absolutely essential reading for anyone interested in the
problems arising in election software.  There is also a paper by Erik Nilsson
("A Bucket of Worms") on this subject, in the proceedings of CPSR's DIACS 88.

Soviet Space Probe

Wed, 14 Sep 88 09:00:46 EDT
A friend of mine who does satellite work expressed surprise that the Soviets
could lose a space probe so easily.  Apparently, US craft have a "panic"
mode that takes over if there is some problem (presumably in this case the
batteries running low).  The probe then realigns itself so that its solar
panels face the sun, its antenna faces the Earth and it waits for new
commands.  This seems like the right idea, but I don't know much about how
it works.  For instance, are the panic commands in ROM so that they can
never be overwritten?
                                        Dave Feldmeier

Re: "Single keystroke"

Matthew P Wiener <>
Tue, 13 Sep 88 22:39:01 pdt
On Unix, even experienced users can do a lot of damage with "rm".  I had
never bothered writing a safe rm script since I did not remove files by
mistake.  Then one day I had the bad luck of typing "!r" to repeat some
command or other from the history list, and to my horror saw the screen
echo "rm -r *" I had run in some other directory, having taken time to
clean things up.

Maybe the C shell could use a nohistclobber option?  This remains the only
time I have ever rm'ed or overwritten any files by mistake and it was a
pure and simple gotcha! of the lowest kind.

Coincidentally, just the other day I listened to a naive user's horror
at running "rm *" to remove the file "*" he had just incorrectly created
from within mail.  Luckily for him, a file low in alphabetic order did
not have write permission, so the removal of everything stopped early.

ucbvax!garnet!weemba    Matthew P Wiener/Brahms Gang/Berkeley CA 94720

London Underground problem

"Lindsay F. Marshall" <>
Wed, 14 Sep 88 13:46:43 WET DST
According to the news on the wireless this morning the London Undergound
system was distributed by a power failure that had damaged "the computer".
This system appears to control all the lifts, escalators and signals!!
Anyone know what really happened??

Re: Destructive Remote Controls

Tue, 13 Sep 88 20:54 EDT
Jim Williams writes of a remote control at a hotel which had the ominous
warning on it:

   "This remote control will only work on Beeblebrox Hotel TVs.
    REMOTE WILL DAMAGE your home TV sets."

He then asks if this is indeed possible.

I believe that it is entirely possible.  The control signals for the remote
could be chosen in such a way that the "on" control would send a command stream
that would be interpretted by a home TV set as "on" immediately followed by
"off".  Such cycling of the power will quickly damage the power control circuit
and send spikes to the rest of the components.  Most TVs require some form of
delay between an "on" and an "off" (actually, they are the same code, the TV
just changes state) but this could easily be accounted for.

For those doubters, I heard of a "crt saver" for the IBM a long time ago that
actually destroyed the monitor.  It would cut one of the locking frequencies (I
believe that is how it worked) which would make the sceen appear blank, but
would allow a charge to build on a capacitor.  Eventually the capacitor failed
and took the rest of the monitor with it.
                                                   William Curtiss

An ANI Compromise

Tue, 13 Sep 88 17:37:47 CDT
> The `privacy' argument has two sides....  it is the right of an individual
> *not* to have their phone number displayed, but it is also the right of the
> individual *not* to answer anonymous calls.  A problem to which the solution
> seems easy enough....  (now prove otherwise!)

[1] Suppose that all business phones had to "send" their phone numbers by law.

[2] Callers TO business phones have the right to withold their numbers
    using a prefix.  

[3] Individual-to-individual calls would "send" their phone numbers unless
    a prefix was used.

[4] Individuals COULD have their phones set up so that any non-ANI calls
    would be rejected (with a recording saying why).

[5] If you dial a number with a prefix, you get a recording if the target
    of the call ALWAYS gets ANI (e.g. the police emergency line); the
    call will complete at the callers option.

I suspect most folks would opt for [4] on their home phones.  This
should cut down on the number of obscene calls.  AIDs hot lines
can be called with the prefix -- the caller knows their number is
not being traced because they did not get a recording.  Callers to
businesses know their number is not being traced if they used a prefix.

Does that solve some of the problems?
                                          Mike Linnig, Texas Instruments

RISKS Guidelines revisited [*** PLEASE READ THIS. ***]

Peter Neumann <>
Tue, 13 Sep 1988 17:13:19 PDT
In the interest of keeping RISKS stimulating, and minimizing the mass of
suboptimal submissions, this is a reassertion of and elaboration upon a few of
the masthead guidelines, from mechanical to contextual.

  CONCISE: Short contributions are strongly preferred, assuming they satisfy 
  the other criteria.  Long ones may wait indefinitely, unless they are very
  hot. I would rather not have to impose a default limit, but would like to 
  urge consideration on your part.  Think of all the times you have had to 
  struggle with reading someone else's overly long messages that wandered 
  illogically, and try not to write that way.

  NONREPETITIOUS: Messages that go over the same ground as previous messages
  (including this one!) place a serious burden on all of us.  I cannot remember
  every contribution, but try very hard to minimize repetition.  Please try to
  check over previous issues before you fire off your comments.  When you
  relate to back issues, do so explicitly.  Messages that blindly incorporate
  an earlier message in its entirety (particularly when it is long) are very
  annoying.  Yes, I tend to delete most of the repeated portions, but you might
  better do that yourselves.  Interstitial annotations that comment almost
  paragraph by paragraph on the earlier messages are generally not very
  interesting anyway, so avoid those altogether.  (By the way, I usually keep
  reconsidering not-yet-included but still-possibly-interesting messages for
  several days until they eventually fall off the end of my attention span.
  However, I do not usually send out rejection notices, and trust the network
  servers to help you distinguish between that case and the case in which your
  mail was never received -- although that may not be a reliable process for
  some of the networks.)

  COHERENT: Writing skills are difficult to master.  But PLEASE take care in
  formulating your thoughts.  It makes your contributions much more readable,
  and saves agonizing back-and-forths later.  I hate playing English professor,
  but I cannot believe how bad some of the submitted writing is.  (I do edit
  when it is flagrant.)

  RELEVANCE: By now you know that I have a broad interpretation of "computers
  and related systems".  But I still get lots of contributions that are clearly
  not relevant.

There are a few of you RISKS contributors whose messages have been reliably
relevant, sound, concise, etc., and who always assume other readers are smart,
honest people with good intentions.  Many thanks to you.  I hope that others
will try harder to emulate you.  As a reward for you, this relatively boring
message is placed last in the issue (just in case you didn't get this far) --
in the ongoing struggle to make RISKS readable.  (For some others, however, it
probably should have been placed FIRST.)

Thanks to all RISKS folks for your support and help over the past three years.
The feedback I get seems to indicate that it is worth the effort to continue.

Please report problems with the web pages to the maintainer