Subject: RISKS DIGEST 16.47 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 20 October 1994 Volume 16 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** Contents: Computer mess at Greyhound (Phil Agre) British Rail Journey Planner (Marcus Reynolds via Clive D.W. Feather) Spin control by computer (Rob Hasker) Tampering blamed for rebuffed candidacy in Peru (PGN) Re: Data Security in Iceland; Software Bug Cripples Singapore (Jim Haynes) Tarom Airbus: automatic mode switch escaped the commandant (Daniel Salber) Computer risk that nearly proved deadly (Carl Maniscalco) Software reuse (Mark Gonzales) Risk of seeming similar interfaces (Monta Elkins) Re: squirrelcide (Douglas W. Jones) Re: CNID (Peter da Silva, Scott E. Preece, A. Padgett Peterson) Washington DC ACM Professional Development Seminars (John Sheckler) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 20 Oct 1994 11:55:19 -0700 From: Phil Agre Subject: Computer mess at Greyhound The 20 Oct 1994 Wall Street Journal contains an article about computerization at Greyhound that you'll have to read to believe. The full reference is: Robert Tomsho, How Greyhound Lines re-engineered itself right into a deep hole, Wall Street Journal, 20 October 1994, pages A1, A10. After Greyhound came out of bankruptcy a few years ago, a new management team declared that they would revolutionize the company but cutting costs and creating a huge computerized reservations system to replace the existing collection of incompatible systems and things done by hand. They called it "re-engineering". Wall Street liked this idea and bid up the company's stock price. The managers, feeling obliged to keep the stock price up, promised that the system would work on schedule. But of course it didn't, for reasons that won't surprise Risks readers. The main problem is that buses make many more stops than airplanes, meaning that a bus scheduling system is an order of magnitude harder to build than an airline scheduling system, which is already one of the most complex things anybody ever built. The system started slipping behind schedule, and the prototype had a terrible interface, crashed all the time, and hung up on people. Meanwhile, Greyhound was falling apart. Employee turnover was very high, customer service was terrible, the computer was messing up everything it touched, and the company advertised a discount program even though it had no chance of handling the expected volume of business. Yet the stock price stayed high because stock analysts, who make dramatically more money than Greyhound's customers, don't ride buses and so didn't see the problems. This postponed the day of reckoning long enough to cause tremendous disruption for the customers -- and long enough for the top managers of the company to cash in a pile of options while the stock was still at its highest level. "Looking back, Mr. [Thomas] Thompson [the vice president in charge of developing the system] says, "I should have quit or just said that I couldn't do it." Instead, most copies of his report [warning of difficulties with the system] were destroyed, and any mention of it was purged from many Greyhound agendas, calendars and computer files, many people say." It's distressing that words like "re-engineering" can have such magical force for so many people that well-known pitfalls in system implementation can go undetected for so long -- except, of course, by the working people who have to use the systems or get around on the bus. Phil Agre, UCSD [But don't wait for Greyhound to put on the dog. PGN] ------------------------------ Date: Mon, 17 Oct 1994 12:03:41 +0100 (BST) From: "Clive D.W. Feather" Subject: British Rail Journey Planner On Saturday morning, 15 Oct 1994, two trains collided head-on on a section of single track south of London. The causes of the crash aren't yet known, but someone on the newsgroup uk.transport looked up one of the trains in question using British Rail's own software (sold to the public): > Newsgroups: uk.transport > From: Marcus@mreyno.demon.co.uk (Marcus Reynolds) > Subject: BR Journey Planner (Uckfield - Oxted) > Date: Sun, 16 Oct 1994 09:12:21 +0000 > > When asked for the times of trains between Uckfield & Oxted on a Saturday > morning, British Rail's own Journey Planner software offered:- > > Arrival Departure > Uckfield 8:00 > Cowden 8:29 8:29 no change > Oxted 8:48 > Journey time 0:48 > > Other Solutions > > INTERRUPT 0DH, GENERAL PROTECTION FAULT possible illegal address > error code = 0000 > > [Etc., etc.] > > Clearly this is a computer programme with second sight. [MR] Clive D.W. Feather, Santa Cruz Operation, Croxley Centre, Hatters Lane, Watford, WD1 8YN, United Kingdom clive@sco.com +44 1923 813541 FAX-813811 ------------------------------ Date: Fri, 14 Oct 1994 13:19:38 -0500 From: Rob Hasker Subject: Spin control by computer As to be expected, the governor's race in Illinois is pretty heated and involving a fair bit of mud-slinging. The latest story (reported in the Oct. 11 Champaign-Urbana News-Gazette) concerns the husband of one candidates, Dawn Clark Netsch; apparently he failed to pay property taxes for four years on a condominium in Chicago that they owned. Of interest to RISKS readers is that he blames the problem on a computer at the county tax office; he claims that he didn't pay because the county sent the tax bill to the wrong address. The condo is on Goethe street, and the story is that both E's in the street name were dropped in the county tax records, leaving `Go th' and making it appear that the street was `60th.' According to Netsch's husband, this meant he never got the tax bill. Whether or not this is a valid excuse, I thought it was an interesting application of computers to spin control. Rob Hasker hasker@cs.uiuc.edu ------------------------------ Date: Thu, 20 Oct 94 10:00:22 PDT From: "Peter G. Neumann" Subject: Tampering blamed for rebuffed candidacy in Peru Susana Higuchi, deposed wife of Alberto Fujimori (president of Peru), had her presidential hopes quashed by Peru's electoral board because of a shortage of valid signatures. Higuchi claims to have submitted about 130,000 signatures, while the board claims only 11,851 were valid, short of the required 100,000. Higuchi claimed some 150,000 signatures were erased from her party's computers during a blackout that affected only the block in which her offices were located. She blamed her husband's cronies for high-tech fraud. [Source: San Francisco Chronicle, 20 Oct 1994] The moral of this story is certainly familiar to RISKS readers. I paraphrase an old song: Backup your troubles in your old kit bag, and smile, smile, smile. [And read the next item. PGN] ------------------------------ Date: Thu, 20 Oct 1994 14:55:17 -0700 From: haynes@cats.ucsc.edu (Jim Haynes) Subject: Re: Data Security in Iceland; Software Bug Cripples Singapore >From: hauh@ismennt.is (Haukur Hreinsson) >Subject: Data security in Iceland >[story of theft of a computer, containing the only copy of a writer's MS] Some years ago I received a letter from the publisher of a small magazine that I subscribe to. Someone had broken into their office and stolen the computer, and (this was back in CP/M days) all the floppy disks that were nearby. So they had done a mailing from some old paper copy of a list of subscribers, and were asking us to tell them when our subscriptions expired, by looking at mailing labels on the last copies received. Ever since then, wherever I go, I preach to people about making backups and keeping a copy of the backup in some safe place where it won't be easy to steal along with the computer. I wonder if there's a way to get this message out to the myriads of small business and organization people who aren't in a position to read the computer industry literature. If only we could get the story to be spread and repeated as well as the Craig Shergold plea and the gold star tattoo urban legend! >From: Lee Lup Yuen >Subject: Software Bug Cripples Singapore Phone Lines I wonder if the writer of the software bug will be tried and sentenced to caning. A new concept in software quality assurance! ------------------------------ Date: Wed, 19 Oct 1994 23:59:21 +0100 From: daniel.salber@imag.fr (Daniel Salber) Subject: Tarom Airbus: automatic mode switch escaped the commandant's notice This is a shortened translation of an article published in Le Monde, date 16-17/10/94, p. 9. Le Monde is considered by many as the major and most-respected French daily newspaper. It always has very documented and accurate reports. Thanks to Francis Jambon for help with the translation of technical terms. In-flight stall of an A310 Airbus An automatic mode switch escaped the commandant's notice The investigation commission shed more light this Friday on the incident that involved an A310 of the Tarom airline on the 24th of September over the Orly Paris airport. It appears that the aircraft which was in "landing approach" mode was too fast. This triggered a "mode" switch response from the aircraft. In other words, the aircraft started to go upwards to slow itself down. The aircraft was flying at 364 kilometers per hour (226 mph or 202 knots), slightly over the speed limit of this configuration which is 360 kmph (224 mph or 200 knots). This triggered the automatic response. The pilot tried to counter its effect and thus started a process that provoked the stall of the aircraft. This new information lead the French civil aviation authority (DGAC) to decide to inform immediately the French airlines that use A310s and A300-600s equipped with the same protection mechanism. The DGAC asked the airlines to draw the attention of the crews on the required observation of established speed limits. Airlines should also make sure that the crews are perfectly-well informed of the logics of the protection system that automatically triggers in case of abnormal speed. Daniel Salber, Grenoble, France, Daniel.Salber@imag.fr ------------------------------ Date: Tue, 11 Oct 94 17:17:50 EDT From: HeavyWater@aol.com Subject: Computer risk that nearly proved deadly A woman with whom I am acquainted recently wound up in the intensive care unit of a local hospital due to a computer risk. The woman, who has been in ill-health for some years and has been undergoing regular dialysis, accidentally pulled out her shunt (a semi-permanent connection point for the dialysis machine) while sleeping and had to undergo urgent but relatively minor surgery at the local hospital emergency room. During this procedure, the ER physician - who had been informed that the woman had a pacemaker implanted - used an electrocautery device to stop the bleeding. The surgery itself went well; however, the woman's condition deteriorated. After some days went by and doctors had told relatives that the woman was not expected to survive, it was discovered that the electromagnetic field created by the electrocauterizer had apparently corrupted the software of her microprocessor-controlled pacemaker, causing it to fire in a pattern out of sync with her natural cardiac rhythm. The difference was slight enough to avoid immediate detection but serious enough to cause problems. A representative of the pacemaker's manufacturer was able to reprogram the unit (using data transmitted to the still implanted unit as audio tones via a transducer) and the woman is now recovering quite nicely. I believe the risk here is pretty obvious. Carl Maniscalco (heavywater@aol.com) San Diego, CA ------------------------------ Date: Wed, 19 Oct 94 14:39:18 PDT From: markg@ichips.intel.com Subject: Software reuse There's an interesting letter in the October '94 IEEE Computer Magazine (page 5). I'll quote the first paragraph: Marty Leisner of the League of Programming Freedom writes: Capers Jones had a nice article in Computer on the economics of software re-use, but he should have changed "First, you cannot safely reuse garbage." to "First, you cannot economically reuse garbage." Many computer applications don't exhibit "safety" aspects (the worse that can happen is they do not work as advertised). I think this is a risky attitude in the modern world. Almost any program that produces output that is used by humans can have a safety aspect - people can be physically or economically injured if the application gives the wrong answer. This means any program from a spreadsheet, to a C compiler, to a nuclear power plant control system can be safety critical for some or all of its users. Published reusable software should be as carefully designed and verified as any other safety critical software, since its publishers will have no control over what systems it gets reused in. Mark Gonzales markg@ichips.intel.com ------------------------------ Date: Thu, 20 Oct 1994 13:16:39 -0400 From: Monta@vt.edu (Monta Elkins) Subject: Risk of seeming similar interfaces We're a PC compatible office that may switch to Power Mac's (due to external economic incentives). While installing software on a new Power MAC my colleague needed the serial number on the disk in the drive. He reflexively reached up and pressed the button below the disk drive to eject the disk, except on the Power Mac this is the POWER button. This crashed the installation (and generally confused the operating system). For a company that actively seeks converts from the PC compatible market; they (Apple) should have caught this problem and moved the power switch AWAY from the disk drive. This illustrated the risk of SEEMINGLY similar interfaces. (maybe pressing the power off button should light a second button, labeled "Are You Sure?" :) ) monta@vt.edu Monta Elkins Career Services Virginia Polytechnic Institute and State Univ. ------------------------------ Date: Thu, 20 Oct 94 09:57:37 CDT From: "Douglas W. Jones" Subject: Re: squirrelcide (PGN, RISKS-16.46) A brand-new locally invented anti-squirrelcide device is currently under test by Iowa Illinois Gas and Electric in my neighborhood. Their initial reports are extremely favorable (transformers equipped with the device in a 6 month test run killed no squirrels, other transformers in the same area had their usual kill rate). Given that it costs the utility about $100 a squirrel kill to replace blown fuzes etc, the device is showing up as a winner (it's trivial to install and inexpensive). The device is a band which snaps around the insulator on the high voltage feed to the transformer (the favored site for squirrels to zap themselves) and gives them a warning tingle before they get a chance to do themselves in. Just a plastic band with stainless steel fingers, with all electric current needed to provide the tingle coming from leakage through the air and over the insulator surface. SRI and PG&E ought to look into something like it! Doug Jones jones@cs.uiowa.edu ------------------------------ Date: Thu, 20 Oct 1994 12:25:20 -0500 From: peter@nmti.com (Peter da Silva) Subject: Caller ID flamage... not again... Another Anti-CNID fella misses the point: > The article states clearly that the real reason for CNID is commercial. Be that as it may, we have CNID now and it's proven a valuable weapon against telemarketers. Virtually all telemarketers call from their own business phone, transmitting the business address. It's great: here's three calls fifteen minutes apart from the Houston Symphony. No thanks. We can pick and choose who we want to listen to (Hi! Sure, I've got a bag of clothes for your charity) and who we want to do the receiver drop on (companies with names like Allied Marketing are a good choice). Best of all, I can call my wife! She's a little phone-shy, so she doesn't answer the phone much during the day... but with CNID she knows it's from work and I can talk to her. > Privacy advocates have been saying this for years, and for a long time they > have gotten patronizing lectures about how CNID is for residential use in > catching harassing phone callers. CNID is for all sorts of things, including things the companies pushing it have never thought of. I include telemarketers in the category of harassing phone callers and it catches them just fine. > But CNID is a poor way to catch harassing phone callers. Really? You think it's responsible to call the cops on some dumb kid with a little spare time? I call their parents and let them resolve the problem at home. Haven't used CNID for that yet, but Call-Return worked in one case... in the other the kids called when their parents were out :-< but next time they'll have to deal with daddy :->. [stock id-blocking feature list] Your enhancements are fine, and I have no problem whatsoever with them. I would still buy CNID with them in place. In fact I'm pretty sure they are... I've had a couple of calls like that... and I still bought the service. Certainly the local stores selling ID boxes are doing a brisk business. I don't know who you think CNID proponents are, but it's nowhere near as simple as you make it out. > What can you do? Well for a start you can quit pushing it as a "pro-CNID" "anti-CNID" argument, because all that does is polarise people who *would* be on your side into taking an opposed position just to defend a capability they consider important. And you can quit acting like all the pro-CNID people are nasty telemarketers, too. You can catch more flies with honey, and all that rot... ------------------------------ Date: Thu, 20 Oct 1994 08:27:21 -0500 From: preece@predator.urbana.mcd.mot.com (Scott E. Preece) Subject: Calling Number ID debate Phil Agre suggests some simple rules for calling-number ID. I'd like to promote a simple adaptation that would retain essentially all of the subscriber benefit of CNID, even when blocked. Require the phone company to assign a second unique number (a blind identifier, not a directly dialable number) to each telephone and supply that number, instead of the regular phone number, when the caller is blocking. This would allow the recipient to identify the caller without giving the recipient a callable number. As an enhancement, the phone company could be allowed to offer to attempt calls through that number (call an 800 number then key the blind identifier), but the subscriber must be able to specify that (1) all such calls are to be rejected, (2) all calls from a particular number are to be rejected, or (3) all calls from a particular number are to be accepted. I don't think this represents a serious technological hurdle; I think it answers the privacy concerns and provides a significantly more useful service than one that allows simple blocking. scott preece motorola/mcg urbana design center 1101 e. university, urbana, IL 61801 217-384-8589 preece@urbana.mcd.mot.com fax: 217-384-8550 ------------------------------ Date: Thu, 20 Oct 94 09:55:17 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Calling Number ID Debate First, readers should be aware of the CNID FAQ which I wrote some time ago - it is available at the Telecom archive or I can send a copy. Second, I am strongly in favor of nationwide CNID as should be all system owners with dialup lines (of course I am also in favor of Clipper as soon as the gov - next month ? - drops key escrow so be forewarned 8*). Why, because with CNID, crackers/phreaks/war dialers will have to find another way - unless the number is known and on an approved list, the modem doesn't answer at all. True, not all people call in from known numbers but in the two years I have been testing, a very high percentage - over 80% - of the dialins are local and known. Of the other 20%, nationwide CNID will handle about 5% leaving 15% that will need a different number to dial and OTP devices. Further, since starting to play with this two years ago (my FreeWare .ASP for Procomm + is still in the Telecom archives), I have found it possible to not only block unwanted calls but create a tailored menu/connection for employees calling from home that connects directly to their preferred platform (normal authentication is still required but it does not have to be multi-step). Somehow in all of the noise, this market seems to have been missed entirely but with more and more telecommuters/service providers/dial-up accounts/etc. it is a natural protection and additional layer of security/logging that also happens to be invisible to conventional attack. True, a caller does not have to give their number and the telcos will provide means to accomplish it but *I reserve the right not to answer blocked calls*. Using crude equipment (a Supra (plug) v.32b modem - the CNID was a $20 option) this was possible two years ago. What I do not understand if why more people are not using it - a whole untapped market that seems to have been ignored. Sure there are problems - my biggest one was the time to scan an "approved" list that kept growing using a 386-25/ST-225 combination - sometimes it would take five rings before the whole list could be scanned & the modem told to answer - but that's what engineers are for 8*). Padgett ps please do not inquire about a product. Other than the original freeware .ASP, the rest has been a hobby: there is no GUI or pretty packaging, that's what vendors are for. The point is it *can* be done - after proving that, I tend to lose interest. ------------------------------ Date: 20 Oct 1994 10:53 EST From: ndqajds@atscv1.atsc.allied.com (John Sheckler, ATSC, 301/805-3258) Subject: Washington DC ACM Professional Development Seminars The Professional Development Committee of the Washington, D.C. Chapter of the Association for Computing Machinery (ACM) presents technical and management seminars for computer professionals and managers. This fall, the Committee will offer ten one-day professional development seminars during the week of November 14 - 18, on topics of current interest. Monday, November 14 Mr. Allen S. Perper - Business Process Engineering/Reengineering Mr. Will Tracz - Domain-Specific Software Architectures -- Process, Products, and Infrastructure Tuesday, November 15 Dr. Cy Svoboda - Information Engineering Mr. Mike Gorman - Managing the Development of Client/Server Applications Wednesday, November 16 Mr. Ed Krol - The Whole Internet -- Archie, Veronica and the Gopher Explore the World Wide Web Mr. William Durell - Data Administration and Management Thursday, November 17 Dr. Robert N.Charette - Profiting from Risk Management of Business Processes Mr. Watts S. Humphrey - Personal Process Improvement Friday, November 18 Dr. Robert S. Arnold - Legacy System Migration Mr. Edward V. Berard - Testing Object-Oriented Software Additionally, on Thursday, November 10, 1994, the Professional Development Committee will host our 13th International Speaker, Philip Zimmermann, presenting a seminar entitled "Public Key Cryptography." Thursday, November 10 - 13th International Speaker Mr. Philip Zimmerman - Public Key Cryptography The seminars will be held at the Center of Adult Education, University of Maryland, College Park, Maryland, at the intersection of University Boulevard (MD 193) and Adelphi Road. The seminars run from 9:00 a.m. (registration at 8:30 a.m.) until 5:00 p.m. Attendance at each course will be limited to the capacity of the room being used (check with the ACM/PDC answering machine, (202) 462-1215, for availability). Detailed registration information and assistance can be obtained by calling Nora M. Taylor (301) 229-2588. Additional information about the Fall 1994 professional development seminars presented by the Washington, DC Chapter of the ACM can be requested via e-mail to dcseminars@acm.org and is available also via anonymous ftp from acm.org in: chapter_forums/chapter_articles/prochap/DC_ACM_Fall_94_PDS_General.txt . A description of each seminar is available also. [File names deleted, along with registration info.] ------------------------------ Date: 20 October 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.47 ************************