The RISKS Digest
Volume 3 Issue 06

Thursday, 12th June 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 Risks from inappropriate scale of energy technologies
Michael J. Natkin
o Shuttle Software
David C. Smith
o An additional SDI problem: sensor technology
Eugene Miya
o Privacy in the electronic age
Dave Platt
o Sgt York software
Larry Campbell
Mark Vilain
o Info on RISKS (comp.risks)

Risks from inappropriate scale of energy technologies

"Michael J. Natkin" <mjn%brown.csnet@CSNET-RELAY.ARPA>
10 Jun 86 (Tue) 23:46:50 EDT
  One of the most important categories of long term risks to the public
from technology seems to have been overlooked in Risks so far.  The
assumption that more technology is automatically good is so ingrained
in our thinking that it is hardly questioned.  We measure our welfare
in terms of Gross National Product, not by how many people have enough
to eat, or by distribution of income.

  In particular a vast amount of our technical, capital and human
resources are expended developing monolithic energy technologies
without regard to end use needs. The public has long been duped into
the idea that centralized energy management has it's best interest in
mind as we develop ever increasing electrical capacity. But centralized
reactors and other "hard" technologies are extremely susceptible to
terrorist attack and other failures, as has been mentioned before.

  The public has been told that it doesn't have the expertise to make
decisions about such high risk high technologies as SDI and nuclear
power, and in some sense this is true. But the technocrats have
preempted the public's right to make the moral and political policy
which guides the choices.

  I think that we should be pursuing a policy course which develops
technology that can be put safely in the hands of non-technical people.
This might take the form of small burners which use the methanol from
organic wastes, windmills, or non-electrical solar collectors, to name a few
possibilities.  Localized, distributed technologies have many advantages,
including ease of repair, localization of risk from outage, and major
reductions in distribution losses and cost of distribution equipment and
labor. I strongly recommend Amory Lovins' "Soft-Energy Paths" to others
interested in issues of appropriate scale in technology.

       Michael Natkin
CSnet: mjn@brown
 ARPA: mjn%brown@csnet-relay
 UUCP: ...!{allegra,decvax,ihnp4}!brunix!mjn

Shuttle Software

David C. Smith <DCSmith@SRI-AI.ARPA>
Wed 11 Jun 86 08:55:30-PDT
The cover story of the September, 1984, CACM is "A Case Study: The Space
Shuttle Software System".  As with other CACM case studies, this one is
a discussion, or interview, with several people involved with the subject
matter, in this case 6 individuals from the IBM Federal Systems Division.
An Outline of the Interview included in the article contains:

  Project Overview
  The Shuttle Computers
  Project Organization
  Testing Facilities
  Detailed System Operation--No Redundancy
  Redundant Set Operation
  System Problems
  The Interprocess Variable Problem
  Concluding Remarks

The issue also contains several other articles in a Special Section on
Computing in Space, including "Design, Development, Integration: Space
Shuttle Primary Flight Software System", written by 2 senior technicians
from the IBM FSD.

It seems like a good place for a novice to the shuttle and its systems
(like myself) to get some basic information about the shuttle computers
and the complexity of the systems.

Dave Smith

An additional SDI problem: sensor technology

Eugene Miya <>
11 Jun 1986 1124-PDT (Wednesday)
The view expressed within are the view of the author and not of my agency
nor of the Federal government.  ------------------------------ A lot of
interest has been expressed regarding the focus of the problems of SDI: the
software, in particular battle management.  Note the Science article of May
9 1986.  However, I wonder about the other components of the system.  Where
there are various groups watchdogging computing, but the more hardware
oriented, EE areas such as radar have fewer opposition elements. Recent
postings on cruise missiles and the integration of DIVAD move me to post this.

Sensor technology is one area which worries me.  SDI battle management
makes certain assumptions about the ability to detect and identify targets.
I think that most computer people don't understand the nature of radar
to worry about the problems of `target' detection and ranging.  That is
all that radar is: detection (boolean) and ranging (distance=rate times
time). A first starting references is Skolnick's text on Radar. (Dated)

Inherent problems with a ranging system include: Range and azimuth
ambiguities, difficulties with empirically determined signatures.  Most
people don't seem to understand that knowing the geometry of systems are
important.  Satellite images [some radar maps to be used in offensive
missiles] are not photographs (you must call them images) because their
geometry is from a linear and not a point perspective, so distance
determination for things like cruise missiles cannot be done using a
straight edge.  Radar (simple) is like looking at the world using a
monochromatic spot light from the point where you are looking: you don't get
shadows (an important distance cue).  Note: I have not talked about clutter,
or noise (ever wonder how high speed jets detect jets from ground objects,
or how AWACS which points down get insignificant ground objects cleared?).

While there exist solutions, all of them involve tradeoffs in complexity,
cost, and new emergent problems.  Solutions in Doppler systems,
phased arrays, stereo transmit/receive systems, but just the inherent
simplicity of the concept and the over-generalization of use worries me.
This is a case where "high-level language" solutions may not be

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA

Privacy in the electronic age

Dave Platt <Dave-Platt%LADC@HI-MULTICS.ARPA>
Wed, 11 Jun 86 10:47 PDT
A news clipping from this morning's "Los Angeles Times" (page 2, The News
in Brief):

   The House Judiciary Committee voted 34 to 0 for a bill seeking to
   bring constitutional guarantees of the right to privacy into the
   electronic age.  The legislation would extend laws that now protect
   the privacy of the mails and land-line telephone conversations to also
   cover electronic mail and some telephones that use radio waves.
   The bill was cleared at the request of Rep. Robert W. Kastenmeier
   (D-Wis.), chairman of Judiciary's subcommittee on courts, civil
   liberties and administration of justice.

Anyone know the details?  Just what privacy coverage would be afforded
by this bill in its present form?  How would the bill's provisions
affect the sysops of private electronic bulletin-board systems, for
example?  Would this bill clarify the legal standing of electronic
transactions and messages re their use as evidence in court?

     [Very strange.  RISKS-3.1 noted that the House sent a bill to the 
      Senate on 3 June that covered "federal interest" computers.  Is this
      an additional bill, or a modification of one already sent over?  
      Maybe someone in the House is reading RISKS and noted the apparent
      flaws in the bill that I mentioned in RISKS-3.1?  PGN]

Sgt York software

Wed, 11 Jun 86 01:52:39 edt
In RISKS 3.4, Mike McLaughlin (mikemcl@nrl-csr) and Ken Laws (laws@sri-ai)
dispute the Sargent York latrine fan story. [...]

I quote from a story by Gregg Easterbrook in the November 1984 issue of
_The Washington Monthly_:

    During a test one DIVAD locked on to a latrine fan.  Michael Duffy,
    a report for the industry publication _Defense Week_, who broke this
    aspect of the story, received a conference call in which Ford officials
    asked him to describe the target as a "building fan" or "exhaust fan"

_The Washington Monthly_ and _Defense Week_ are both reputable publications.
Does anyone have a citation for a retraction in _Defense Week_, or should we
assume that the TV networks swallowed Ford's story whole?

Larry Campbell                             The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     (617) 367-6846

Sgt. York software

Wed 11 Jun 86 12:48:29-EDT
Here is some information on the DIVAD software that hasn't appeared yet in
this forum.  [It] is abstracted from a longer note compiled by Reid
Simmons from material he received from Gregg Easterbrook (both his article
in the Atlantic, and personal communications).

According to Easterbrook, the DIVAD did target a latrine exhaust fan in
one series of tests.  The target was displayed to the gunners that man
the DIVAD.  But the Sgt. York did not shoot at the latrine, or even
swivel its turret in the latrine's direction, having prioritized the
target as less important than other targets in its range.

In another series of tests (Feb. 4 1984), U.S. and British officials
were to review the DIVAD as it took upon a rather cooperative target: a
stationary drone helicopter.  On the first test run, the DIVAD swiveled
its turret towards the reviewing stand as "brass flashed" and the
officials ducked for cover.  It was stopped only because an interlock
was put in place the night before to prevent the turret from being able
to point at the reviewing grandstand.  Afterwards, the DIVAD shot in the
general direction of the helicopter but the shells traveled only 300
yards.  The official explanation is that the DIVAD had been washed the
night before, screwing up its electronics.  Easterbrook wonders what
would happen if it rained in Europe when the DIVAD was being used.

Easterbrook goes on to claim that the snafus the DIVAD experienced were
very much due to software.  The main problem was that the pulse-Doppler
tracking radar and target acquisition computer were a very poor match.
Easterbrook claims that the hard problem for the software (tracking
fast, maneuvering planes) was easiest for the pulse-Doppler radar which
needs a moving target.  On the other hand, the hard part for the radar
(detecting stationary helicopters) was the easiest to aim at.  The DIVAD
mixed two opposing missions.

Easterbrook goes on to say that human gunners are often more successful
than their automated counterparts.  They can pick up on visual cues, such
as flap position on approaching aircraft, to determine what evasive
maneuvers the enemy might make.  These kinds of cues are not visible to
things like pulse-Doppler radars.  Further, evasive courses of action
are hard for human gunners to counter, but even harder for target
tracking algorithms (again the lack of visual cues comes as a
disadvantage).  For example, the DIVAD expected its targets to fly in a
straight line (which my military friends tell me is not too likely in a
real combat).

There is lots more to the Sgt. York story, not all of which is relevant
here.  If there is a moral to be drawn specifically for RISKS, it's
that as advanced as our technology may be, it may not always be the
match of the problems to which it is applied.  This was certainly the
case with the unfortunate DIVAD.

marc vilain

Please report problems with the web pages to the maintainer