Subject: RISKS DIGEST 17.24 REPLY-TO: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Thursday 10 August 1995 Volume 17 : Issue 24 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Air-Traffic Control Woes (PGN) False zero reading possible on voltmeter (Mark Brader) An unusual off-by-one error (Mark Brader) Emulating failures (Raymond Turney) Cellular-phone stuff (Martin Cohen) Kane v. McDonnell Douglas (Susan Kinney via Dan Stone) Australia next to ban PGP (Ross Anderson via Dave Farber and Lance J. Hoffman) Re: Dave Parnas on Tenth Anniversary Issue (Paul Green) Re: Warning on Using Win95 (Brad Silverberg) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 10 Aug 95 7:45:31 PDT From: "Peter G. Neumann" Subject: Air-Traffic Control Woes The Federal Administration's Fremont (Oakland) air-traffic control center was "off-the-air" yesterday (9 Aug 1995) due to a local power outage. Power died at 7:13 a.m. as technicians were doing maintenance. Both the archaic system and the even more archaic backup system were down. The center lost all radar and radio contact with airborne planes, which is most unusual -- although it has happened before. The immediate effects continued for over one hour, and the aftereffects lasted long after that as planes were kept on the ground waiting for the mess to clear. (The Oakland center covers an 18-million square mile circle including the northern California border and San Luis Obispo to the south, more than half way to L.A.) Fortunately, the weather over northern California was good, and en-route flights could operate visually. [Source: David Dietz, San Francisco Chronicle, 10 Aug 1995, p. 1. David noted that in the past four months, computers have failed 20 times at the ATC centers in Chicago, Washington DC, Dallas-FortWorth, Cleveland, and New York. Long-time RISKS readers are not surprised. ------------------------------ Date: Wed, 9 Aug 95 16:42:18 EDT From: msb@sq.com Subject: False zero reading possible on voltmeter I'm merely re-forwarding this item, whose original author is not given. I saw it in sci.engr.safety, to which it was forwarded by Kermit Carlson (carlson@okra.fnal.gov) at Fermilab. " ...The defective units are Fluke 70 Series 2 and Fluke 77 Series 2 The problem occurs when the DMM is used to test D.C. voltages between 500 and 1000 volts. If the test leads are connected to the D.C. source terminals with reversed polarity, the display will read 0 volts. If the leads are then reversed to the correct polarity, the display remains locked on the zero volts reading. Therefore, someone could be testing a 1000 volt D.C. source, and obtain a reading of zero. If this meter is being used to verify a de-energised state, there is a risk of unintended contact with a lethal voltage...." Carlson adds: The memo does indicated that this false zero reading and the locked-up state has been verified by the manufacturer. I'm not familiar with the particular model in question, but presumably it has a digital display, and hence is fair game for RISKS. For those who don't know, the odd-sounding Fluke is a genuine company name. Mark Brader, msb@sq.com SoftQuad Inc., Toronto ------------------------------ Date: Mon, 31 Jul 95 15:28:15 EDT From: msb@sq.com Subject: An unusual off-by-one error The Usenet sci.math FAQ list discusses, among other things, the question of whether it is appropriate to consider that 0^0 (where ^ means exponentiation) has a well-defined value or not. The following paragraph, arguing that 0^0 should be defined as 1, is stated to appear at page 162 of "Concrete Mathematics: A Foundation for Computer Science" (Addison Wesley, 1989, ISBN 0-201-14236-8) by Ronald L. Graham, Donald E. Knuth, and Oren Patashnik: | Some textbooks leave the quantity x undefined, because the functions | 0^0 and x^0 have different limiting values when 0^x decreases to 0. | But this is a mistake. We must define x^0=1 for all x , if the | binomial theorem is to be valid when x = 0 , y = 0 , and/or x = -y . | The theorem is too important to be arbitrarily restricted! By | contrast, the function 0^x is quite unimportant. Obviously the first two quoted lines are garbled. In fact, the corresponding text in the book actually reads: Some textbooks leave the quantity 0^0 undefined, because the functions x^0 and 0^x have different limiting values when x decreases to 0. (Except that it uses proper exponentiation signs.) I emailed the list's maintainer, Alex Lopez-Ortiz, to point out what I assumed was a typo. He replied to say that actually the error was the result of a bug -- he had used a program to remove LaTeX math formatting codes from an online copy of the paragraph, and it had apparently shifted each formula by one position in the text! Mark Brader msb@sq.com SoftQuad Inc. Toronto ------------------------------ Date: Tue, 08 Aug 1995 17:23 -0700 (PDT) From: Raymond.Turney@ncal.kaiperm.org Subject: Emulating failures It is not clear that the possibility of emulating hardware in software, and thus the possibility of creating software that emulates hardware so so closely as to be subject only to the same failure modes as hardware, says anything at all about the potential reliability of software in other contexts. If I understand things correctly, most hardware is self referential, intended to do a limited number of clearly specified things well. Most software, on the other hand, is directed at a real-world task or tasks ... which can easily be either incompletely understood or misunderstood altogether. It may be the case that what hardware is normally supposed to do is better understood in the CS world than all the strange things non computer scientists ask software to do. If this is the case, software is less reliable -- not because of the medium, but because a vaguer definition of, and lesser understanding of, the task to be performed leaves more room for error. Or, the reliability of software is less because the risk of human error is greater, in the tasks which it is customarily applied to. Raymond Turney ------------------------------ Date: Tue, 1 Aug 95 13:46:51 PDT From: Martin Cohen Subject: Cellular-phone stuff Well, I am now one of those whose cellular-phone number was duplicated. According to AirTouch Cellular, this was discovered when the pattern of calls using my number changed (from 1-2 minutes a day to 1 hour a day!). The detection of this type of change is clearly (IMHO) a good use of technology. While talking to the customer service rep, I asked about the risk of digital phones to the hearing impaired (and their hearing aids) as reported in an earlier risks. She said that the European phones were higher powered and that the American phones, because of their lower power, were safe. I asked her to ask that this be checked anyway. ------------------------------ Date: Wed, 9 Aug 1995 09:30:07 -0500 From: d-stone1@uiuc.edu (Dan Stone) Subject: Kane v. McDonnell Douglas Date: Wed, 9 Aug 1995 08:24:46 -0500 From: Susan Kinney Subject: Kane v. McDonnell Douglas To: Multiple recipients of list ISWORLD Have any of you written up the Kane Carpet Co. v. McDonnell Douglas Corp. suit as a case? Below are details if you are unfamiliar with the case. Susan Kinney MISTRIAL DECLARED IN KANE CARPET CASE, The Record, April 6, 1994; Pg. D03 Seven months into a jury trial in which the Kane Carpet Co. claimed that it had gone bust because of a computer, a Superior Court judge has declared a mistrial. Judge Mark A. Baber issued the decision this week after Kane's former president, Richard Lehmbeck, testified that he had suffered a nervous breakdown affecting his recall of events in 1989, when the computer went on line; and in 1990, when Kane folded. The onetime Secaucus-based distributor of floor coverings has claimed that a McDonnell Douglas Corp. computer system destroyed its business in a few weeks as complaints about incorrect invoices and duplicate deliveries piled up. McDonnell Douglas denies any responsibility for Kane's demise. The case is expected to be rescheduled for a new trial. Dan Stone, Associate Professor, Univ. of Illinois, Dept. of Accountancy, Champaign, IL 61820 217-333-4537 d-stone1@uiuc.edu fax: 217-244-0902 ------------------------------ Date: Tue, 1 Aug 1995 20:36:29 -0400 (EDT) From: "Lance J. Hoffman" Subject: Australia next to ban PGP Date: Tue, 01 Aug 1995 15:29:05 -0400 From: Dave Farber Subject: Australia next to ban PGP [unverified info ...] From: rja14@cl.cam.ac.uk (Ross Anderson) Australia's proposed crypto policy: (1) Banks will get key escrow (2) Other Australian residents will be forced to use weak crypto Source: talk by Steve Orlowski, Assistant Director, Australian attorney general's department, given at the Cryptography Policy and Algorithms Conference, Queensland University of Technology, last month. p 34: `the needs of the majority of users of the infrastructure for privacy and smaller financial transactions can be met by lower level encryption which could withstand a normal but not sophisticated attack against it. Law enforcement agencies could develop the capability to mount such sophisticated attacks. Criminals who purchased the higher level encryption products would immediately attract attention to themselves.' He mentioned that his department considered itself a suitable repository for the government central decrypting unit, which would decrypt traffic for local police forces. He also wants to escrowed keys for banks and other organisations allowed to use strong crypto. Centralising the wiretap capability with the AG is represented as a useful safeguard against abuse of power by local police forces. It would be presented as a `data recovery' facility in order to reassure the voters. Centralisation will enable the AG to acquire the capability to use ``more sophisticated techniques in circumstances where the key cannot, for whatever reason, be recovered from escrow''. So the technical parameters would appear to be: 40 bit keys for the masses, 56-bit escrowed keys for the banks, and a Wiener machine sitting in Orlowski's office. Belt, braces and string. Curiously enough, he quotes a `Review of long Term Cost Effectiveness of Telecommunications Interception' as saying that ``Encryption by targets of their communications (both voice and data) is not considered as a problem for TI at present in Australia'' and goes on to say that ``there has been comparatively little market for voice encryption products, although they have been readily available''. He even produces some good arguments for the EFF, such as that much of the intelligence comes from the call log data and from calls to third parties such as airlines and hotels which are not encrypted. He also says that the OECD countries will hold a meeting on National Cryptography Policies later this year. While at the conference, I found out that a classified meeting took place this March in Germany between the signals intelligence agencies of the developed countries, plus Australia and South Africa, at which the assembled spooks agreed to press their governments to bring in escrow and/or weak crypto. Australia seems rather eager to lick Uncle Sam's boots on this issue. I wonder what the payoff was? ------------------------------ Date: Wed, 9 Aug 1995 12:16:55 EDT From: Paul_Green@vos.stratus.com (Paul Green) Subject: Re: Dave Parnas on Tenth Anniversary Issue Prof. David Parnas makes a good point that it would be nice for each of us to contribute more original success or failure stories and to rely less on the popular press for our data. I'd like to expand on this idea, and, in the future, I will try to contribute some unpublished stories. As someone who works for a company that sells fault-tolerant computers, which are designed never to fail, I've often wondered why failures of our systems (unfortunately, being human beings, neither we nor our systems are perfect) aren't reported in the press. It finally dawned on me that the answer is very simple: our customers do not want their failures reported. Failures reflect poorly on the person who selected or implemented the system, on the department responsible, and on the business and its image in the marketplace. Failures hurt customers and lose business. (After all, that's why they are buying our equipment in the first place!) If you call a company whose systems are dead on the floor, some may admit it, but I also know of instances where they have claimed to be "updating their files" or "on holiday" or almost anything that would get you to go away and not get angry at them. Another aspect of this denial and cover-up is that even when the fault and responsibility for the failure is clearly within the MIS department, we, the vendor, will be blamed. I just have had to learn to accept that aspect of the computer business. (We certainly ARE to blame some of the time, but we get blamed far more times). While it is healthy for society as a whole to expect perfection and to not tolerate failure, we also have to find a way to get society to expect honest explanations and total ownership of responsibility. Having worked with Japanese, European, and American companies, my feeling is that the Japanese are the best at this, the Europeans are second, and the Americans are far behind. All of them will berate you for a failure and want a quick workaround and a solid fix, but typically only the Japanese want to know what was the root case of the failure, and what process changes you are instituting to avoid this problem in the future. This kind of customer pressure to "do the right thing" is incredibly helpful within the company towards ensuring that we understand and truly correct the problems. I wish more customers did this. Total Quality Management (TQM) programs seem to be a pretty good tool for fixing these problems within a company. In my personal, everyday life I've made two small changes to try to help the world at large. One is to refuse to accept the stock phrase "it was a computer error" when I receive it; the other is to ask why the failure occurred and what will be done to prevent it from happening again. The end result of this human tendency to cover-up failures, deny responsibility, and let vendors off too easily is that we are getting neither the awareness nor understanding (to borrow from Parnas) that is possible. I'm sure that the press is able to report on only a small fraction of the actual failures that occur; I'd guess less than 1%. Airline pilots have a way to report problems anonymously; perhaps we need a similar program in the systems business. Paul Green, Director, VOS Planning, Stratus Computer, Inc., Marlboro, MA 01752 (508) 460-2557 Paul_Green@vos.stratus.com FAX: (508) 460-0397 ------------------------------ Date: Sat, 05 Aug 95 15:31:00 PDT From: bradsi@microsoft.com (Brad Silverberg, Sr VP Microsoft Corp) Subject: Re: Warning on Using Win95 (RISKS-17.21) The FACTS: These stories are NOT TRUE. 1. A user may choose to register by the paper card, electronically, or not at all. It is completely the user's choice. The online registration application is an electronic version of the paper registration card that traditionally comes with all Microsoft products. The intent is to offer customers a convenient and helpful way to register. The registration application must be explicitly run by the user and the user supplies, completely on a voluntary basis, similar information that he would with the paper registration card. When the user runs the app, it asks for the typical information, such as name, address, company, as well as system configuration info for that PC (things such as type of CPU, RAM, hard disk space, etc.) and what products the user may have installed. This is done only with the user's consent and not required to complete the registration. There is no default answer to the question of whether to include the system information or not: it requires an explicit Yes by the user. What's more, if the user says No to the system info, then the app does not even bother asking about the product info (and doesn't send it); if the user says Yes to the system info, then the user is led to the product info screen and has to explicitly say Yes to it too. The app does not send any user info that the user is not aware of and not explicitly agreed to. In particular, the app does not send any files such as config.sys, autoexec.bat, or the registry -- just the info that was on the screen and that the user said Yes to. Nor does the registration application look out on the network. It only looks at the PC the app is being run on. 2. MSN is involved with the registration application only in that it uses the MSN transport to upload the registration information. You don't have to be an MSN member to register, and once you register you are not an MSN member. 3. MSN does NOT transmit the user's directory structure or file names. MSN only uploads the version of the Win95 build and the language that is being used on the computer, and any other user initiated information, such as BBS postings and email. MSN uploads the build and language info so that its on the fly upgrades are synched up with the version of Win95 on the PC being upgraded and in the right language. MSN is not uploading any other information about the user's PC or files. In addition, we have set up a section on our Windows web page for "clarifications" -- where we place our responses or position on topics such as press reports, rumors, etc. The web address is: http://www.microsoft.com/windows/pr/clarifications.htm. We've posted our FAQ on the regwiz rumor there (http://www.microsoft.com/windows/pr/regwq&a.htm). Feel free to redistribute or point people to it. Thanks! [My sincere apologies to Microsoft, and to Paul Saffo who was a completely innocent bystander. He did not write the piece in RISKS-17.21, and I should either have not run it or else run it without his identity, because he did not submit it to RISKS. Thanks to Brad for making the effort to clarify the issues. I always greatly appreciate first-hand accounts in RISKS. PGN] [The FAQ is too long for RISKS, but is available for anonymous FTP in RISKS-17.24msfaq . PGN] ------------------------------ Date: 9 August 1995 (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 the newly automated , with first text line SUBSCRIBE or UNSUBSCRIBE [with option of E-mail address if not the same as FROM: on the same line]. HELP gives instructions on using the Majordomo listserver in other ways. 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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.24 ************************