Subject: RISKS DIGEST 12.44 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 8 October 1991 Volume 12 : Issue 44 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: RISKS of Highway warning signs (Jim Hofmann) US Coast Guard's user fiendly software [sic] (Dave Schmidt) Fiber optics can spontaneously destroy themselves! (Jeffrey Sorensen) 911 Glitch Delayed Help in Fatal Mt. Prospect Fire (W.F. Wicks via Mark Brader) Risks of owning a modem (Geoff Kuenning) Emergency phone dialer in Contra Costa county (Darren Alex Griffiths) ECC == Error CAUSING Code? Tape drive overcorrects itself... (John Board) Re: AT&T "Deeply Distressed" (Bob Colwell) Re: Back quotes print wrong (Dick Karpinski, Simson L. Garfinkel) Re: Space Station Software Hubris (Stephen G. Smith) Schipol Airport (Peter De Graaf via Mark Kennedy) Computer Mediated Ethical Discussion: An Invitation (Peter Danielson) ACM Computer Security Day (Beth Olson) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 4 Oct 91 13:10:05 EDT From: Jim Hofmann 5577 Subject: RISKS of Highway warning signs On 3 Oct 91 just after midnight, an accident occured partly BECAUSE of the electronic warning signs. Woodrow Wilson bridge in Washington D.C. is a drawbridge, which, when it goes up is supposed to notify three signs each in Maryland and Virginia. The signs are programmed to flash a warning message --- presumably to slow down cars and trucks coming towards the traffic. In this case, the sign operators were not notified and hence a truck barrelled into a queued car and killed the driver. The implication is that had there been no signs, the driver might have been more cautious. But since there WAS a sign and it was not flashing a warning signal, the driver did not slow down. The obvious fix here is that if the signs are broken or not notified in time, the bridge should not be allowed to raise. J.B.Hofmann [This saga had some strange background. There are separate controls for each side of the river, and the programming is done upon request by telephone, via a dedicated phone line. Apparently there were many hours of delay between the receipt of the request to open the bridge and the reported attempt to notify the ``programming'' staff, so that the notification was not attempted until after prime shift. The programming staff insisted the phone never rang, even though someone was required to be in the room at all times and even though the phone rang louder than anything else in the room. The bridge is opened something like 400 times per year. This one was for a sailboat. Source: Washington Post 4Oct91 and various news broadcasts. PGN] ------------------------------ Date: Tue, 1 Oct 91 12:03:40 PDT From: daves@amc.com (Dave Schmidt) Subject: US Coast Guard's user fiendly software (No, I didn't misspell it!) I recently tried to be a good little citizen and pay the new USCG boat tax. This involves paying some money, for which you get a nondescript sticker for your boat; this supposedly prevents hassles with the Coast Guard. USCG does not have it's own personnel taking orders; you call an 800 number and either order the sticker with a credit card (!) or order an order form to use to order the sticker with a check. The order form we sent was evidently misread, as our address was completely messed up. When I called back to find out what happened (after 2 months), the phone droid said: "No problem. We'll send you a claim form....Uh oh. The computer won't let me fix your address. The claim form will go to the same address that the sticker was sent to - you know, the one that the post office couldn't figure out?" Isn't it nice that with all of the work done on making user friendly software, that people still overlook obvious functions like correcting data entry errors? If this isn't "user fiendly", I don't know what is... David Schmidt WB7RDI daves@amc.com Applied Microsystems, Inc ------------------------------ Date: Tue, 1 Oct 91 15:04:48 EDT From: sorensen@spl.ecse.rpi.edu (Jeffrey Sorensen) Subject: Fiber optics can spontaneously destroy themselves! In the Sep 28 issue of _Science News_ there is an article about a recently discovered property of fiber optic cables that could lead to all kinds of risks. It turns out that a fiber optic in an environment "where the temperature can suddenly increase" can result in the complete destruction of a fiber optic in what is known as a fiber "fuse" effect. "For certain types of optical fibers...damage can occur when the visible-light laser power transmitted... is as low as 4 milliwatts..." The damage to the fiber is a series of bullet-shaped cavities that form at equidistant spacings from the sight of heat damage tracing back towards the laser light source. "The damage effectively (ruins) the fiber as a medium for transmitting light. One test showed that a single flare could damage 1.5 kilometers or more of fiber." The damage travels at a rate of about 1 meter per second! The causes of the phenomena are being researched and the sides of the debate are presented in the article (pp. 200-201). The effect is related to the germanium concentration and fibers with high concentrations are at the most risk. The temperatures required to cause the effect are between 700 'C and 1,000 'C. On the risks involved: "It's a lot more catastrophic than just cutting a line...you basically destroy the fiber." Anyone using these types of fibers in, say, a nuclear reactor or for a critical sensor would be well advised to check this out. Jeff Sorensen sorensen@ecse.rpi.edu (518) 276-8202 ------------------------------ Date: Fri, 4 Oct 1991 22:42:00 -0400 From: msb@sq.com (Mark Brader) Subject: 911 Glitch Delayed Help in Fatal Mt. Prospect Fire (comp.dcom.telecom) Date: 2 Oct 91 13:29:45 GMT From: wickswf@adobe.rtsg.mot.com (William F. Wicks) Newsgroups: comp.dcom.telecom Subject: 911 Glitch Delayed Help in Fatal Mt. Prospect Fire Organization: TELECOM Digest Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 786, Message 7 of 8 Something of interest from the suburbs of Chicago. In the September 26 issue of the Northwest Edition of the {Chicago Tribune} was the following article: "A computer glitch in the new enhanced 911 system serving six northwest suburbs caused the system to malfunction as a Mt. Prospect man tried to alert authorities to a fire that killed his wife and mother, authorities said. The incident led Centel to discover and correct the problem before anyone else was affected. Mt. Prospects fire officials said the system's failure did not contribute to the deaths of the two women, who they believe died before the emergency phone call. The 911 error was caused by a record-keeping procedure in Centel's system, which listed the man's neighbor's phone number (where he placed the 911 call) both to the home in Mt. Prospect and to another address in Des Plaines which had previously had the number. In processsing the call, the 911 computer software saw two addresses for the same phone number, which is not permissible in its programming and eliminated one. When the man called 911 and the computer read the Des Plaines address, it played a recording saying that the community was not hooked up to the 911 system. At this point the call should have been routed to the Northwest Central Dispatch System, but it did not. The recording directed the man to call an operator, who put him in contact with the emergency dispatcher in Des Plaines. That dispatcher called Northwest Central Dispatch officials who sent firefighters to the scene." Although in this case it was determined that nothing could have been prevented if the error had not existed, this could have been a very costly error. It was found that 26 other people had wrong addresses in the computer. I found this story very interesting because I live in Schaumburg which just recently converted to E-911 (not this same system though). William Wicks Motorala, Inc. wickswf@adobe.rtsg.mot.com [Moderator's Note: I saw the same story. Thanks for passing it along. Our Chicago 911 operates pretty well considering the heavy load on it this past summer with the warfare going on here for the past few months. Those suburbs with their own 911 (ie, phone exchanges unique to their community) also do okay. The troublesome ones are as the story noted, those communities with overlapping phone exchanges where one has 911 and the other does not. PAT] ------------------------------ Date: Sat, 5 Oct 91 02:38:29 PDT From: desint!geoff@uunet.UU.NET (Geoff Kuenning) Subject: Risks of owning a modem As you may notice from the header of this message, it is about 2:30 A.M. on Saturday morning (or Friday night, if you prefer). I just got a knock on my door, which was astounding in itself. It turned out to be a couple of cops. They asked me if I owned a certain phone number, which is the one I use for my modem (and nothing else). Apparently it had dialed 911. In itself, this is nothing unusual. I have seen similar reports on RISKS before. But my L.sys file has no number containing the sequence 911! A check of my uucp logs showed successful calls at 2:01 and 2:08, followed by a failure at 2:23. Presumably this last was the cause of the 911 call (we have good police response times here). There are two numbers for the 2:23 call, both of which contain the sequence "166". Now how did that get turned into 911? Maybe my dyslexic modem turned the digits upside down, then got confused about what was repeated :-)? Seems moderately unlikely. For what it's worth, it's a Telebit T-2500. The cops said it happens fairly often. Personally, I'm upset. Those guys have better things to do than chase spurious calls from modems. But I have no idea what I can do to prevent a recurrence. I've only had the thing a couple of months. I sure hope this isn't a "feature". If so, perhaps the police department has a way for me to tell them to ignore 911 calls on that line. Geoff Kuenning geoff@ITcorp.com [We have had several items on this topic before, but the problem does not seem to go away. PGN] ------------------------------ Date: 2 Oct 91 18:36:44 GMT From: unisoft!dag@ucbvax.Berkeley.EDU (Darren Alex Griffiths) Subject: Emergency phone dialer in Contra Costa county I noticed an interesting news story in the San Francisco Examiner a couple of days ago. It seems that a bay area county (Contra Costa) has set up a system to dial every phone in the county in case of emergencies. The system can be setup to dial all the phones (about 30,000) within a few hours in the event of a toxic spill or other disaster, or it can call every phone within a few blocks and ask people to look out for a lost child. Initially this sounds like a good thing, and it probably is, but there are certainly some questions. I've never heard of this type of system before, is Contra Costa the first one to have it? Also, I assume they didn't test it by calling all of the phones, so how do they know it will really work? There are also some interesting risks associated with it. By definition the system is connected to the phone network, I wonder what the chance of some piece of pond scum breaking in to it and sending fake messages to people are? What if the system breaks and goes wild at 4:00am calling up numbers all over the world? Where does it get the address information from as well? I wonder if it uses the 911 database or if it has it's own built by the city? Ahhh, so many questions, so little time. Darren Alex Griffiths dag@unisoft.com (for now) dag@ossi.com (RSN) ------------------------------ Date: Tue, 1 Oct 91 11:19:32 -0400 From: Subject: ECC == Error CAUSING Code? Tape drive overcorrects itself... Product manager's worst nightmare: creating a feature designed to enhance reliability (in this case of data stored on tape) which, in fact, reduced it (in this case by sometimes causing data losses). The RISK of allowing marketing to force one bell or whistle too many into a design? Reminds me of the "Uninterriptable Power Supply" we had in our lab which caused system crashes by putting spikes on the "protected" side of the supply whenever its internal cooling fans cut in, but I digress. I excerpt from a letter recently received from IBM. I applaud their frank and rapid disclosure of a potentially dangerous technical flaw; I find their tone ("well, you don't really need ECC anyway because our drive is so good") somewhat amusing, a luxury I am permitted since we experienced no losses. My opinion might be harsher if we had been adversely affected by the problem.... "IBM has discovered that the Error Correction Code (ECC) function in the IBM 150MB 1/4-inch tape drive is not performing to our satisfaction. [...] This ECC implementation is unique to this ... drive, and was intended to provide an additional margin of data protection beyond commonly accepted reliability levels. However, a problem has been found which has the potential for causing loss of data when the drive is reading a tape made with ECC. There are no error codes to indicate that this condition has occurred. This problem will have no impact on the system until the tape is read, because the data is recorded correctly on the tape, but may be read back incorrectly under certain unusual circumstances. Most users will not experience this set of circumstances. Since the [...] drive provides all the recognized industry standard checking features such as Read after Write and redundancy checking in addition to ECC, ECC is not required in order to provide commonly accepted reliability levels [...]." John Board, Asst. Prof., Dept. Electrical Eng'g and Dept. Comp. Sci., Duke University, Durham NC USA +1 (919) 660-5272 INET: jab@ee.egr.duke.edu ------------------------------ Date: Mon, 7 Oct 91 15:12:25 -0700 From: colwell@ichips.intel.com Subject: Re: AT&T "Deeply Distressed" (RISKS-12.43) An [AT&T] executive told the FCC that AT&T was ``deeply distressed by the lapses in procedure'' that led to a network failure in New York City last month. ... 4. Nationwide, AT&T has stepped up plans to spend $200 million over the next 12 months to improve the reliability and backup of its power systems, which is expected to greatly diminish the risk of similar equipment problems. I get the uncomfortable feeling that the real risk here is being intentionally ignored. What caused this service outage was human error. What caused Chernobyl was human error. Ditto for Three Mile Island and the Kansas City Hyatt hotel walkway collapse. Design engineers can try to anticipate how machinery and materials will interact with each other. But it's devilishly hard to predict how something as complex and unpredictable as a human being, especially one that becomes emotional and possibly irrational under duress, will react to the system. It's clear that the human component of the AT&T outage was what caused the outage. That's the link that needs more attention in the engineering and in the analysis of failure. Bob Colwell, Intel Corp. JF1-19, 5200 NE Elam Young Parkway, Hillsboro, Oregon 97124 colwell@ichips.intel.com 503-696-4550 ------------------------------ Date: Fri, 4 Oct 91 13:12:59 PDT From: dick@ccnext.ucsf.edu (Dick Karpinski) Subject: Back quotes print wrong (Risks of computerized typesetting) I ran into this problem myself and have repeatedly reported the problem both to NeXT and to Adobe. For me, with Courier, the back quotes are correct on the screen and wrong on the laser printer. Frustrating and dangerous. It is possible to see the difference between forward and back quotes in the printer output, but it is not easy. Forward quotes print as forward quotes which are a bit heavier on the top whereas back quotes print as forward quotes which are a bit heavier on the bottom. After such a disaster as recently reported, it ought to be easier to get the vendors involved to fix the problem. I hereby solicit anyone's assistance in reporting the problem to appropriate authorities so that it can be fixed. Dick ------------------------------ Date: Fri, 4 Oct 91 14:54:09 PDT From: simsong@nextworld.com (Simson L. Garfinkel) Subject: Back quotes explained (was: Risks of computerized typesetting) After several helpful messages from the net, we have finally figured out what happened with our Courier font. Apparently, a few years ago Adobe did a silent change to their Courier font. Backquotes were changed from the regular character with a negative slope to a regular forward quote character which happens to be a little wider at the bottom then at the top. (The normal forward quote character is a little wider at the top than at the bottom.) Thus, the ` and ' characters in the current Adobe Courier font *are* different characters, but you can't tell the difference unless you look at them under a magnifying glass. Happily, Adobe made this substitution without telling anybody, and without changing the name of their Courier font. As several people pointed out, we could have avoided this problem by providing our publisher with our own copy of the Courier font. The publisher, ORA, has now started doing this with all of their books sent out to be typeset and printed. Ah, standards. -s ------------------------------ Date: Thu, 3 Oct 91 20:39:28 -0400 From: sgs@grebyn.com (Stephen G. Smith) Subject: Re: Space Station Software Hubris In RISKS-12.42 David Bremner writes: >... but what worries me is the attitude that writing ( working ! ) 10 >million line programs is a solved problem, that all we have to do is use Ada >(TM AJPO) and mil-std 2167A, and everything will work fine. > David Unfortunately, the "MIL-STD" snake oil promises exactly this. This is extremely attractive to the bureaucratic mentality -- "Follow the written procedures *exactly* and it will all work". Anything that doesn't work will be traced to a failure of somebody (invariably a junior non-manager) to follow the standard properly. Note also that in the Washington Post employment ads, "Software Engineer" is a code phrase for "Junior Programmer with a working knowledge of Ada". No wonder things don't work. Steve Smith Agincourt Computing sgs@grebyn.com (301) 681 7395 ------------------------------ Date: Fri, 4 Oct 91 14:39 MET From: hvlpb!mkenned@att.att.com Subject: Schipol Airport [The following article appeared recently in a Dutch newspaper, possibly "de Volkskrant." I have freely translated it into English, so please excuse any errors I have made with either the translation or with the English. Thanks!] Scrabble on Schipol, The Letter "A" May Not Be Used Anymore Schipol celebrated its 75th jubilee in a sober way on Thursday. The airport is busy with rebuilding and expansion, and regarded the "mess" as a cause for a celebration. A new, fifth pier is being constructed. This "E-pier" must be delivered in May. But the E-pier will never be called the E-pier. At the same time as the opening of the new pier, all of the other piers, exits and docking locations for airplanes, are receiving new letters and numbers. A non-trivial operation, which shall be executed overnight and cost around 2 million Dutch guilders. The letter descriptions of the piers are being pushed up 2 places in the alphabet. The A-pier will now be called the C-pier, the B-pier D-pier, etc. The new E-pier will become the G-pier. The descriptions are changing to avoid confusion between languages. The letter "A" in English is pronounced the same as the letter "E" in Dutch [a long "ayyy" sound]. For example, the airplane to Malaga from departure gate A12 is, in English, called up as [ayyy 12, or E2 in Dutch]. Less seasoned Dutch travellers could become completely panicked, and speed off toward the other side of the airport. "And that is a very long walk, especially as you must also come back again", says a spokesman from the airport. If the letter A is henceforth taboe in Schipol, that does not apply for the letter B. It is true that the new pier descriptions are beginning from C, but that is being done to allow the small, future extension in front of pier C to be called B. There is still a second reason for the roundabout and costly name changes, which must be carried out not only on all of the boards, but also in all of the computer systems. The descriptions of the exits presently consist of one [number] with two digits. Exits have, in the past decade, been regularly numbered in this way. There exists, therefore, only one exit 12, and that is on the A-pier; one 42, on the C-pier; and one 83, on the B-pier. The number of exits and docking locations are threatening to exceed 100 with the expansion of the airport. They should then be described with a letter and three numbers. This gives problems not only with Schipol's computer system, but it could also lead to confusion with the flight numbers, which consist of two letters and 3 numbers. "Flights from British Airways, for example, are described with BA and 3 numbers. That can then look suspiciously like a number from the B-pier," explains the spokesman. If there is a little bit of noise in the communication line, it leads to a great confusion. This applies not only for the passengers, but also for the pilots and employees in the control- tower. To avoid such communication failures, all number descriptions are becoming adjusted. So that Schipol, in the coming days, will never need to use a number above 100. Peter De Graaf = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Note: There are a large number of obvious risks in using a system which has many potential communication faults, especially when air traffic control is involved. One quick point is that Schipol airport will be facing the same problem again if it ever expands to include, after the H-pier, an I-pier. The letter I is pronounced in Dutch like an English E, and the Dutch interpret an English spoken I as an "ij", a Dutch "substitute" for the letter Y. Confusing? Definitely. Solution? Perhaps using distinct names for the piers instead of letters would be the best method. I seem to recall one airport which used color coded piers, such as Red pier and Green pier, etc. Mark Kennedy, Explorations Dept., Huizen, AT&T Network Systems Nederland mkenned@hvlpb.ATT.COM [If you get to where you think you are supposed to be and find nothing, you might find Nay-Pier's Bones. X-Pier-imental evidence may lead to N-Pier-ical results, especially in Leap-Piers. PGN] ------------------------------ Date: Fri, 4 Oct 91 14:18:16 PDT From: Peter Danielson Subject: Computer Mediated Ethical Discussion: An Invitation COMPUTER ETHICS THROUGH THICK & THIN Computer Ethics through Thick & Thin is a three year research project funded by an Applied Ethics Strategic Grant from the Social Science and Humanities Research Council of Canada. The project will investigate the ethical potential of computer mediated communication by creating two virtual colloquia that differ in the information available to their members. The Thick group will know each other only as continuing pseudonyms; the Thin group will be able to access whatever information its members will contribute. The two colloquia are based on e-mail in order to encourage wide membership. The groups will discuss ethical issues raised by computer technology, such as privacy and ownership and control. For a description of the project and information about how to join either group, please contact: Prof. Peter Danielson, Centre for Applied Ethics, University of British Columbia, 1866 Mail Mall E-165 Vancouver, B.C. Canada V6T 1Z1 danielsn@unixg.ubc.ca (604) 822 4658 FAX (604) 822 8627 ------------------------------ Date: Fri, 04 Oct 91 12:33:03 EST From: Beth Olson Subject: ACM Computer Security Day STUDENT DISCOUNT AVAILABLE FOR COMPUTER SECURITY SEMINAR SERIES The sponsors of the Computer Security Day Seminars are offering a Special Discount to Students. The normal fee of $195 for attendance is reduced to $35 for students. Each attendee will receive as part of the program three excellent books on Computer Security: COMPUTERS UNDER ATTACK -- Edited by Peter Denning COMPUTERS AT RISK -- Published by the National Research Council COMPUTERS VIRUSES -- Published by the ADAPSO Computer Committee Together with posters and a checklist of 53 Ways to Observe Computer Security, the student attending will get this entire package, excluding lunch for $35. Call 1-800-524-4023 today to register for the seminar in the city of your choice. See the following announcement. COMPUTER SECURITY DAY DECEMBER 2, 1991 Computer Security Day will focus the attention of corporate executives and computer professionals on those safeguards which are essential, considering the risk of intrusion into personal privacy and potential disasters that can cause economic and personal loss. This program will emphasize that attaining increased computer security is not only a technical matter, but a management and social issue as well. SYMPOSIA In preparation for Computer Security Day on December 2nd, half-day symposia will be presented in the following metropolitan areas. These symposia will provide corporate executives and computer professionals with practical information to make their installations more secure. Tuesday, October 8 Phoenix Sheraton Phoenix Monday, October 21 Atlanta Atlanta Hilton & Towers Tuesday, October 22 Los Angeles Los Angeles Hilton & Towers Friday, October 25 Detroit Novi Hilton Tuesday, October 29 Chicago Palmer House Wednesday, October 30 Minneapolis Minneapolis Metrodome Hilton Monday, November 4 Houston Westchase Hilton & Towers Wednesday, November 6 Philadelphia Univ. of Pennsylvania Faculty Club Thursday, November 7 Boston Back Bay Hilton Friday, November 8 New York New York Hilton & Towers Friday, November 15 San Francisco Bay Sunnyvale Hilton Monday, November 18 Washington, DC National Institute of Standards and Technology (NIST) For further information, contact: Don Nowak, Program Manager, ACM, 11 W 42nd Street, New York, NY 10036, (212) 869-7440, Extension 223 nowak@acmvm.bitnet Sponsored By: ACM SIGSAC, ADAPSO, American Express, Computerworld, Ernst & Young Beth Olson, ACM Local Activities, 11 West 42nd Street, New York, NY 10036 voice: 212/869-7440; fax: 212/944-1318 olson@acmvm.bitnet ------------------------------ End of RISKS-FORUM Digest 12.44 ************************