27-Oct-86 15:20:45-PST,15180;000000000000 Mail-From: NEUMANN created at 27-Oct-86 15:18:35 Date: Mon 27 Oct 86 15:18:35-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.88 DIGEST Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Monday, 27 October 1986 Volume 3 : Issue 88 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: SDI, Missing engines, feeping creatureism in consumer products (Roy Smith) More aircraft instrumentation (John Allred) Re: Military vs. civilian automatic control systems (Eugene Miya) Perfection (Douglas Humphrey) Shipboard anecdotes (Mike McLaughlin) RISKS UNDIGESTIFIER on UNIX (John Romine) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.) ---------------------------------------------------------------------- Date: Thu, 23 Oct 86 15:28:25 edt From: cmcl2!phri!roy@seismo.CSS.GOV (Roy Smith) To: RISKS@csl.sri.com Subject: SDI, Missing engines, feeping creatureism in consumer products This message is a potpouri of several random thoughts that I've had in the past few days. The first two are apropos to recent topics on RISKS, the last is new material. Re: SDI and unexpected inputs. I have a friend who works for the Army Night Vision Lab (I'm not sure that's actually the correct name). They work on "find the tank in the jungle at night" problems. He once described a program that looks for tanks in a battlefield -- the first thing it does is find the horizon and concentrate on the area below (i.e. the ground). My first thought was "what happens when they start dropping tanks by parachute?" Re: Planes loosing engines. I gather than in many of the cases of planes having gross defects (i.e. a control surface torn off), the situation was at least meta-stable until the pilot tried to do something (i.e. turned off the auto-pilot to take control). I'm just guessing, but it seems that a chase plane could take off and intercept the damaged plane to make a visual inspection of its exterior quickly enough to be of some use. Am I being naive to think that this would be 1) practical and 2) of any use? Is it done already? Re: feeping creatureism. There is an annoying trend towards computerizing things that just don't need computerization. Even worse is the urge to make things *seem* computerized when the microprocessor in them does nothing more than scan for switch closures on the control panel and run a simple timer. I recently bought an air conditioner -- it doesn't have a control panel, it has a "command center". It has the same controls (on/off, etc) as any other air-conditioner, but the panel is made up to look like some sort of computerized gizmo. My new electric dryer is the same way -- it's got "electronic drying", which means is it has a thermostat is the exhaust vent just like my mother's old mechanical-timer model. Speaking of my mother, she just bought a new car and hasn't figured out how the radio works yet because the familiar volume and tuning knobs aren't there any more. So, how does all this tie in with COMPUTER RISKS? Take the dryer; by making it appear that there is some kind of computerized system monitoring and controlling the drying process, the consumer is duped into believing that his dryer is somehow better than the old ones. He doesn't really understand *why* it is better, but since it computerized, it *must* be better, right? Likewise with the car radio. While it may be true that digitally synthesized tuning is better than mechanical variable capacitors, (let's not start arguing about *that*) there was nothing wrong with the user interface (2 knobs to turn, maybe some pre-set pushbuttons). While the real advantage of the new radio over the old is the PLL instead of the variable cap, the *percieved* advantage is the "tune-up/tune-down" buttons instead of the tuning knob to turn. In fact, the new-fangled user interface is no better than the old one, and may in fact be worse. Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ------------------------------ Date: Mon, 27 Oct 86 10:35:39 EST From: John Allred To: risks@csl.sri.com Subject: more aircraft instrumentation Doug Humphrey asks: " ... I am not sure why a pilot would need a video monitor to tell him that Number 2 just fell off the wing, ... . He will no doubt understand this by the way the aircraft is acting." A perfect example of why a pilot could use a monitor is the American Airline DC-10 crash at O'hare. The pilots knew they had lost power on the engine. However, they had no way of knowing that they had physically lost the engine (because you can't see the engines from the DC-10 cockpit.) Upon detecting that they had lost power in one engine, the pilots went exactly by the book - they changed the airspeed to best-2-engine-climb speed. Unfortunately, when the engine fell off the wing, it also ripped out some hydraulic lines in the wing, which were holding the slats (high lift devices on the leading edge of the wing) extended. With the slats retracted, the stall speed of the damaged wing was *above* best-2-engine-climb speed. So, one wing stalled, the other kept generating lift, and the plane rolled over. It should also be noted that pilots in simulators, when given the exact same situation, were able to save the aircraft when they knew that they had physically lost the engine, while pilots that did not know uniformly failed to save the aircraft. Doug is correct in stating that a pilot should be able to understand if he's lost something important. However, that understanding could come too late, or in and of itself be fatal. ------------------------------ Date: Mon, 27 Oct 86 09:04:33 pst From: eugene@AMES-NAS.ARPA (Eugene Miya) To: risk@sri-csl.ARPA Subject: Re: Military vs. civilian automatic control systems I basically agree with Will's thesis about missions, but I don't the difference is that simple (binary). Two years ago, an F-8 Crusader (single engine Navy fighter, older) lost power over San Diego. The pilot had time to eject, but before doing so, he tried to avoid hitting buildings in the Serrento Valley area. (True he might have misjudged prior to ejection, but the plane did come down in a parking lot and not the nearby electronics buildings.) Many pilots have faced this dilemma in the past: including civilian pilots (do I kill several hundred people on the ground in addition to the passengers I have just killed?). I think this also goes for civilian rescue missions. Ford' Mayeguez (sp) mission in 1975 cost more Marine lives than civilians rescued. True we will never know the real political consequences of not rescueing (liberals: "we would have negiotated release," conservatives: "they would have died"), but my point is many of the fundamental types of systems are no different in the civilian or military sphere, and that there is overlap (with tricky trade offs) with military operations. --eugene miya ------------------------------ Date: Mon, 27 Oct 86 02:52:25 EST From: Douglas Humphrey To: risks@csl.sri.com Subject: Perfection To LIN : In response to a message, you state that none of the anti-SDI folk ever stated that the software had to be perfect. I have heard constantly in both the widely read (Washington Post) and limited (?) distribution industry media (Aviation Leak and Space Mythology) SDI critics that contect that it must be perfect or it is useless. I don't beleive this, and I would hope you don't either, but saying that the whole must be perfect certainly implies that the parts must be perfect. (Opps. contend..) About failure modes in software systems, yes, it is possible to design fault tolerant and fault permissive systems. Systems that have a know 'prefered failure mode'. Example, hardened underground facilities, I have been told (no references here) are not designed to withstand forces equaly throughout the structure. That would mean that when the structure finaly failed under load, there would be no reliable way to project where the failure would happen. Better to design with structural over load failure in mind and specificaly designate one area as the failure area, and then take withever measures one can (air/water tight bulkheads, etc.) in that area since you now have a high degree of confidence that the failure will happen where you want it, and are ready for it. Software can be designed the same way by dealing not only with the quantity (targets) by the quality of targets (destinations) and selectivly 'failing' on those which are the least important. I would guess that a catostrophic failure would be the one to avoid, even of the system decided that it was time to reboot, clearing target tracking data since some of it was detected as bad. The system might then let through whatever was locked at the time of the failure, but at least it would resume defense rather than either crash outright, or get into a position where its target load started to effect its real time processing and maybe preventing it from reacting well enough to to its job. Hey ! If we get flaming about this much deeper, we should all start submitting bills to SDIO....... Doug ------------------------------ Date: Mon, 27 Oct 86 13:05:11 est From: mikemcl@nrl-csr (Mike McLaughlin) To: pgarnet@nswc-wo.ARPA Subject: Shipboard anecdotes [marginally relevant but intersting] Cc: neumann@csl Two anecdotes about shipboard emergencies. In that fire, one sailor did think about what was happening, and ran aft as fast as his little legs would carry him. A _giant_ Chief Gunner's Mate named Mills grabbed him, pointed him back to his battle station, and said something like "Son, you better get to your battlestation. When a destroyer has a fire in a magazine, you just can't run far enough!" In another emergency that was really too complex to explain on Risks, I _really_ went automatic. I had far more charge of the situation, and far more depended on my own actions. Simply put, the USS Saratoga was about to run over us, and we had lost control of our rudders. I did the requisite things, and am here to tell about it. But _during_ the experience I was "out of body" - Some part of me was floating above and behind me, watching me give orders & do things, sort of supervising/monitoring me, but not interfering. I have no recollection of the situation from my body's eyes and ears once the situation developed. All of my quite detailed memory is from that viewpoint floating up in the aft port quarter of the pilothouse. I must have done good, because everybody said so, from the skipper down to the real authorities, the mess cooks. I have to conclude that I had been so thoroughly trained that I was operating on a learned-reflex basis, leaving my conscious mind free to observe. I don't know if we can use that somehow in designing "operator assistants" or not. - Mike ------------------------------ To: RISKS-request@csl.sri.COM Subject: RISKS UNDIGESTIFIER Date: Mon, 27 Oct 86 10:24:41 -0800 From: John Romine If you have the MH Message Handler (a user agent for UNIX) you have the "burst" command which seems to work just fine on Risks digests. MH is now distributed as user-contributed software on the 4.3BSD tape, and is available for anonymous ftp from the host louie.udel.edu. Also, you can get a magtape copy for $75 from the University of California, Irvine. I've included the release announcement below. /JLR A new release of the UCI version of the Rand Message Handling (MH) system is available for distribution. This release of MH is called MH 6.5 There are a lot of changes between MH.6 and MH 6.5; a lot of performance enhancements were made, there's also a lot of support for distributed mail (personal mail and bulletin bboards). Here are the details: - MH is in the public-domain - MH runs on a number of versions of UNIX (4.[123]BSD, V7, SYS5, and related variants, e.g., HPUX) [sorry, no support for SYS3.] - MH runs on top of a number of mail transport systems (MMDF-{I,II}, SendMail, stand-alone (with UUCP support)) Although MH is not "supported" per se, it does have a bug-reporting address, Bug-MH@ICS.UCI.EDU. Bug reports (and fixes) are welcome, by the way. There are also two ARPA Internet discussion groups: MH-Users@ICS.UCI.EDU and MH-Workers@ICS.UCI.EDU (somewhat analogous in charter to Info-UNIX and UNIX-Wizards). There are two ways to get a distribution: 1. If you can FTP to the ARPA Internet, use anonymous FTP to louie.udel.edu [10.0.0.96] and retrieve the file portal/mh-6.tar. This is a tar image (approx 4MB). The file portal/mh-6.tar.C is the tar image after being run through the compact program (approx 2.3MB). The file portal/mh-6.tar.Z is the tar image after being run through the compress program (approx 1.5MB). 2. You can send $75 to the address below. This covers the cost of a magtape, handling, and shipping. In addition, you'll get a laser-printed hard-copy of the entire MH documentation set. Be sure to include your USPS address with your check. Checks should be made payable to Regents of the University of California and must be drawn on U.S. funds. It's also a good idea (though not mandatory) to send a computer mail message to "Bug-MH@ICS.UCI.EDU" when you send your check via USPS to ensure minimal turn-around time. The distribution address is: Support Group Attn: MH distribution Department of Information and Computer Science University of California, Irvine Irvine, CA 92717 714/856-7553 Sadly, if you just want the hard-copies of the documentation, you still have to pay the $75.00. The tar image has the documentation source (the manual is in roff format, but the rest are in TeX format). /mtr ------------------------------ End of RISKS-FORUM Digest ************************ -------