29-Sep-86 21:45:47-PDT,10120;000000000000 Mail-From: NEUMANN created at 29-Sep-86 21:43:07 Date: Mon 29 Sep 86 21:43:07-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.70 DIGEST Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Monday, 29 September 1986 Volume 3 : Issue 70 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Deliberate overrides? (Scott E. Preece) Multiple causes and where to place the "blame" (PGN) The Art of "Science" and its Computers (PGN) No-lock Brakes (Peter Ladkin) Sanity in Automating Keyword Abstracting (Brint Cooper) The Network Is Getting Old? (PGN) 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: Mon, 29 Sep 86 09:17:27 cdt From: "Scott E. Preece" To: RISKS@CSL.SRI.COM Subject: Deliberate overrides? /**** ccvaxa:fa.risks / LIN@XX.LCS.MI / 2:47 am Sep 29, 1986 ****/ > From: Charles R. Fry > > > No matter how many automated controls we install on cars (and airplanes) > > to prevent operators from exceeding their vehicles' limits, there will > > always be a need to allow the deliberate violation of these limits. > From: LIN@XX.LCS.MIT.EDU > This discussion about allowing overrides to programmed safety limits > worries me. One of the nice things about computer-driven controls, as opposed to mechanical controls, is that they allow you to be less draconian in specifying limits. You don't have to build a bomb release that can never, ever allow the pilot to drop a bomb while inverted; you can instead say "You know, if I do what you've asked, the bomb is going to fall on the wing and probably strip off your starboard control surfaces." and the pilot can say "Yes, I know, do it anyway." And by providing a (safety-covered and hard-to-reach) button that says "Override control limits" you can even make it possible for the pilot to say in advance that at this point she feels the danger in overriding the controls is smaller than the danger in not overriding the controls. The reason we think it's reasonable to require automated controls to allow exceptions is that we know the automated controls have allowed and encouraged us to incorporate limits and we recognize that (1) those limits may have erred on the side of normal safety, (2) since the systems are new, the necessary operational envelope may not be known, and (3) the interaction of the limits may create unanticipated problems. Yes, users should be allowed to override automated controls in almost all cases AND designers should make very, very sure that the effort to override is proportional to the danger of the override. In many cases there should also be logging of overrides, so that operators, maintainers, and designers have an opportunity to notice that actual use seems to be violating the design assumptions. I wonder how many readers of this list [NO, this is NOT a survey, DON'T write to tell me] drive cars with manual transmissions precisely because they want to be in control, want to know that doing x and y will result in the car doing z, without any control system in the way to place limits on actions or responses... scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece ------------------------------ Date: Mon 29 Sep 86 21:36:04-PDT From: Peter G. Neumann Subject: Multiple causes and where to place the "blame" To: RISKS@CSL.SRI.COM Today's AP noted that the FAA may cite the pilot of the Grumman Yankee for being in restricted airspace, at precisely the moment of the crash between the Aeromexico jet and the Piper Archer (which was also in restricted airspace), which distracted the air traffic controller from attending to the jet and the Piper (the absence of whose altitude information was also a factor) -- at precisely the time the crash occurred. The controller did tell the Grumman pilot that he was in restricted air space, but then granted him permission to continue (and that negotiation took two precious minutes away from his attention to the jet). ------------------------------ Date: Mon 29 Sep 86 16:36:51-PDT From: Peter G. Neumann Subject: The Art of "Science" and its Computers To: RISKS@CSL.SRI.COM A computer of the AAAS sent out renewal bills for SCIENCE to some subscribers: Subscription price $6647, Postage $732, Voluntary contribution $10, Total $5437. The subscription price during 1986 was $60, and the accompanying letter from the president of AAAS noted that inflation had required an increase. A quite amusing editorial by Daniel Koshland, Jr. in the 26 Sept 86 issue wondered whether any people would rush out to take advantage of the incorrect addition. ------------------------------ Date: Mon, 29 Sep 86 14:47:16 pdt From: ladkin@kestrel.ARPA (Peter Ladkin) To: risks@sri-csl Subject: No-lock Brakes A minor correction to Chuck Fry's comments - the first anti-skid system on a production car was installed on a Jensen (pre-dating the Jensen-Healey) in the 60s. It was made by Lockheed, and derived directly from aircraft systems. ------------------------------ Date: Mon, 29 Sep 86 15:09:02 EDT From: Brint Cooper To: Risks Forum Subject: Sanity in Automating Keyword Abstracting Here is an example of a risk associated with the use of computers. The risk is to the accurate dissemination of information and is caused by faulty programming (programmers?). Today, the BRL Librarian informed us that the Defense Technical Information Center (DTIC, formerly known as DDC) now requires that the titles of our technical reports (the principal products of a research lab such as the BRL) be written so that the "keywords" are found in the first five words of the title. Thus, a report which formerly was titled "Communication Modeling in the Artillery Control Experiment" with keywords "error control," "tactical communications," "networks," and "modeling" would have to be titled "Modeling, Tactical Communications, and Error Control Networks," thus sounding like, as one chap here put it, "a four volume set by Harry van Trees" instead of a 25 page report. Exact text of our librarian's notice follows: > We have been advised by DTIC that the titles of technical reports should > be designed with the key words positioned in the first five words of the > title. This is because only the first five words are used in a title > search in the DTIC electronic data base DROLS.(DEFENSE RESEARCH ON LINE > SYSTEM). Important to know (and remember) is that articles are counted > in those first five words. Therefore a report entitled "A report of the > effect........." will not have any key words picked up in a title > search. If you currently have a report in editing, we will review it > and if it it does not comply with the DTIC recommendation we will advise > you so that it can be reworked. If you currently have a report under > review or in writing you might like to think about a title change. > Please give this widest possible dissemination. Brint ARPA: abc@brl.arpa UUCP: ...{seismo,unc,,decvax,cbosgd}!brl-smoke!abc Dr Brinton Cooper, U.S. Army Ballistic Research Laboratory Attn: SLCBR-SE-C (Cooper), Aberdeen Proving Ground, MD 21005-5066 Offc: 301-278-6883 AV: 298-6883 FTS: 939-6883 Home: 301-879-8927 [ASK NOT WHAT YOUR COMPUTER CAN DO FOR YOU, ASK WHAT YOU CAN DO FOR YOUR COMPUTER! I started to add a diatribe, but gave up in annoyance. PGN] ------------------------------ Date: Mon 29 Sep 86 09:50:22-PDT From: Peter G. Neumann Subject: The Network Is Getting Old? To: RISKS@CSL.SRI.COM There has been an enormous amount of difficulty in dealing with the ARPANET since early September, perhaps related to the installation of new IMP software and subsequent patches when the new release did not work properly. I had devastating problems TELNETing from four different East-coast hosts to three different SRI systems (irrespective of whether there was a gateway at my end, and even with no loads on either system). No answers have been forthcoming from any of our gurus, so the problems remain pervasive and painful. I am also getting a rash of returned net-barfed RISKS mail (as well as RISKS filling up peoples' directories when they go on vacation). There are also local problems. Last Friday a message from SRI-STRIPE to SRI-CSL took 7 hours to be delivered, while TN and FTP between those two machines worked fine. From: David L. Edwards It is becoming increasingly apparent that there are serious network problems. There has been some discussion of this on the TCPIP forum. Network delays, failed connections, inability to make connections etc. are being reported by hosts all over the network. BillW has noticed that direct communications between SRI and SU are bad. In your case there are one or two gateways involved in addition to the IMPs. The mailer recently reported 750+ attempted connections with 670+ failures. Old age? Software rot? Incompatible changes to net software? Saturation? Who knows. Stay tuned. ------------------------------ End of RISKS-FORUM Digest ************************ -------