Subject: RISKS DIGEST 15.26 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Saturday 13 November 1993 Volume 15 : Issue 26 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Gripen crash report (Urban Fredriksson) SAS MD-81 crash report, December 1991 (Martyn Thomas) MASS state police confuse car owners with gun carriers (NOT) (Simson Garfinkel) Re: No change in Ada policy (Anonymous, Parnas) Risk-happy drivers foil anti-lock brakes (Mark Brader) _Naissance d'un virus_ soon to be published (Jean-Bernard Condat) Re: pseudospoofing (Andrew Marchant-Shapiro) I'm Me (Nick Szabo) Re: anonymizing service (Karl Lui Barrus) Re: Not so easy to be anonymous (Seth Chazanoff) Re: Stupid language games (Dave Parnas) Re: Networking (Phil Agre) "Friendly Fire" in system design (Steve Taylor) Re: Teachers Beware! (Andy Cunningham) FBI Operation "Root Canal" Documents Revealed (Dave Banisar) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, 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 folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 15, 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. There are also alternative repositories, such as bitftp@pucc.Princeton.EDU . If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . 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: Sat, 13 Nov 1993 07:23:58 GMT From: urf@icl.se (Urban Fredriksson) Subject: Gripen crash report The Swedish Accident Investigation Board's preliminary report on the Gripen crash on Aug 8 is presented in the air force's magazine FlygvapenNytt 3/93. Summarily, the conclusions are: - The only equipment malfunction before the crash was the electronic map which had nothing to do with the crash - The flight control system, the engine and all other systems worked as specified until the aircraft impacted - No external cause is suspected - The pilot was properly trained and equipped - The limits for minimum altitude and maximum angle of attack were exceeded insignificantly and did not have anything to do with the crash - The manufacturer and customer knew that large and rapid stick movements could cause divergent Pilot Induced Oscillations, but considered the likelyhood of it actually happening insignificant, so all pilots weren't informed - The red warning light was too late in telling the pilot that the control system was saturated, for him to do anything about it - The low altitude of 270 m made it impossible for the pilot to try to regain control The crash sequence started with a low speed 360 deg left turn at 280 m. The afterburner was lit, speed 285 km/h, load 2 G, bank angle 65 deg and angle of attack 21 deg. After finishing the turn, the control stick was moved to the right almost to the endpoint and slightly forward. The left wing's rear control surface rapidly went to the bottom position. The aircraft to bank to the right 20 deg past horizontal, angle of attack decreased to less than 10 deg. In order to fast regain a horizontal wing attitude, the pilot rapidly pulled the stick almost all the way to the left and continued to keep it slightly forward. This caused the control surfaces to move with their maximum deflection speed, and as the flight control system then had little or no control surface movement on its own to work with, the stability margin was reduced. At the same time the alert system informed the pilot of this, and he no longer recognized the aircraft's behaviour. The aircraft started to roll to the left and pitch up. In response to this the control stick was moved almost to the right endpoint and some forward. The result was a roll to the right to 35 deg bank and a lowering of the nose to 7 deg below the horizon, whereupon the stick was pulled forcefully back and to the left. At the same time, the artificial stability system tried to raise the nose, which in combination with the pilot's command caused a powerful pitch up. By this time, the control stick was fully forward, but the aircraft was already unflyable. >From exit of the turn until ejection the sequence took 6.2 s. The time from when the pilot didn't recognize the flying characteristics until stall took 2.7 s, but the control system warning wasn't shown until 1.2 s before the stall. The cause of the crash was the misjudgements that PIO was so unlikely and that the warning light would tell about any problems early enough for no mention of this in the pilot's manual was necessary. My own comments: The first crash was caused by the artificial control system having too much authority, sometimes leading to a slight response delay to the pilot's commands, causing PIO during a landing in gusting sidewinds. It has been reported from other sources that the main change made to the control laws a few weeks before the crash was to increase the pilot's authority a tiny bit. Some doubt has also been cast on the statement that the flight control computer worked as specified, as its log only goes a few seconds back and thus only showed data since the pilot left the aircraft. The crash report doesn't go into this in detail, but it is clear they had its error log to work with, in addition to data from the "black box". This report also clears up some things I didn't understand from earlier this year, when it was said that maximum angle of attack was 26 deg, and at 35 deg the rear airbrakes come out and the canard gives a full pitch down command automatically. Obviously fly-by-wire does not have to mean you impose hard limits on the aircraft's performance, in the Gripen case the pilot is trusted not to exceed them. Urban Fredriksson urf@icl.se ------------------------------ Date: Fri, 12 Nov 1993 10:11:58 +0000 (GMT) From: Martyn Thomas Subject: SAS MD-81 crash report, December 1991 According to Flight International, 10 NOVEMBER 1993, "an automatic engine-control function in the McDonnell Douglas MD-81, of which the operating airline was unaware, was a major factor in the Scandinavian Airlines System (SAS) accident near Stockholm, Sweden, in December 1991, says the official report into the accident" In summary, it seems that the airline failed to detect clear ice on the wings before takeoff. The ice broke free and entered the engines damaging the fan stages. This caused the right engine to surge. The pilots retarded the right throttle. The automatic thrust-restoration system ATR caused both throttles to advance without the pilots noticing, making the surging worse in the right engine and starting surging in the left. The surges destroyed the engines. It seems that SAS were unaware of the ATR, which was documented but in a section of the production flight-procedure manual dealing with noise abatement. SAS VP Johan Juhlin is reported as saying "We did not order it. It was hidden in the computer. The only way to disconnect the ATR was to disconnect the whole autothrottle system." McDonnell Douglas say that they made SAS aware of the full capabilities of the MD-80 when it was delivered. The documentation has since been improved, and SAS have changed their procedures and training to emphasise the ATR and correct anti-surging procedures. The ATR was designed to improve safety where an engine fails after take off and noise abatement procedures have caused the engines to be throttled back. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk Fax: +44-225-465205 ------------------------------ Date: Wed, 10 Nov 93 20:19:58 -0500 From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Subject: Massachusetts state police confuse car owners with gun carriers (NOT) I forwarded the RISKS note about people receiving gun permit renewal notes accidentally in Massachusetts to David Lewis, who heads the Registry of Motor Vehicle's information technology group. (His official title is Deputy Registrar.) You may remember the message: >Date: Fri, 5 Nov 93 13:26:43 EST >Subject: Mass. state police confuse car owners with gun carriers >My wife received a letter yesterday from the Massachusetts state police, >informing her that it was time to renew her "License to Carry Firearms". >It included a renewal form that she was to take to her local licensing >authority, the police station in our case. This is what David Lewis had to say about it: "It wasn't actually a tape of vehicle owners. They got stickers confused with people who were supposed to get food stamps. So the people [who were supposed to get] the food stamp books got the gun permits, and the people who were supposed to get gun permits got food stamps. But it wasn't the Registry this time." Just setting the record straight. ------------------------------ Date: Fri, 12 Nov 93 8:57:55 PST From: "ANONYMOUSLY INCLUDED via Peter G. Neumann" Subject: Re: No change in Ada policy (Eachus, RISKS-15.25) [This was submitted by a reliable RISKS contributor who wishes to remain anonymous. PGN] It was noted in RISKS-15.25 that industry needs to be sold on the usage of Ada. As far as I know, industry likes Ada well enough. What they do not like is the EXCLUSIVE use of Ada. Industry has the problem of maintaining millions of lines of working code, code that is rather well debugged, and reasonably well documented, code that was written in what was once a DoD standard - FORTRAN or COBOL, for example. If the government really believes in capitalism, and if the government believes that private industry is in business to make money, then the government should be willing to allow industry to transition to Ada as that makes economic good sense. And not sooner. What such a policy shift might discover is that there are real problems for which Ada is not the best language. There is a very significant difference between a policy of "Ada exclusively" and a policy of "any assembly language you choose." Limiting government sponsored software to a list of government approved languages is a good place to start; investing some r&D money (little "r" and big "D" since most of the "research" is done) in software engineering "tools" for some "legacy languages" (FORTRAN, COBOL, BASIC) would improve the codes written in those older languages, and avoid the impact of a massive mandated change. Indeed, some of these "tools" exist; "DAVE" for FORTRAN, for instance. ------------------------------ Date: Thu, 11 Nov 93 22:05:19 EST From: parnas@triose.eng.mcmaster.ca (Dave Parnas) Subject: Re: No change in Ada policy (Eachus, RISKS-15.25) Was there anything significant in your running the expression of faith in ADA just before the article about Groundhog day? There are still people who seem to believe in the latter too. Dave ------------------------------ Date: Wed, 10 Nov 1993 19:40:28 -0500 From: msb@sq.sq.com (Mark Brader) Subject: Re: Risk-happy drivers foil anti-lock brakes (Bruce, RISKS-15.24) > From the Ottawa Citizen Sunday Edition November 7, 1993 > by Brad Evenson, Citizen consumer writer > ... > "After having practised the emergency stopping manoeuvres with anti- > lock brakes, drivers drove faster, had higher accelerations around a curve > and stopped harder," a summary of the study said. > "If drivers choose to drive faster because they know they have greater > control, and if they choose to follow other vehicles more closely under > slippery road conditions, then the safety benefit from anti-lock brakes > might be reduced or lost completely." Okay, if this study is not misleading, then anti-lock brakes are a device which allows faster driving and closer following in slippery road conditions, without increasing the accident rate. This is bad? Mark Brader, SoftQuad Inc., Toronto utzoo!sq!msb, msb@sq.com ------------------------------ Date: Wed, 10 Nov 93 11:08:44 EST From: cccf@altern.com (cccf) Subject: _Naissance d'un virus_ soon to be published :-) By the general secretary of the Chaos Computer Club France (CCCF), the French translation of "The Little Black Book of Computer Viruses" will soon be published by Addison-Wesley France (fax: +33 1 48 87 97 99). Naassance d'un Virus (dec 1993, 237 pages, circa 98 FF). Jean-Bernard Condat, PO Box 155, 93404 St-Ouen Cedex, France Phone: +33 1 47874083, fax: +33 1 47874919, email: cccf@altern.com ------------------------------ Date: 10 Nov 93 20:07:00 EST From: "MARCHANT-SHAPIRO, ANDREW" Subject: RE: pseudospoofing (RISKS-15.25) On pseudospoofing, there is an interesting SF-based discussion of the potential political consequences, to be found in Orson Scott Card's _Speaker_for_the_Dead_ (if I recall correctly, the two other sections of the [so far] trilogy also contain some elements: _Ender's_Game and _Xenocide_). In these books, Card describes a situation in which the political commons (not unlike internet) is invaded by two extremely bright pseudospoofers, who, seemingly opposed, debate each other in such a way as to manipulate the public into going along with their schemes. There are better writers than Card, and the concept has probably been around for a while, but it's an interesting execution. Andrew Marchant-Shapiro Depts of Sociology and Political Science USmail: Union College, Schenectady NY 12308 AT&T: (518) 388-6225 INTERNET: marchana@gar.union.edu BITNET: marchana@union.bitnet (no fooling!) [AM-S among others reminded me that my rend(er)ing of Tom Lehrer was not as on the records. "Don't write naughty words on walls IF you can't spell." I knew that, but (mis?)remembered a live version from the early 50s... PGN] ------------------------------ Date: Thu, 11 Nov 93 0:28:31 PST From: szabo@netcom.com (Nick Szabo) Subject: I'm Me I'd like to assure the readers of RISKS that I am in fact a unique person, distinct from the other names L. Detweiler listed. Of the people on his list I know from personal contact, all are distinct people in Real Life(tm). Well before his post to RISKS, L. Detweiler was provided means of personally verifying that many of the names he listed are distinct True Names (eg phone numbers he can call), but it doesn't seem to help. Nick Szabo szabo@netcom.com ------------------------------ Date: Fri, 12 Nov 93 09:42:55 CST From: Karl Lui Barrus Subject: Re: anonymizing service To everybody who is worried about the service anon.penet.fi: If you mail to an address such as an####@anon.penet.fi, you will be assigned an id. If you mail to na####@anon.penet.fi, your message will be passed along and you will NOT be assigned an id. an == anonymous na == not anonymous It's that simple. I mention this because it seems every other week somebody is discovering the "risks" of this service while how to avoid the problem altogether is never discussed. ------------------------------ Date: 11 Nov 1993 17:17:01 GMT From: seth@inst-sun1.jpl.nasa.gov (Seth Chazanoff) Subject: Re: Not so easy to be anonymous (Ullman, RISKS-15.25) In RISKS-15.25, Robert L Ullmann points out that one may be able to be identified when using an anonymous mailer through stylistic analysis techniques. ( This is what radio intercept operators in WWII called the senders fist. ), There is a section that I was told about on the Comparative Literature GRE that starts _None of the following paragraphs were written by any of the authors listed, but the correct answer is the name of the author whose style the paragraph was written in._ The problem with this technique is that many people may use similar enough techniques that attempting to assign a message to an individual may be very difficult. Recently JPL opened an anonymous newsgroup for internal gripes. My boss's boss came to me and said that he had noticed that I was active in that group. ( It is good to know that management is reading the group. :-)) I asked him how he came to that conclusion and he told me that he recognized my style of writing. The only problem was I had not heard of that newsgroup till he told me about it. Seth ------------------------------ Date: Thu, 11 Nov 93 22:00:44 EST From: parnas@triose.eng.mcmaster.ca (Dave Parnas) Subject: Re: Stupid language games (Schroeppel, RISKS-15.24) Neither Jones, nor Mellor, nor Parnas (see RISKS-15.22) was arguing in favour of exhaustive testing in the quote picked upon by Schroeppel. Jones was trying to explain the complexity of software to non-programmers. He did this by trying to give the listeners a "feel" for the number of possible cases that would have to be considered. I pointed out that even though the complexity, as described, seemed daunting, it was understated. There is neither theoretical, nor practical basis for focusing on control state and neglecting data state. The thought attributed to Daimler by Schroeppel is irrelevant because carburetors don't have to be tested on all mixtures, just the ones that they will encounter, and that can be controlled. Moreover, continuity, and known upperbounds on the derivatives of the functions describing carburetors, limit the amount of testing that need be done. It's this lack of continuity that makes testing of software so difficult. ------------------------------ Date: Wed, 10 Nov 1993 16:48:21 -0800 From: Phil Agre Subject: Re: Networking Richard Schroeppel has taken exception to my essay on "Networking on the Network" in Risks 15.12, stating "I do not choose my friends based on their potential usefulness to my professional advancement. Even a little bit." As my essay repeatedly made clear, I am not advising anybody on the choice of their friends, only on the development of their professional relationships. These are different concepts. Heretofore, practical knowledge about how the world works has been restricted to elites, who are so embarrassed about this knowledge that they only pass it along in private, leaving others exposed to the Risks of untutored navigation in the professional world, permanently wondering why they can't seem to get anything done. If we write down the world's unwritten rules and circulate them on the Internet, maybe we can level the playing field a bit -- or even change the rules. Phil Agre, UCSD ------------------------------ Date: Fri, 12 Nov 93 18:14:15 +1100 From: Steve Taylor Subject: "Friendly Fire" in system design I've just remembered an old episode of the "Space Patrol" TV series in which the good guys spaceship was fired on by Earth spaceport defenses, which had been set to fire on any metals not originating on Earth. Unfortunately in a classic design glitch, the system designers had forgotten that many of the Space Patrol's ships had been built on Pluto, and were made of - ahem... Plutonium. The RISKS are obvious. Whatever they are. Steve Taylor smt@xedoc.com.au Xedoc Software Development ------------------------------ Date: Fri, 12 Nov 93 08:53:24 +0000 From: "Your friendly UNIX guru" Subject: Re: Teachers Beware! [Spera, RISKS-15.23] > First there was writing in the palm of the hand, then the crib sheet (or back > of the tie or sole of the shoe or etc.), next came the programmable > calculator, now coming to a store near you, the Newton generation. There was an alleged incident at Reading University (England) where a student used a laptop computer in an exam. The exam in question was "open book" but the rules did not forbid it's use in any exam. After this, the rules were tightened up and each calculator had to be "certified", as either - "non programmable" or "programmable and memory cleared". Certificates had to be displayed on desks, and invigilators could request that the memory be cleared at the start of the exam. Any device with alphanumeric memory was prohibited. Any calculator (even a simple 4 function credit card calculator) could be confiscated until the end of the exam unless a certificate was displayed on the desk. I can't vouch for the accuracy of the incident, but I was very aware of the rules being tightened up to the point that I had to go and buy a simple scientific calculator to use instead of my HP-28S. And switching from RPN to grungy-old-horrible-notation was a total pain! Highlighting the flaws in a set of rules isn't always a good idea - it usually gets the rules tightened too far. AndyC the WB (aka Andy Cunningham) Logica Industry / Ford Motor Company Phone: +44 277 253765 Fax: +44 277 253582 Net:andyc@cappsdv2.fob.ford.com ------------------------------ Date: Sat, 13 Nov 1993 08:40:25 -0500 From: Dave Banisar Subject: FBI Operation "Root Canal" Documents Revealed (from the CPSR Alert 2.05) In response to a CPSR Freedom of Information Act lawsuit, the FBI this week released 185 pages of documents concerning the Bureau's Digital Telephony Initiative, code-named Operation "Root Canal." The newly disclosed material raises serious doubts as to the accuracy of the FBI's claim that advances in telecommunications technology have hampered law enforcement efforts to execute court-authorized wiretaps. The FBI documents reveal that the Bureau initiated a well-orchestrated public relations campaign in support of "proposed legislation to compel telecommunications industry cooperation in assuring our digital telephony intercept requirements are met." A May 26, 1992, memorandum from the Director of the FBI to the Attorney General lays out a "strategy ... for gaining support for the bill once it reaches Congress," including the following: "Each FBI Special Agent in Charge's contacting key law enforcement and prosecutorial officials in his/her territory to stress the urgency of Congress's being sensitized to this critical issue; Field Office media representatives educating their contacts by explaining and documenting, in both local and national dimensions, the crisis facing law enforcement and the need for legislation; and Gaining the support of the professional associations representing law enforcement and prosecutors." However, despite efforts to obtain documentation from the field in support of Bureau claims of a "crisis facing law enforcement," the response from FBI Field Offices was that they experienced *no* difficulty in conducting electronic surveillance. For example, a December 3, 1992, memorandum from Newark reported the following: The Newark office of the Drug Enforcement Administration "advised that as of this date, the DEA has not had any technical problems with advanced telephone technology." The New Jersey Attorney General's Office "has not experienced any problems with the telephone company since the last contact." An agent from the Newark office of the Internal Revenue Service "advised that since the last time he was contacted, his unit has not had any problems with advanced telephony matters." An official of the New Jersey State Police "advised that as of this date he has had no problems with the present technology hindering his investigations." Likewise, a memorandum from the Philadelphia Field Office reported that the local offices of the IRS, Customs Service and the Secret Service were contacted and "experienced no difficulties with new technologies." Indeed, the newly-released documents contain no reports of *any* technical problems in the field. The documents also reveal the FBI's critical role in the development of the Digital Signature Standard (DSS), a cryptographic means of authenticating electronic communications that the National Institute of Standards and Technology was expected to develop. The DSS was proposed in August 1991 by the National Institute of Standards and Technology. NIST later acknowledged that the National Security Agency developed the standard. The newly disclosed documents appear to confirm speculation that the FBI and the NSA worked to undermine the legal authority of the NIST to develop standards for the nation's communications infrastructure. CPSR intends to pursue further FOIA litigation to establish the extent of the FBI involvement in the development of the DSS and also to obtain a "cost-benefit" study discussed in one of the FBI Director's memos and other documents the Bureau continues to withhold. ---- To subscribe to the Alert, send the message: "subscribe cpsr " (without quotes or brackets) to listserv@gwuvm.gwu.edu. Back issues of the Alert are available at the CPSR Internet Library FTP/WAIS/Gopher cpsr.org /cpsr/alert Computer Professionals for Social Responsibility is a national, non-partisan, public-interest organization dedicated to understanding and directing the impact of computers on society. Founded in 1981, CPSR has 2000 members from all over the world and 22 chapters across the country. Our National Advisory Board includes a Nobel laureate and three winners of the Turing Award, the highest honor in computer science. Membership is open to everyone. For more information, please contact: cpsr@cpsr.org or visit the CPSR discussion conferences on The Well (well.sf.ca.us) or Mindvox (phantom.com). ------------------------------ End of RISKS-FORUM Digest 15.26 ************************