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 3 Issue 03

Friday, 6 June 1986

Contents

o Watch this Space
Eugene Miya
o Unshakeable Faith in Technology
Herb Lin
o SDI as a defense against terrorists?
Bruce Wampler
Martin Moore
Bernie Gunther
o Basis for SDI Assumptions?
Herb Lin
o Info on RISKS (comp.risks)

Watch this Space

Eugene miya <eugene@ames-aurora>
5 Jun 1986 1910-PDT (Thursday)
The following is a personal observation and not an opinion of my employer.

Next week the President's Commission will be reporting its findings on the
Challenger incident.  Already leaks have occurred, and I find some of them
in Time magazine.  While I cannot completely comment on the bureaucracy
problems in NASA, it is interesting to note that part of the solution to the
launch decision problem is adding more members (contractors and astronauts)
to the final launch decision process.  There is an irony to that.  One on
hand we have been trying to reduce bureaucracy, to make committees smaller,
and so forth, and one would ideally have astronauts and contractors
"represented" by a "good" bureaucrat, and yet the solution is to increase
the size and complexity of some committees.  Yes, safety should be first,
but how do you achieve safety?  Or should I say achieve safety and balance
it with complexity?

This complexity actually has another system to compare it to: SDI.  I don't
want to completely open a can of worms, but we should keep our eyes open on
this other space program and see how it handles complexity in contrast the
to manned space program.  Several weeks ago, Danny Cohen at USC-ISI reported
somewhere (I thought it was Science, but I saw it in stronger language) that
SDI developers (i.e., the aerospace community) have been very conservative
about their use of computers and that SDI needs the state-of-the-computing-art.
Cohen said something to the effect that we have to push aerospace companies
to use the most advanced computing techniques available.  Space companies
have always tried to use tried-and-true technologies and have varied them
only one slow degree at a time.  I would like to point out to the
readerships of both the space and risks digests that these two different
forces are now acting upon companies like Lockheed, Rockwell, and so forth,
and it will be interesting to watch how they develop.

Both systems are quite complex, conservative to some degree, but supposedily
diverging forces are pushing for more conservativism and less conservatism.

From the Rock of Ages Home for Retired Hackers:

--eugene miya
  NASA Ames Research Center
  eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  {hplabs,hao,dual,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene


Unshakeable Faith in Technology

<LIN@XX.LCS.MIT.EDU>
Thu, 5 Jun 1986 09:35 EDT
A small consolation is that the SDI advocates no longer use the
Shuttle as an example of the finest in American technology.


SDI as a defense against terrorists?

Bruce Wampler <unmvax!wampler@ucbvax.Berkeley.EDU>
Thu, 5 Jun 86 09:58:58 mdt
    Offense is much easier than defense.  The mention of terrorists
brings to mind an obvious BIG hole in the whole SDI concept.  If I were a
terrorist (or even the USSR after some SDI was in place), I'd take a serious
look at the wide open U.S. society, the thousands of miles of shoreline and
the leaky borders with Mexico and Canada.  Why bother trying to get through
a massive defense system (as unreliable as it might be) when you can land a
boat or drive a pickup across the border with a nuclear device and plant it
under City Hall in Anytown, USA?  And if anyone has any doubts, just take a
look at the unstoppable influx of drugs and illegal aliens.

    Maybe what SDI should really be is a big perimeter around our
borders to stop such things.  Now if someone can just get the algorithm
to distinguish heroin, aliens, and plutonium...

Dr. Bruce E. Wampler
University of New Mexico
Department of Computer Science
Albuquerque, NM 87131

..{ucbvax | seismo!gatech | ihnp4!lanl}!unmvax!wampler


SDI as a defense against terrorists?

<mooremj@eglin-vax>
6 Jun 86 08:25:00 CDT [Hooray. A Date Appears!]
At the risk of beating a dead horse, I would like to take issue with this
statement by Bob Estell:

>That shield might save 75% of the population in a terrorist attack, launched
>by an irresponsible source; this is far more likely than a saturation attack
>by a well armed power like the USSR.  

The risk of such an attack (a terrorist attack with an ICBM) is nearly 
nonexistent.  In the first place, it is a lot easier and cheaper to perform
a terrorist attack, even a big one, with nothing more exotic than conventional
explosives; consider, e.g., the destruction of the two main water conduits 
serving New York City (I just read a mediocre novel with this as its premise.)

Secondly, even if the terrorists decide to go the exotic route, chemical or
biological weapons are much easier to produce (or otherwise obtain) and 
deliver.  Several years ago someone mailed packages of white powder to various
DoD sites.  The powder was the crystalline form of Lance, a nerve gas; tasting
the powder would cause instant death and smelling it would cause permanent
brain damage.

Thirdly, even if the terrorists decide they just *have* to use an atomic bomb,
it is much more practical to either build it in place (see "Build Your Own
A-Bomb and Wake Up the Neighborhood" by George W. Harper in the April 1979
issue of _Analog_) or to deliver it by more conventional methods (probably
ship, but possibly airplane.)  It is much harder to build an effective
ICBM than it is to build an effective A-bomb; a crude bomb will still do the
job, but a crude ICBM will most certainly miss your target, assuming that it
doesn't blow up in your face first. 

Finally, even if the terrorists somehow managed to obtain a few missiles
with H-bombs attached, nowhere near 25% of the US population would be 
endangered.  At a guess, the smallest area containing 25% of the population
would be the entire Boston-Washington strip, with Los Angeles, Chicago, and
Atlanta (I've never liked Atlanta) thrown in for good measure.  It would
take a *lot* of bombs accurately delivered to kill 25% of the population.
Furthermore, as Herb Lin pointed out, the technology is already there to
defend against limited attacks.

                Martin Moore (mooremj@eglin-vax.arpa)


SDI as a defense against terrorists?

<mck-csc!bmg@EDDIE.MIT.EDU>
Fri, 6 Jun 86 10:47:36 EDT
Libya will soon be able to buy an ICBM from Brazil.  I read this in a
recent article in either Time magazine or the New York Times.  

How about a single missle from Cuba?

Bernie Gunther



<LIN@xx.lcs.mit.edu>
Fri, 6 Jun 1986 09:23 EDT
        arms-d@xx.lcs.mit.edu
Subject: Basis for SDI Assumptions?
ReSent-To: risks@SRI-CSL.ARPA

    From: bcsaic!douglas at uw-june <Doug Schuler at uw-june> [...]
    What is the story on the software for the Sargent York gun?  Was a "high
    level" language used? If so, and the complexity still defeated the project,
    it bodes ill for SDI which consists of [the logical equivalent of?]
    thousands (hundreds?) of Sargent York guns launched into space.  If a
    high-level language was used, there is still life in the "historical"
    argument described by Bob Estell.

I don't think the Divad failed because of software, if software is
construed in the narrow sense of improperly written lines of code.
However, the problem WAS a system integration problem, and thus does
have some relevance to software issues.  The stated reason for Divad's
failure was that it was unable to hit Soviet choppers at long enough
range.

Consider the time that Divad shot at a latrine fan during a test, looking
for the rotating blades of a helicopter.  The Divad radar looked for a
particular Doppler shift in the return signal, and you can imagine how the
fan could mimic a helicopter blade.  Is this a software problem?  It seems
to me that you could argue it both ways, but in either case, I don't think
the presence of a high-level programming language would have helped.

     [Flawed algorithms often appear as "undependable" software, although
      they can of course equally well be embedded in hardware.  We should 
      not try to make too much of the hardware-software distinction.  The
      "blame" usually rests on the shortcomings of the designers and 
      implementers...  PGN]

Please report problems with the web pages to the maintainer

Top