The RISKS Digest
Volume 2 Issue 13

Thursday, 20th February 1986

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Dec. 8 cruise missile failure caused by procedural problems
Martin J. Moore
o Computerized voting
Matt Bishop
o Non-science quotations on Plutonium
Bob Ayers
o Software Piracy
o Air Force Security Safeguards
Stephen Wolff
o Shuttle Safety
NYTimes News Summary
o Info on RISKS (comp.risks)

Dec. 8 cruise missile failure caused by procedural problems

"MARTIN J. MOORE" <mooremj@eglin-vax>
0 0 00:00:00 CDT
Last December 8, a Tomahawk cruise missile was launched from a submarine in
the Gulf of Mexico.  It was intended to fly around southern Alabama and the
Florida panhandle and then crash onto the Eglin AFB reservation; however,
about 9 minutes into the flight the missile made a sudden right turn and
crashed outside the reservation near the small town of Freeport (the
residents of Freeport were less than amused.)  No explanation for the failure
was given until an article in the 2/20 issue of the "Playground Daily News"
[Fort Walton Beach, Florida].  The article says in part:

   Human error caused a malfunction that led to the errant flight and
   subsequent grounding near Freeport of an unarmed cruise missile on
   a test flight two months ago...Newly released information shows that a
   "procedural problem" involving the missile's computer guidance system
   caused the malfunction [according to a Navy spokesman]...He said the
   middle portion of a launch-fly-recovery program guidng the sophisticated
   missile was erased when the launch crew loaded the information into the
   missile's memory banks too quickly.  As a result, the missile went from
   the launch mode straight to the recovery mode "without going through the
   most important part of the mission"..."That's what caused it to make the
   unscheduled turn," he said.  "It was not the missile's fault.  It did
   exactly what it was supposed to do."..."It was not a mistake.  In reviewing
   the procedures we can see how it happened.  Since then, new directions and
   new procedures have been instituted."

Old saying:     If all else fails, follow the instructions.
New corollary:  If you follow the instructions, you can't make a mistake.
                (or, "I was only following orders, Your Honor.")

Computerized voting

Matt Bishop <mab@riacs.ARPA>
19 Feb 1986 0804-PST (Wednesday)
   Unfortunately, I'm not in Massachusetts, so I won't be going to Ms.
Waskell's lecture on computerized voting.  But ever since I heard about
the electronic tally board in some legislative house (I think the U.S.
House of Representatives), I've been interested in the safeguards.
The method used involved the legislators pushing one of two buttons at
their desk (one for "yea", the other for "nay").  Well, it seems that
some legislators pushed buttons for colleagues who were absent and who
did not know how they were "voting"!

   Now, this story may be apocryphal (since I don't remember the
source, you might as well take it with a grain of salt) but it does
bring up a point I've not heard addressed.  If you use an electronic
"ballot puncher" (as opposed to manually punching the cards then
counting them electronically) how can you ensure the ballot is punched

   So, my questions to this group:  Anybody know if all electronic
voting schemes used at election time require manually punched ballots?
If not, what tests are the electronic "ballot punchers" subjected to
in order to test their reliability?  (I gather there can be no precautions
against someone voting for someone else other than careful checks at
the precinct, by the precinct workers.  Opposing comments welcome!)

Non-science quotations on Plutonium (Risks 2.12)

Ayers.PA@Xerox.COM <Bob Ayers>
19 Feb 86 11:00:20 PST (Wednesday)
From Risks 2.12:
    "In a worst possible case, you could double the entire worldwide
     burden of plutonium in the atmosphere."
        Robert K. Weatherwax, head of Sierra Energy and Risk Assessment

I find this quotation silly and non-science. Here are two meanings for
his sentence:

  1. The accident could double the instantaneous weight of Pu in
     the atmosphere.

       So what? Weatherwax supplies no figure for the current atmosphereic
       Pu burden, and no figure for that burden's harm or risk.
       Anyone know what the current level of Pu is? If its one femtogram, or
       even one milligram, who cares what "doubling" it does?

  2. The accident could double the amount of Pu that has been added to
     the atmosphere by man.

       That's probably what Weatherwax wants you to read into his sentence.
       And its clearly silly, because when an above-ground Pu atom bomb goes
       off, MOST of the 10-20 kilogram critical mass of Pu goes into the
       atmosphere. Considering the number of above-ground bombs tested, this
       would mean that the "accident" involved at least a tonne of Pu!

Look at the loaded words: "double" "entire" "worldwide".  Would his sentence
have changed meaning if he had simply left out the words "entire worldwide"?
No, but it wouldn't have sounded like a drum-roll was being played in the
background.  This isn't science, guys, this is politics — or silliness.

           [If we horse around a little, we might get to Whinny the Pu.  PGN]

Software Piracy

Thu 20 Feb 86 16:34:11-EST
   In Risks-2.11, I noticed that it was suggested that one way that software
manufacturers combated software piracy was by providing various "extras"
with their software packages which supposedly enhance the value of the
product. To an extent, this is true, and I will grant that those who are
really interested in a said game (business software is another matter) will
purchase it rather than copy it because of the extras and the value that
they provide during the playing of the game. However, I submit that the vast
majority of computer users are only casually interested in a certain "new
game", and because of this will not be too deterred by the lack of colorful
maps or cute little clues which are provided with the game. These can easily
be described or listed in a small and easily written text file, and
distributed all over the US and Canada with the actual "cracked" game that
is being pirated. Thus, these objects included with the software are only a
deterrent for the interested player, who probably buys most of his software
anyhow. Software companies do not loose money due to these people, rather,
it is the software trader who seeks to get new software at a regular rate
(which with a modem is exceptionally easy to do) who is the main threat to
software company profits, and large cloth maps and parchment instructions
thrown in to the software package are of little interest to some one who can
easily get the complete instructions and contents of the "extras" all typed
up in a neat little text file. This also goes for games like "Captain
Goodnight", which sought to deter piracy by having a set of codes, which if
not used properly in various sections of the game, would cause the program
disk to reboot (Apple version). However, it was just as easy to type up the
chart that the software manufacturer provided and include it with the
program on the same disk. Versions have even been circulated where the
section of the program that asks for your 'ID code' is taken out, and the
game proceeded as if the user had typed in the right code.

   One further thing - Another notable software manufacturer which is reputed
for their software protection policy is Beagle Brothers, who provide valuable
utilities and some games for the Apple which are unprotected and at a
much more modest cost then most of its competition.

D.Reuben                      Reuben@Weslyn.Bitnet (or Reuben@Weslyn.Arpa)

Air Force Security Safeguards (RISKS-2.12)

Stephen Wolff <steve@BRL.ARPA>
Wed, 19 Feb 86 4:10:21 EST
>   Subject: Security Safeguards for Air Force Computer Systems
>   "WASHINGTON (UPI) - . . . .
>      The Air Force Audit Agency, which inspected eight bases, sharply
>   criticized officers at each facility for failure to inspect safeguards,
>   such as lead boxes designed to limit electromagnetic signals emitted
>   by the equipment..."

Bet the spells to ward off evil spirits weren't current, either.

                     [If you think that Steve's remark is off the
                      mark for the RISKS Forum, you could be wrong.
                      But no spirited follow-ups, please.  PGN]

Shuttle Safety

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 20 Feb 86 16:51:02-PST
c.1986 N.Y. Times News Service: news summary for Thursday, February 20, 1986

    Washington - NASA's technical experts reviewed the shuttles' booster
rocket sealing problems last August without considering the impact of
cold weather on the seals or giving much attention to the possibility
that launchings should be delayed while the seals were strengthened,
according to a key participant in the top-level review and recently
released documents. The participant, William H. Hamby, deputy director
of shuttle program integration, described in an interview a history of
rising concern over the rocket seals.

    New York - Shuttle safety margins were cut to adhere to an
accelerating launching schedule, according to space agency documents
made public by the chairman of a House panel. The chairman, Rep. Edward
J. Markey, D-Mass., said the actions, coupled with the explosion of the
Challenger, raised basic questions about the safety of the shuttle
design and precautions by the space agency.

Please report problems with the web pages to the maintainer