20-Sep-85 10:37:19-PDT,14504;000000000001 Mail-From: NEUMANN created at 20-Sep-85 10:34:12 Date: Fri 20 Sep 85 10:34:12-PDT From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-1.15 Sender: NEUMANN@SRI-CSLA.ARPA To: RISKS-LIST@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-1.n) ---------------------------------------------------------------------- Date: Wed 18 Sep 1985 16:51:10 EST From: David Weiss 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 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 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 ************************ -------