risks@sri-csl (09/20/85)
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
RISKS-FORUM Digest Friday, 20 Sep 1985 Volume 1 : Issue 15
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
SDI Panel at 8th ICSE in London (David Weiss)
Risks to the Moderator (PGN)
Mailer Protocol Woes (Marty Moore)
Another Horror Story -- Sidereal Time Rollover (Marty Moore)
Article: Health Hazards of Computers (Ted Shapin)
Two More SDI Related Queries (douglas schuler)
CAL ID -- computerized fingerprint system (douglas schuler)
Rejections:
Either your contributions are drifting off the mark, or I must be jacking
up my standards (or both). I rejected several items this time.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: Wed 18 Sep 1985 16:51:10 EST
From: David Weiss <wanginst!weiss@nrl-css.arpa>
Subject: SDI Panel at 8th ICSE in London
To: RISKS@SRI-CSLA
Panel Discussion on the Strategic Defense Initiative at the 8th
International Conference on Software Engineering
One of the more interesting sessions at the 8th International
Conference on Software Engineering was a discussion of software for
the Strategic Defense Initiative (SDI). The moderator was Manny
Lehman and the panelists were Fred Brooks, David Parnas, and Alan
Perlis. The discussion was originally intended to be a debate, but
Fred Brooks was not willing to participate in a debate because he had
not yet reached a resolution of the issues. (I understand that
volunteers for the position of opposing Parnas in a debate on SDI
were hard to find. Dr. Brooks deserves credit for being willing to
engage in a public exploration of touchy issues about which he feels
unsettled in concert with a strongly opinionated colleague in an
effort for both audience and panel to learn more.)
The discussion started with a presentation by Parnas of the technical
reasons why reliable SDI software cannot be built. (Readers of this
newsletter will be familiar with many of the arguments put forth by
Parnas. A complete discussion in hard-copy is available from him at
the University of Victoria, Department of Computer Science, P.O. Box
1700, Victoria, B.C., Canada.)
Brooks responded with reasons why he thought we could build such a
system. His major point was that we have built similar systems in
the past. He identified the Apollo missions software as an example,
suggesting that we start with such a system and incrementally build
from it towards an SDI system, using what's learned along the way.
Perlis then added a few comments, explaining why SDI software would
be more complex than existing software and why it is of the hardest
type of software to build. His argument was that the SDI system
represents a moving target in terms of requirements and design.
Following some further discussion among the panelists the floor was
opened to technical questions from the audience.
The major place in which Parnas and Brooks seemed to disagree was
whether or not similar systems have been built. Brooks tried to use
the Apollo and Space Shuttle as examples. Parnas's point was that in
those systems everything can be predicted in advance. In an
anti-missile system, the number, shape, and trajectories of launched
missiles can't be predicted. In addition, the system must
distinguish decoys from real warheads. Finally, the defense system
itself will be under attack. As a result, realistic tests and
simulations of operating conditions for such a system could not be
conducted.
All the discussants seemed to agree that an SDI system could not be
built error-free, and that it would not be completely reliable.
Nonetheless, there were advocates of building it on such grounds as
that it would only be needed for a short time, and could be turned
off the rest of the time, or that we now place our trust in systems
that are also untested and probably unreliable.
In summary, there were no good responses to any of the questions that
Dave Parnas raised. Nonetheless, there were arguments put forth for
the construction of an SDI system on the grounds that it need not be
completely reliable.
David Weiss
Wang Institute of Graduate Studies
------------------------------
Date: Thu 19 Sep 85 17:40:08-PDT
From: Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Subject: Risks to the Moderator!
To: RISKS@SRI-CSLA.ARPA
RISKS-1.15 was ready to go out Wednesday night. Murphy hit in spades. The
SRI MICOM switch for dial-up access was unavailable for two days, and is
still down. An alternative route might have been available through the only
system that receives dial-ups directly from a split-speed modem, but that
system went down for five hours. Several other more circuitous alternative
routes all ran into broken gateway, which resulted from a power failure
Tuesday night. It would not have helped to drive back to SRI, because the
SRI-CSLA (which kept running through all this) was out of net contact as a
result of a gateway problem. All of the gurus were invisible. If you ever
get this issue, you will know that things have improved. Peter
------------------------------
Date: Tue, 17 Sep 85 07:40:58 CDT
From: mooremj@EGLIN-VAX
Subject: Mailer Protocol Woes
To: risks@sri-csl.arpa
Receiving 2 or 3 duplicate messages is a minor annoyance. Receiving over
a hundred is a *major* annoyance. A few weeks ago, a message from SECURITY
(a non-digest, re-mail distribution list) contained a record that was too
long for our mailer to handle. The result was that the message would be
transmitted from Rutgers, and our mailer would have a problem with the long
record. The message would not be successfully acked, but the mailer would
send me the partial message up to the problem. Since the message was not
acked, Rutgers kept remailing it to me. Before the Rutgers wizards flushed
the message, I had received 173 (I think) copies of the partial message;
at times I was receiving one every 15 minutes! This happened just before I
left on vacation, and I was seriously concerned about returning to work and
finding my disk quota used up by N*1000 copies of the busted message...
Marty Moore (mooremj@eglin-vax.arpa)
[I'm glad we're not the only ones! I think the protocols really
need further ruggedization. Thanks. PGN]
------------------------------
Date: Tue, 17 Sep 85 12:41:04 CDT
From: mooremj@EGLIN-VAX
Subject: Another Horror Story -- Sidereal Time Rollover
To: risks@sri-csl.arpa
How many of you real-time programmers have been bitten by time rollover at
midnight? How about *sidereal* time rollover? It happened like this:
In the late 70's I worked on the USNS Redstone, which is the primary tracking
and support ship for at-sea test launches of the Trident Submarine Launched
Ballistic Missile. I wrote a section of program which took telemetry data
from the Trident's Inertial Guidance Unit and reduced it to provide track
data. Now, Inertial Guidance is like the little girl in the famous rhyme:
when it's good, it's very very good, but when it's bad, it's very very bad.
As such, we had some fairly extensive reasonableness checks on the data.
One in particular took the data's time tag (in sidereal hour angle format),
differenced it with a reference hour angle computed at program initialization,
converted the answer to seconds, and compared this to the program's running
time. If the two times were dissimilar, the IG data was rejected. This
check worked beautifully on numerous tests, with both simulated and actual
input data.
Unfortunately, the programmer (blush, cringe, hang head in shame) completely
overlooked the possibility that the sidereal hour angle could reach 2*pi
radians and roll over during the mission. This eventually happened on a "2+2"
test launch. In a "2+2" launch, two missiles are launched close together,
then two more are launched close together after a lengthy delay. The sidereal
hour angle rolled over about five minutes before the first missile was
launched. The program decided that the IG data had a bad time tag and promptly
rejected it. Fortunately, other devices were tracking the missiles; mission
rules stated that if no track data was received for a certain period, missiles
in flight must be destroyed.
During the delay between the first and second missile pairs, I carefully --
very, very carefully -- patched the running program to disable the time check.
On the second pair of missiles, the IG data was great, which was a good
thing, because for about 40 seconds, no other device tracked them; if the IG
had also failed, the missiles would have been destroyed. If the sidereal
rollover had occurred *between* the two pairs of launches...(gulp)
The moral: the check worked great on numerous tests, until a peculiar set of
conditions occurred. When the bug bit, we were able to save the test; but
with just a small change in conditions, we could have destroyed two Trident
missiles unnecessarily. I don't know what they cost, but I'm sure it's at
least $10,000,000 each.
Marty Moore (mooremj@eglin-vax.arpa)
------------------------------
Date: Wed 18 Sep 85 15:59:24-PDT
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Article: Health Hazards of Computers
To: RISKS@SRI-CSL.ARPA
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
"The Health Hazards of Computers" edited by Art Kleiner. Pages 80-93,
Whole Earth Review, No. 48, Fall 1985, $4.50. PO Box 15187, Santa Ana, CA.
92705, or your news-stand.
"This amalgamation of information, conjecture, experiment, and reporting is
the end of a 12-month odyssey. It started last June, when we were planning
the 'Computers as Poison' issue (Fall '84 WER)."
"We really should have something on the health hazards of video-display
terminals (VDTs)." I said to Kevin and Stewart. "After all, it's a major
uncertainty. You sit with you nose squeezed up against the beast for hours
every day; you hear vague reports of cataracts and birth defects; you hear,
on the other hand, industry groups saying there's nothing wrong with the
machines .... Whom should you believe?"
A tip from Mike Castleman of Medical Self-Care Magazine led me to the
Center for Investigative Reporting in San Francisco. A reporter there named
Diana Hembree had already been investigating VDT radiation health hazards
for several months, with a particular interest in its effects on women
workers -- most VDT terminal grunt workers, such as airline reservation
clerks and data- entry operators are women. At my request, she assembled a
group of investigators to look into potential radiation hazards from
personal computers.
Their original article arrived in time for the Computers as poison issue,
but because it reported on a situation that was simultaneously
controversial, extremely technical, and inconclusive, we didn't feel
comfortable printing the article without scientific review.
Thus we held it and sent it to two dozen physicists, radiologists,
biophysicists, and doctors -- all people with a preestablished interest in
this topic. Diana's original theme wasn't particularly incendiary; it
basically said, "There seems to be a cause for concern, but nothing
conclusive; more research is needed." We got back a dozen replies, some
complimentary and other criticizing us for everything from hysterical
sensationalism to underplaying the danger. Some of those replies led to
further interviews that supplemented Diana's already exhaustive research.
Meanwhile, discussion of the EIES computer network began turning up comment
from other people who had investigated the issue.
Ultimately, I edited Diana's article, plus some of the replies and other
comments into these 14 pages.
The article ends with a bibliography and notes. Ted.
------------------------------
Date: Thu, 19 Sep 85 12:41:36 pdt
From: bcsaic!douglas@uw-june (douglas schuler)
To: RISKS@SRI-CSL
Subject: Two More SDI Related Queries
I have two queries r e l a t e d to SDI but (I hope) of general
risks interest.
1. Does anybody have rough heuristics for comparing the complexity of
large projects? I'd like to see a matrix where several very large
projects were compared feature by feature (e.g. person-years, LOC,
cost, function, etc)
2. I would be very curious to see the results of using Boehm's estimating
techniques (_Software Engineering Economics_) on the SDI software. The
techniques were developed at TRW and, hence, may be applicable to SDI.
Doug Schuler (206) 763-5295
{allegra,ihnp4,decvax}uw-beaver!uw-june!bcsaic!douglas
uw-june!bcsaic!douglas@washington.arpa
------------------------------
Date: Mon, 16 Sep 85 07:55:43 pdt
From: bcsaic!douglas@uw-june (douglas schuler)
To: Neumann@SRI-CSLA.arpa
Subject: CAL ID -- computerized fingerprint system
This isn't really a submission, just a noteworthy subject that I heard on
NPR this morning. The "CAL ID" computer system is a $40 million system
(from NEC) for storing and retrieving finger prints. The system has not
been officially accepted as of yet as only 2 million of the 2.5 million
fingerprinted California citizens are stored. It is still being tested.
The system was used successfully to identify the "nightstalker" from
fingerprints. Only males born since 1960 had been included. Ramirez was
born in February, 1960. It was estimated that the new system will result in
20,000 additional arrests per year in California.
[I thought this was worth including. There are all sorts of
associated risks. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------