22-Apr-87 17:59:17-PDT,9090;000000000000 Mail-From: NEUMANN created at 22-Apr-87 17:57:03 Date: Wed 22 Apr 87 17:57:03-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.76 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Wednesday, 22 April 1987 Volume 4 : Issue 76 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Risks of Warranties (Jim Horning) Re: Checklist stops risks? (Jerome H. Saltzer) Newer highly maneuverable planes on board and checklists (Eugene Miya) Aircraft risks (Peter Ladkin) Neutron beam detection (Scott Dorsey) 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. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Tue, 21 Apr 87 15:04:03 PDT From: horning@src.DEC.COM (Jim Horning) To: RISKS@CSL.SRI.COM Subject: Risks of Warranties ABACUS, vol. 4, no. 3, Spring 1987 contains the results of ABACUS Competition #3, which invited readers to submit actual examples or parodies of software disclaimers of warranty. The winner is included as a format example in the user manual of the Horstmann Software Design product, ChiWriter: Cosmotronic Software Unlimited Inc. does not warrant that the functions contained in the program will meet your requirements or that the operation of the program will be uninterrupted or error-free. However, Cosmotronic Software Unlimited Inc. warrants the diskette(s) on which the program is furnished to be of black color and square shape under normal use for a period of nineyt (90) days from the date of purchase. NOTE: IN NO EVENT WILL COSMOTRONIC SOFTWARE UNLIMITED OR ITS DISTRIBUTORS AND THEIR DEALERS BE LIABLE TO YOU FOR ANY DAMAGES, INCLUDING ANY LOST PROFIT, LOST SAVINGS, LOST PATIENCE OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. The runner-up is from the Haven Tree Software Limited program Interactive EasyFlow: We don't claim Interactive EasyFlow is good for anything--if you think it is, great, but it's up to you to decide. If Interactive EasyFlow doesn't work: tough. If you lose a million because Interactive EasyFlow messes up, it's you that's out the million, not us. If you don't like this disclaimer: tough. We reserve the right to do the absolute minimum provided by law, up to and including nothing. This is basically the same disclaimer that comes with all software packages, but ours is in plain English and theirs is in legalese. We didn't really want to include any disclaimer at all, but our lawyers insisted. We tried to ignore them but they threatened us with the attack shark at which point we relented. These remind me of the software order form I received some years ago requiring me to sign a statement acknowledging that the only warranty made by DJ AI Systems was that they owned the copyright on the software being ordered. Jim H. ------------------------------ Date: Wed, 22 Apr 87 12:32:30 EST To: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: Re: Checklist stops risks? From: Jerome H. Saltzer Joseph Beckman suggests that his VCR and auto radio problems might be reduced by checklists. Probably so. There is a more subtle technology RISK hiding here, one that I notice almost every time I find that a computer has appeared in the control path for an auto radio, a VCR, an automatic washer, or a toaster oven: the device acquires a whole host of new features, options, and state memory that it didn't use to have. As a result you can't run it without a checklist. Lots of things don't need a checklist. My old toaster certainly didn't need one. But judging from the frequency of mistakes, my new one seems to. A real RISK arises when someone hi-tech's a traditional design, pushing its functional spec over the threshold at which the average user needs a checklist to run it, and then sells this improvement to an unsuspecting and unprepared user community. Jerry Saltzer [Jerry, Many thanks. This raises the desire for CONSISTENCY of code with specifications where the system must do NO MORE AND NO LESS than specified. Of course, it is likely to do all sorts of things that are not specified, and therein lie all sorts of risks. Trying to specify the action required for EVERY STATE in the state space is an important but very difficult task. (How many of you have fallen on the EMACS bug that results in your being totally HUNG, where even ^G does not work? ) PGN] ------------------------------ Date: Tue, 21 Apr 87 10:04:09 PDT From: Eugene Miya To: risks@csl.sri.com Subject: Newer highly maneuverable planes on board and checklists Two added notes to existing topics. There is a recent Aviation Week which mentions a program to make even more maneuverable planes (but not higher G), but I still wonder if it's not more a matter of screening pilots to withstand force. Not unlike recent DARPA comments that maybe 1 in 3 programmers can program new parallel architectures. Regarding checklists: we have some automated checklist work here. Originally they thought they wanted to put more control into the checklist but decided to separate the control from the check (safer). We should make things easier to use up to a point. I refrain from comment on slow neutrons. I would worry more about film than food (but that's not my area). SAIC is a scientific body shop with offices all around the country. I was approached by them to work as a contractor at a spook Agency. --eugene miya, NASA Ames ------------------------------ Date: Tue, 21 Apr 87 13:57:54 pst From: ladkin@kestrel.ARPA (Peter Ladkin) To: risks-request@csl.sri.com Subject: Aircraft risks Tom Perrine thinks I am suggesting that pilots are willing to risk GLC episodes in the new planes. I am not suggesting this. I am suggesting that they are more willing to risk a black-out, since the danger of accelerated stalls is moderated. Consequently they risk GLC episodes when they are tired, hard-worked, or simply (according to the air force) away from it over the weekend. A computer is in the loop. My argument is that it makes the scenario more likely. One possible source of confusion - a blackout is not a loss of consciousness. Blackouts are loss of vision, caused by the collapse of the retinal arteries, and are easily reversed by unloading the Gs. peter ladkin ------------------------------ Date: Tue, 21 Apr 87 11:50:35 edt From: Scott Dorsey To: RISKS@CSL.SRI.COM Subject: Neutron beam detection [RISKS 4.75] I can't imagine anything worse that one could do to luggage than bombard it with slow neutrons. The last time I flew commercial, I was carrying about $200 worth of motion picture film in my luggage, and I would be very upset if it had been fogged. Lots of vacationers carrying their vacation pictures will be very upset. Next time I'm taking the lead sheathing... In addition, what happens to digital electronics when they are hit with slow neutrons? I assume the levels of radiation are low enough not to permanently damage watches, calculators, etc., but it may well be enough to change the state of logic. Logic, like the digital timer used to set off the explosive device that was hidden in the luggage, which goes off in the airport. A machine which detects nitrogen chains may also detect things like ammonia if it cannot discriminate between long and short chains. Some explosives (like ammonium nitrate) are reasonably safe when not in the presence of an activator, and have reasonable industrial uses. Pity the fertilizer salesman whose sample case is confiscated. Worst of all, this could lead to a false sense of security; there are lots of nitrogenless explosives out there. Two-part explosives aren't all that hard to come by. I don't like the idea of pumping hard radiation into luggage. It's just a bad idea in general. Might be good for disinfecting your clothes, though. Scott Dorsey Kaptain_Kludge ICS Programming Lab (Where old terminals go to die), Rich 110, Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge ------------------------------ End of RISKS-FORUM Digest ************************ -------