Subject: RISKS DIGEST 13.09 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Saturday 1 February 1992 Volume 13 : Issue 09 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Confusing Telephone System Overload Message (Bruce McCulley) Re: Airbus A-320 (Helen Trillian Rose, anonymous, Harry Erwin, Joe Morris, Dave L. B., James B. Shearer) Communication between ATC and pilot (Ian Moor) Another hacking myth (Robert Jenkins) World Bank Virus [anonymous] Australian Tax File Numbers (Barry Johnson) Error in 1099-G Tax Form (William Mihalo) Computer evidence is Hearsay (Kevin Stock) The absence of a warranty (Fred Gilham) Re: A Tale of Risk Avoidance [so far ...] (Rick Smith) Serious dangers in the Caltrans AVI spec [URGENT for Californians] (Phil Agre) 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 may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, 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: Thu, 30 Jan 92 11:51:03 -0500 From: mcculley@racy.zko.dec.com Subject: Confusing Telephone System Overload Message On Tuesday night (1/29/92), after President Bush's State of the Union address I happened to tune into the CBS television network as they were announcing a novel poll. They claimed nothing like it had ever been attempted before, and it sounded interesting so we stayed with them for awhile, and even tried to participate. The basis for the poll was an interactive telephone system set up at a site in Omaha, Nebraska, with an (800) WATS line to allow toll-free access from anywhere in the US. Early in the show CBS announcer Charles Kuralt reported that the telecommunications center was capable of handling thousands of calls per minute, "so there should be no problem". HA! Participation required a touch-tone phone, so that callers could respond via keypad entry to the canned questions posed by the automated response system. Although we live in a rural area with old mechanical switch gear, my phones all can switch between rotary and touchtone mode, so I could dial up using pulse mode and then switch to tone for the response. After watching a few minutes to see what additional explanations were given, I decided to try accessing the poll. At the time they seemed to be running at a couple of thousand calls per minute. My initial attempt to call them resulted in a very long dead interval, followed by a message saying "Your call cannot be completed as dialed, you must supply more digits in the number dialed." That seemed strange, so I tried redialing several times, more carefully, with similar results. Since the map showing calls received was showing nothing from our area of New England (New Hampshire and Maine were both showing null), I wondered if there was a problem with the WATS routing or something, that might have caused the strange error message. So I called the operator, and when I started to say I was having trouble dialing an (800) number she immediately asked if it was the one that had been given on TV. When I said it was, I was told that the lines were flooded. Apparently the volume of calls was either forcing the long-distance system into some strange failure mode in which it thought more digits were required in the number being called, or there was a mismatch between the particular error condition and the error message being used. I suspect, based on my limited knowledge of the telephone network, that there may have been some timeout or connection loss or contention or something that inadvertently truncated the routing information string, due to the huge volume of calls. Shortly afterward, with the display showing about 125,000 calls processed, Dan Rather reported on the air that AT&T was estimating there had been about 7,000,000 call attempts! Obviously their throughput was a little below the capacity requirements... BTW, using redial, I was able to access the number on a subsequent attempt, and did get my response included in the poll. At that time they were reporting about a hundred thousand calls processed. From the ratio of call attempts reported by AT&T to calls processed it looked to me like the ratio was upwards of 70 to 1. It took me only about ten tries or so, so I guess I was lucky. The risk seems obvious, experimenting with a novel application in a live production environment requires some careful system analysis and planning to avoid unexpected errors. One thing I'm curious about, wonder what their phone bill was? --bruce mcculley ------------------------------ Date: Tue, 28 Jan 1992 23:31:25 -0500 From: Helen Trillian Rose Subject: Speculation on latest A-320 crash: why? (Joel Upchurch, RISKS-13.08) Joel> It might be informative to compare the A-320 accident rates to Joel> other planes that have a two man crew, rather than comparing it Joel> to planes of similar size that use a three man crew. OK. We'll do this. The Boeing 757. No total hull losses. No incidents *at all*, that I can recall. The Boeing 767. One total hull loss, due to a problem with the engines (and on the engines that were least used. The ones in question were the Pratt & Whitney, while most customers had the GE/SNECMA). The Boeing 747-400 (though not a 2-engine plane, is the most "technologically advanced", aside of the A320, with an almost total glass-cockpit) some incidents, but no hull losses. The 747-400 is particularly interesting because earlier models had three flight crew members. The A-320 is about the same vintage as the 747-400, and is newer than the 757 and 767 by a good five plus years. Helen Trillian Rose EFF Systems and Networks Admin ------------------------------ Date: Tue, 28 Jan 92 12:33:32 XXT From: [anonymous] Subject: A320 crash may have been caused by ATC/Pilot miscommunication ... The AT320's fly-by-wire system or glass cockpit ... may not have been directly involved in the lastest A320 crash. A U.S. air safety source informs me that initial information suggests that a miscommunication between Air Traffic Control and the A320's pilot may have been the primary cause of the accident. Apparently the A320 was originally on a landing path to a runway with a fairly rapid descent slope. Sometime fairly late in the landing sequence, the pilot was ordered to a different runway by ATC, but may not have been warned that the new runway would require a different descent to avoid slamming into a mountain. The pilot descended at the original rate and the crash resulted. Before someone argues that the automated information transmission systems being planned would have solved this problem, it's worth noting that many are very concerned that such information systems would deprive pilots of information being sent to other planes, which they might need to know to avoid collisions or other problems. Many accidents have been avoided by pilots who heard ATC directions being given to *other* pilots (over conventional radios, of course) and realized that they themselves needed to take evasive action! ------------------------------ Date: 29 Jan 92 13:25:27 GMT From: trwacs!erwin@uunet.uu.net (Harry Erwin) Subject: Re: Speculation on latest A-320 crash: why? There is an old story about WWII in the Pacific, where an operations research team was sent to the combat zone to determine where armor should be added to the fighters in use. Originally they were going to survey aircraft returning with battle damage to see where the battle damage was concentrated--the armor was to be added to those areas. However, an older analyst pointed out that the armor should be added where there was no battle damage--planes receiving damage in those areas were not returning. Harry Erwin erwin@trwacs.fp.trw.com ------------------------------ Date: Thu, 30 Jan 92 11:09:24 -0500 From: Joe Morris Subject: Re: Another A-320 crash in France (Bennett, RISKS-13.06) >In RISKS 13.05 Romain Kroes, Secretary General of SPAC is quoted as saying >"...it has been clear to us that the crews were caught out by cockpit layout" > > Surely this statement implies that there is a problem with training >rather than the software or the crew Not necessarily. Especially in stressful environments, a poorly-designed cockpit layout can be a disaster waiting to happen. An aviation example on a smaller scale is the control panel layout of the flight instruments. For years there was no standardization of what instrument went where, neither between manufacturers or even between models. Only after studies showed that there was a quite significant safety advantage did the designers agree to the "basic" formation: airspeed artificial altimeter indicator horizon turn-and- gyro vertical speed bank indicator compass indicator Prior to the standardization these instruments could be almost anywhere in the cockpit. (Of course, we now have the interesting problem of trying to figure out how to best present the information on integrated displays in an EFIS (Electronic Flight Information System) environment.) Another example of poor cockpit design was the way that Beech Aircraft moved cockpit controls around in different years in some of its airplanes. In some years the Beech Bonanza airplane put the control for the wing flaps (which are to be retracted after landing) on the left side of the cockpit and the gear retraction switch on the right; in other years the positions were reversed...with the obvious problem of pilots retracting the landing gear while on the ground. Beech also had a disconcerting habit of not following common industry practice in the order of the engine controls: where most designers put the controls on the panel in left-to-right sequence of throttle/prop/mixture, some Beech products used throttle/mixture/prop. My point is that while training can teach a pilot about the particular idiosyncrasies (or idiotsyncrasies) of a particular airplane, a design which is nonstandard and/or unintuitive and/or misleading can be the trigger for failures which are eventually blamed on "pilot error". This does have a direct significance to the normal subject matter of the RISKS-FORUM: the design of user interfaces in software systems. In fact, it's almost exactly the same issue: poorly-designed, or nonstandard, or "slightly" different interfaces between programs which perform similar functions are one of the reasons for many of the problems we have in this industry. Joe Morris ------------------------------ Date: Sat, 1 Feb 92 15:53:12 GMT-0400 From: dlb@osf.org Subject: A320 Crash A couple of comments about topics related to the A320 crash: Potential of the FAA banning or restricting the A320 for nontechnical reasons (i.e. politics or advantage to US aircraft manufacturers): I think this is unlikely for at least two reasons. First, at least one major US airline (Northwest) has a significant A320 fleet. There may be others. If anything, the FAA is more beholden to US airlines than it is to US aircraft manufacturers. Second, the FAA is has an excellent reputation in safety matters to consider/defend. Aviation authorities in many other countries look to the FAA on aircraft safety matters, and routinely implement FAA safety directives. Issuing an unjustified safety directive with significant impact would do major damage to the FAA's status, influence, reputation, etc. 2-man crew (vs. 3-man) as a major factor. Highly unlikely. Virtually all recently manufactured aircraft (newer 737's, 757's, 767's, 747-400's, MD-80, MD-11, ... [hope this list is correct]) have two man crews. None of them have the crash record of the A320. On the other hand, I wonder if we're looking at the wrong statistics. Fatal aircraft crashes are so few and far between that it's hard (statistically) to draw reliable inferences from such spotty data. I'd be much more comfortable looking at data that included significant failures that could have caused the aircraft to crash (but the plane didn't due to skill of the crew, luck, etc.). I'm sure the FAA keeps such numbers, but of course they're not newsworthy because nobody died, and there aren't any good pictures ... --Dave ------------------------------ Date: Thu, 30 Jan 92 18:33:31 EST From: jbs@watson.ibm.com Subject: 3 man aircrews Joel Upchurch suggests 3 man aircrews will be safer than 2 man crews. Studies have shown 1 man police squad cars are safer than 2 man squad cars. Nevertheless police feel safer in 2 man cars (which may be part of the problem). I suspect something similar may be true of aircrews. James B. Shearer ------------------------------ Date: Wed, 29 Jan 92 19:35:55 +0000 From: iwm@doc.imperial.ac.uk Subject: Communication between ATC and pilot Communication between Air Traffic Control and Pilots is currently verbal and in English (as a `Universal' language). An item in a recent BBC radio program mentioned work on a possible replacement. They played back a recording of a dialogue where neither participant had English as a first language as a demonstration of misunderstandings that happen. The cure was to be a means of transmitting coded messages, presumably displayed in the pilot's native language, and presumably vice-versa. The interviewer asked `why not have the commands transmitted directly to the plane?', and was reassured that the pilot would have ultimate control. However nothing was said about: Error checking, natural language is redundant, but coded messages may not be. What happens if the message to be sent was not anticipated by the system designer (Elephant on runway ?). How the message was displayed: Headup display, voice, or another console display Ian Moor ------------------------------ Date: Fri, 31 Jan 92 20:35 GMT From: Robert Jenkins Subject: Another hacking myth There has been an instructive little flurry about hacking in the British press. It starts with Police Review, 17 January 1992: A columnist, C H Rolph, writes: "Did you know that there are hackers (i.e., people who make a hobby out of studying and programming other people's computers, or who get unauthorised access to computer systems by telephone) making a good living out of `cleaning up' people's driving licences. A wealthy man with an endorsed licence will pay a lot to have his file beautified at the Driver and Vehicle Licensing Centre at Swansea. I'm told that for 100 pounds a point, it is possible to get an endorsement completely erased, and then apply for and get an unblemished licence. Or was, until fairly recently." The Times took up this "revelation" and, on 20 January, reported that "an investigation is under way after claims that computer hackers are wiping motorists' penalty points from the DVLC computer in Swansea. The hackers are charging 100 pounds for each penalty point, according to the Police Review". On 31 January, C H Rolph returned to the affair. He referred to the Times story and said "I didn't quite say that. I said there were allegations that this *had been* going on. And it turns about that there had certainly been attempts. The Driver and Vehicle Licencing Centre at Swansea tells me that the story first appeared in the *Sun* in 1986, and that it was at once jointly investigated and refuted by the DVLA and Scotland Yard ... " Looks like pretty bad behaviour by C H Rolph (a former senior police officer, by the way). His original story seems to have had no foundation whatsoever (the *Sun* is not a serious newspaper), but he is trying to wriggle out of accepting fault. And the Times doesn't come out of it well, either. Doesn't *anyone* check out hacking stories, or do journalists prefer urban myth. (I write as a journ.) [This sounds as if an old tale had been warmed over. See RISKS-2.38, 8 April 1986, for Brian Randell's contributed item on the alleged DVLC hacking activities. (See also Software Engineering Notes, vol 11, no 2, April 1986, page 4. [The reference is WRONG in the RISKS INDEX, which appears once again in the January 1992 issue of SEN, pp. 23-32. I just noticed that in digging for the original.) PGN] ------------------------------ Date: Recently From: [anonymous] Subject: World Bank Virus The bit about the World Bank virus [Ted Lee, RISKS-12.36, and Software Engineering Notes, Vol. 16 No. 4 (Oct. 1991) p.17] was actually a bit overblown. A few dozen networked PCs did get hit, but it was just one of those things that came off a diskette of questionable origin. There was no `international army of nerds and police experts' required to track it down, although it did occupy internal staff for several days to clean it out. Apparently the Bank's efforts to have Time print a correction came to naught. ------------------------------ Date: Wed, 29 Jan 92 10:12:00 EST From: BARRY JOHNSON Subject: Australian Tax File Numbers Reading the January 1992 `Inside Risks' column in the CACM reminded me of what seems a very relevant article in "The Australian Computer Journal", Vol. 22 No. 1 (February, 1990) pp. 11-20 [published by the Australian Computer Society (ACS)]: 'Implications of the tax file number legislation for computer professionals'. After years of public resistance against anything like a Social Security Number, the Australian Government finally opted for a 'tax file number.' Although organisations such as employers and banks are expected to collect this number so that it can be included when submitting information to the federal tax authorities, there are also VERY strong legislative safeguards: - It can ONLY be used for tax-related functions. - It must NOT be disclosed to anyone who does not need, nor revealed if not immediately relevant. - It may NOT be used as a national identification scheme nor for building up a database on individuals nor for matching personal information. After discussing the meaning and implications of the legislation, the article touches on implementation issues (access control, personnel screening, communications and operating system security, and professional responsibility) that relate to the securing of the number. It discusses in some detail the choices of including the tax file number in a file/table with other personal information versus isolating it in a separate file/table. Interestingly, the article opens by noting that the legislation is based on privacy principals espoused by the Organization for Economic Cooperation and Development (OECD). It might be interesting to know what they are exactly ... If you would like a copy of the article and are unable to get it from anywhere else, I would be glad to send a copy if you can provide an address. Regards ... BJ ------------------------------ Date: Wed, 29 Jan 92 12:12:53 -0600 From: wmihalo@lucpul.it.luc.edu (William Mihalo) Subject: Error in 1099-G Tax Form Last week I received an erroneous form 1099-G from the state of Indiana. The form erroneously claimed that I had received a large tax refund from the state. A call to the local state revenue office revealed that a faulty computer algorithm had created the problem. Apparently, if you claimed a tax refund or received a tax deduction, and also filed an estimated tax payment for the first quarter in 1991, the algorithm >added< the two numbers together rather than subtracting one from the other. In my case, the error was compounded by a combination of a misplaced decimal point and adding the numbers together. The tax rate for Indiana is 0.034. Thus if you have a $1,000 tax deduction, it reduces your tax liability by $34. The statement that I received had apparently used 0.34 as the tax rate and added this to the amount owed and estimated taxes. The person at the state revenue office said one million people were affected by the error. But I'm not certain if it's that large. At any rate, don't people bother to check their software for mistakes before doing a mass mailing? The last time I received an erroneous 1099 form, I underwent three audits for three years in a row before the IRS finally recognized the error. William E. Mihalo ------------------------------ Date: Wed, 29 Jan 92 09:44:38 GMT From: kstock@gouldfr.encore.fr (Kevin STOCK - MIS (Compta)) Subject: Computer evidence is Hearsay [ Unfortunately I don't have a citable source for this as I no longer live in the UK and so I rely on BBC Radio for this news. ] Local taxes in the UK were changed a couple of years ago from a system known as the "Rates", which was based on property values, to a system called the "Community Charge" (by the Government; most people call it the "Poll Tax") which is based on the number of adults living at an address. Many people consider the new system unfair, and a campaigning movement has been set up to fight against it. One of the principal attacks has been simply refusing to pay the demands. Local councils have therefore taken defaulters to court to request orders for payment. However, the magistrates' courts which should deal with such cases are refusing to hear them, on the grounds that computer output is hearsay and therefore not acceptable as evidence. [ Curiously, in the main criminal courts, computer evidence is acceptable as a result of specific legislation, but this legislation does not apply to the lower courts. The government has promised to end this anomaly. ] Kevin Stock ------------------------------ Date: Tue, 28 Jan 92 18:57:32 PST From: quail@csl.sri.com (Fred Gilham) Subject: The absence of a warranty My understanding is that if a warranty is not provided, the implied warranty gives the buyer quite a bit of protection. Manufacturers supply `limited' warranties for the very reason of saying how far they are willing to go, and for how long, to remedy a problem with their product. An implied warranty, as I understand it, usually says something to the effect that the thing is supposed to perform as advertised or specified in instructions that come with it, basically forever. So, if the manufacturer doesn't supply a warranty, the product had better be good. -Fred Gilham ------------------------------ Date: Wed, 29 Jan 92 13:18:21 CST From: smith@SCTC.COM (Rick Smith) Subject: Re: A Tale of Risk Avoidance [so far ...] (Thorson, RISKS-13.08) Mark Thorson (mmm@cup.portal.com) responded to a posting by "Kai-Mikael J\d\d-Aro" in RISKS DIGEST 13.05: >Tools will always be pushed to their limit, because the limit is actually in >the programmer and it is the fundamental nature of programmers ... >Will Kai-Mikael J\d\d-Aro find himself next year creating state diagrams >with the complexity of a street map of Stockholm ... ? >This might open a whole new range of computer applications ... but there >is no reason to believe these systems will be more reliable than the >smaller systems built before the tool was developed. We have 2 different classes of tools here, very different. As Mark said, the shift to (more) automatic programming simply abstracts away certain technical details in software development. This makes bigger problems easier to tackle, but that's not the essential value of formal methods. I remember Kai-Mikael saying that his workbench provided tests of various state machine properties; this goes far beyond the rudimentary correctness tests a compiler might apply (eg type consistency). Thus, the formal methods _do_ give us more reason to believe in the system's correctness. If the tool in question simply provides a graphic representation for some network (streets, whatever) then it isn't contributing much to increased software reliability. After all, the network's correctness would still depend on whether the coder sees any errors in it when it is created and manually reviewed. Rick Smith. smith@sctc.com Arden Hills, Minnesota ------------------------------ Date: Thu, 30 Jan 92 14:06:58 pst From: pagre@weber.ucsd.edu (Phil Agre) Subject: Serious dangers in the Caltrans AVI spec [URGENT for Californians] I just received the latest revisions to the State of California's proposed spec for automatic vehicle identification (AVI) equipment. This is the box that the state envisages attaching to your car that broadcasts your car's vehicle identification number (VIN) when pinged by a roadsite transmitter. The spec is being developed on the instructions of the state legislature, which is considering automated systems for collecting tolls. The spec has been through a number of revisions. The latest, dated 17 January 1992, is considerably different from the others. It is an irritating document because so little is explained about how toll collection would actually work, and in particular whether it would be necessary for every car on the road to have one of these transmitters. Many of the new revisions are highly technical in nature, but some RISKS-relevant trends are clear. First and most obviously, the proposal no longer contains any language at all about privacy or about encryption. Previous drafts had specified the use of DES, but this is gone. In the former sentence "The initial data records are designed for voluntary implementations of automatic toll collection, where security and anonymity are not overriding concerns.", the phrase "where ... concerns." has now been struck (section 1702.1). Whereas the former document had provided both encrypted and unencrypted versions of the "reader communications protocol" (section 1704.5), the encrypted version is now gone. But this seems to be a symptom of a much deeper change in the purpose of this whole spec. Caltrans (the state Dept of Transportation) has generalized the proposal; the "AVI" equipment is no longer specifically aimed at toll collection but is now intended to support a much wider range of applications. For example, in section 1701 "Definition[s]", the term "Transponders" has been changed from "Electronic devices attached to a vehicle and contain information which can be communicated to the reader." to "Electronic devices that contain information which can be communicated to the reader." New text in section 1702.1, "Objectives", reads "It is further envisioned that more complex data records will be developed to handle anonymous transactions, secure funds transfers, information transfers, and other transactions between the Reader and the Transponder that will be defined as needed." Caltrans will authorize new record types, but "shall pass this responsibility to an appropriate standards setting organization when one is established and recognized." It seems to me that this is a serious situation, for two reasons. The first reason is narrow and clear: the state is about to receive an AVI spec that calls for an unencrypted protocol for toll-collection purposes. This is a serious matter in any case, but just how serious depends on whether it will be compulsory to attach one of these boxes to your car. I cannot understand how automatic toll collection could work unless every car has a transponder. (Maybe there's a box that can "see" a car going by, like the European boxes that issue speeding tickets automatically, and then determine whether any of those cars failed to transmit their VIN's? Even this is a scary enough thought.) The spec certainly reflects no effort to develop a proposal that would not require cars to transmit their VIN's, say through public-key encryption or the anonymous purchase of a transponder that gets decremented like a phone-card. The broader and murkier reason for worry is that the state is envisioning a bureaucratic mechanism for the multiplying applications of automatic tracking mechanisms. The spec is actually broad enough, in principle anyway, to encompass certain kinds of anonymous schemes (as section 1702.1, quoted above, mentions), but the proposal reflects no analysis of the specific technical requirements of anonymous schemes. In effect, all of the hard social issues have been pushed down the line, to the committee that will authorize new uses of these boxes. Once the boxes exist and are in wide use, though, that will be a whole new ball game. We ought to stop now and think. Do we want to set up a bureaucratic mechanism that can turn out automatic tracking schemes on an assembly-line basis, hoping that we can hold the line on privacy and other civil liberties by keeping careful enough track of this process? Or should we take some action -- for example, writing letters to the Pete Wilson, the state legislature, and Caltrans -- to get this entire process to be suspended long enough for a proper public debate? I vote for the latter. The official address for public commentary is as follows ("All written comments received by February 6, 1992, which pertain to the indicated changes will be reviewed and responded to by the Department as part of the compilation of the rule-making file."): Les Kubel, Chief Office of Electrical and Electronics Engineering Department of New Technology, Materials and Research PO Box 19128 Sacramento, California 95819-0128 More importantly, we need to publicize the issue, so that Californians -- and others who live in jurisdictions that might adopt the California proposal as a model -- can make an informed choice. Phil Agre, UCSD ------------------------------ End of RISKS-FORUM Digest 13.09 ************************