Subject: RISKS DIGEST 17.45 RISKS-LIST: Risks-Forum Digest Monday 13 November 1995 Volume 17 : Issue 45 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: Risks of your moderator being off-line (PGN) Ice Cause of X-31 Crash (Andy Fuller) RSA Wants License for Digital Signature Technology (Educom) Espionage charges dropped against Kevin Poulson (Educom) Demon Internet: A "demon"? (Mike Ellims) Re: Traffic Signaling Problems in Chicago Train/Bus Crash (Clive D.W. Feather) Re: Making Railroad Crossings Safe (Paul Green) Re: Writing solid code (Derek Lee Beatty) Another surname-extraction bug (John Gilliver) Faster computers will never make security safer! (Jacob Palme) Regarding Java security (Marianne Mueller) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 13 Nov 95 08:01:36 PST From: "Peter G. Neumann" Subject: Risks of your moderator being off-line For those of you who wonder about the irregularity of RISKS issues, you must realize that RISKS appears whenever two things happen: (1) there is *good* material, and (2) I have a few spare moments to put out an issue. The past year has been one with me having many diverse activities coupled with the fact that noteworthy risk manifestations continue to occur. For the RISKS record, here are a few cases noted over the past few days. * SF 911. On the morning of 4 Nov 1995, the San Francisco emergency 911 telephone system collapsed for over an hour. It was over 20 minutes before police even knew the system was not working (no error-detection alarm). Another brief outage occurred later. This has been a recurring problem over the past three years. * SF Elections. The San Francisco election process caused a lot of unhappiness. First, thousands of absentee ballot pamphlets were in error (pamphlets are printed on a per-district basis, with differing orders of candidates), which could have resulted in miscast ballots. (Replacements were subsequently mailed out.) Second, on election night, 7 Nov 1995, the computer systems kept malfunctioning, seriously delaying the results. It took quite a while to discover that the new energy-efficient screens were incompatible with the building. When the air conditioning was on, power surges caused the computers to crash. Of course, everything worked fine during the earlier testing (in the absence of air conditioning). * HP Recalls. Hewlett-Packard announced on 8 Nov 1995 that 1900 OmniGo 100 personal organizers were being recalled because of a manufacturing defect. Apparently the organizers could lose data while batteries were being changed. However, the systems are new enough that none of the 500 already purchased could have been in use long enough for the battery to need replacement. Indeed, 1400 were still on dealers' shelves. * Risks of a U.S. Government shutdown. I won't go into this one in detail here, but our out-of-country readers may not realize that "non-essential" U.S. Government services may be shut down tomorrow for an indefinite period. One of the risks implications to you all is that, if that happens, I won't have to fly to Washington this week, which might enable me to take a closer look at a very large backlog of second- and third-order responses in the risks directory. Thanks to all of you who have replied to earlier messages. I'll try to get to them. Peter ------------------------------ Date: Thu, 9 Nov 95 10:27:43 EST From: acfa@eci-esyst.com (Andy Fuller) Subject: Ice Cause of X-31 Crash Quoted from NASA Press Release 95-203: ICE CAUSE OF X-31 CRASH A Mishap Investigation Board studying the cause of the X-31 experimental aircraft accident on January 19, 1995, has concluded that an accumulation of ice in or on the unheated pitot-static system of the aircraft provided false airspeed information to the flight control computers, causing the aircraft to go out of control and crash. It is apparent to me that this crash is the result of a bug in the flight control software and sensor hardware of the X-31 aircraft. The computer was unable to compensate for a loss of the airspeed indicator. The pitot tube is used to measure airspeed. Icing of this probe is a common problem familiar to all pilots. BUT IT IS NOT NECESSARILY FAMILIAR TO SOFTWARE ENGINEERS. A pilot can still fly a conventional aircraft if he loses his airspeed indicator. He checks the airspeed once in a while, and can intuitively tell if it has failed (a reading of zero is pretty impossible while the aircraft is flying). The flight control computer was apparently unable to sense the failure of the airspeed indication, and thus acted as though the aircraft was travelling very slowly. This is the equivalent of driving a car on the highway, but steering as though in a parking lot. The X-31 is a "fly-by-wire" aircraft that is inherently unstable. A computer between the pilot's controls and the flight control surfaces is necessary for the aircraft to fly. The amount of control surface movement is inversely proportional to the airspeed: at high airspeed a small movement is sufficient to keep the aircraft under control, at low airspeeds more movement is necessary to provide the same correcting force. If the aircraft is travelling fast, but the computer senses a low airspeed, it will over-control. The RISKS? A computer's view of a flying environment is very different from the pilot's. The computer relies on a very small number of data sources (it has no eyes, ears, or "seat of the pants"). People who control aircraft, cars, ships, trains, power plants, etc. use lots of information that is unavailable to a computer doing the same task. We need to understand these differences before we use computers to take over the job of a human. Andrew C. Fuller, E-Systems, ECI Div., Box 12248, St. Petersburg, FL 33733 (813)381-2000 x3194 Fax:(813)381-3329 acfa@eci-esyst.com [Also noted by Philip R. Moyer . PGN] ------------------------------ Date: Sun, 12 Nov 1995 23:30:22 -0500 (EST) From: Educom Subject: RSA Wants License for Digital Signature Technology (Edupage, 12 Nov 1995) RSA Data Security claims it owns the dominant patent covering digital signature technology, and wants other companies and government agencies to pay them license fees for using it. The U.S. government is fighting RSA's claim, saying the digital signature algorithm it uses in its digital signature standard is covered by a different patent. If RSA can make its claim stick, the government will owe the encryption company royalties for use of its digital signature standard. (Information Week 13 Nov 95 p20) ------------------------------ Date: Sun, 12 Nov 1995 23:30:22 -0500 (EST) From: Educom Subject: Espionage charges dropped against Kevin Poulson (Edupage, 12 Nov 1995) Federal prosecutors have decided to drop espionage charges against computer programmer Kevin L. Poulson because the military document in his possession was obsolete, he was lawfully entitled to access it, and he had not shared it with anyone else. In exchange for the dropped charges, Mr. Poulson pleaded guilty to unrelated crimes involving illegal access into files of the Pacific Bell Telephone Company. (New York Times 12 Nov 95 p18) ------------------------------ Date: Fri, 10 Nov 95 16:22:36 GMT From: Mike Ellims Subject: Internet Demon: A "demon"? Anger over e-mail jam By Richard Grant [Excerpted from an unspecified British Sunday paper a week or two ago] BRITAIN'S biggest Internet service provider has been attacked by furious customers after 60,000 electronic mail messages went astray or were delayed. Fast growing Demon Internet was valued at 26.7 million (pounds) last week in a City fund-raising exercise backed by venture capitalist Apax Partners. Yet at the same time it was advising some of its clients with the right equipment to by-pass its mail relay service to avoid electronic traffic jams. Angry Demon customers also reported e-mail messages becoming lost or being bounced back to them after trying to send them after trying to send them across the Internet though Demon's electronic gateway. Some said they would quit Demon as they had lost confidence in its service. Many of the delayed messages, which are transmitted from computer to computer across continents for the price of a local phone call, have taken up to five days to arrive. The industry standard is under 60 minutes. ... Demon's Todd said: 'When you double in size every five months things don't degrade gracefully, they suddenly go bang catastrophically'. ... What I find amusing is that the company I work for uses Demon as its service provider. If your reading this then the mail got though! We have recently been getting mail messages that have been bumping around in the guts of the system (Demon Internet)for up to a month. I myself have been getting a lack of response to mail message I've been sending out but I expect that because no-one wants to talk to me :-) Other people have performed experiments where they mail each other and third parties, the third parties received the mail but it was not seen here. This seems like a good example of things not scaling up well. Actually something that happened moments before I was about to send this is that I have just re-received a mail message sent to me 2 weeks ago. The views expressed here and the fact I've copied something from a newspaper source are my own doing and do not reflect the views of my employer or my cat. Also all spelling errors are due to the cat playing on the keyboard. Mike Ellims - Pi Technology - mike@pires.co.uk - +44 (0)1223 441 256 ------------------------------ Date: Fri, 10 Nov 1995 15:44:54 +0000 (GMT) From: "Clive D.W. Feather" Subject: Re: Traffic Signaling Problems in Chicago Train/Bus Crash The UK has a simple and elegant solution to this. There is a standard road marking - a diagonal yellow grid - which means "do not enter this area unless your exit is clear" [there are exceptions to the rule, but they don't apply at rail crossings]. This is then painted on the road at *every* automatic rail crossing. In addition, if there is a significant chance of traffic backing up over the railway, the crossing *must* have gates or barriers completely blocking the road, and is operated by a person who must positively verify that the track is clear before the rail signals can change from Danger. In most modern installations, remote control with CCTV is used. Clive D.W. Feather, Demon Internet Ltd. Gateway House, 322 Regents Park Road, Finchley, London N3 2QQ Tel: +44 181 371 1000 clive@demon.net ------------------------------ Date: Thu, 9 Nov 95 14:05 EST From: Paul_Green@vos.stratus.com Subject: Re: Making Railroad Crossings Safe I've been thinking about the Fox River Grove (Chicago) train/school bus accident. I think we have to be careful how we define the problem we are trying to solve. Are we trying to make grade-level railroad crossings safe? Are we trying to make grade-level railroad crossings that are exceptionally close to a traffic light safe? If this is the problem definition I'm not sure it can be solved in a way that is completely safe and cost-effective. Any signalling mechanism is eventually going to fail, or be ignored, or be rendered unsafe by changes in weather, train weight, speed, or traffic light timings. 99.999...9% safe is not the same as 100% safe. What if we defined the problem instead as trying to eliminate collisions between railroad trains and other objects (automobiles, bicycles, pedestrians, etc.)? This past summer I had the pleasure of traveling from Gare du Nord in Paris to Waterloo Station in London on the new Eurostar train. One of the things that only gradually dawned on me is that there are ZERO grade-level crossings for the entire journey. I'm going from my memory and observations, which, of course, are subject to error, but I don't remember seeing any streets, trails, or footpaths where an auto, bicycle, or pedestrian could have come in contact with the train. Lest anyone observe that Fox River Grove is pretty flat (I grew up near there) and so it would be expensive to elevate or depress either the railroad right-of-way or the highways, I would point out that most of northern France and southeast England is also pretty flat. That didn't stop the builders of those lines from constructing an elevated embankment for the railroad line, and running the streets and highways under it. Can the Eurostar strike an object? Sure. It passes thru stations, railroad yards, and switching areas where trespassers, employees, or passengers can walk or fall onto the tracks. But I think it is safe to say that a Fox River Grove type of accident will not befall the Eurostar any time soon. I find myself heading towards an economic argument. Sometimes (not all the time), improving safety raises the costs. Should the good people of Fox River Grove be told that their children gave their lives so that they could have cheaper train tickets? Or did they think that a simple set of relays, lights, and timers would be 100% reliable, and so they could both be safe and save money? Or should we have told them, "This intersection is 99% safe...you supply the last 1% with your own actions?" I grew up in Elgin, Illinois, which has many active railroad crossings, at grade level, over busy streets. My father taught me to *never* stop the car on the tracks, *no matter* whether there were automatic gates, flashing lights, or "cross bucks". Most people know that trains cannot stop in time. Why is a school bus driver stopping a bus with the last 3 feet hanging over the tracks, and, if that was unknown to her, why is a person driving a bus that she is not totally familiar with? As a guess, we seem to have an inherently dangerous crossing, reliance on an imperfectable signalling system, a driver unfamiliar with the route, a driver unfamiliar with the bus itself, and a train that just happens to come along at the key moment. That's 5 (not necessarily rare) events. It makes me ill just to think about it. PG ------------------------------ Date: Fri, 10 Nov 95 21:09:46 -0500 From: Derek Lee Beatty Subject: Re: Writing solid code (Gong, RISKS 17.44) In RISKS-17.44, Li Gong paraphrases Steve McConnell's (or is it Steve McGuire's?) Microsoft Press book, _Writing_Solid_Code_. He tacitly criticizes the book's purported advice to elide error-checking code from the ship version. Unfortunately, Mr. Gong omitted his own error-checking. His version is not what the book advises at all. The book gives some good advice: distinguish 1) code that checks for system and user errors, from 2) assertions that check for programming errors. It admonishes that (after thorough testing) the latter can be removed from the ship version for better performance, but the former must *never* be removed. This is neither new nor so entertaining to RISKS readers, but it's sound advice. Derek Lee Beatty Austin, Texas beatty@netcom.com beatty@ibmoto.com [Li Gong is unavailable at the moment for further comment. For the record, a better translation of "keine bedeutenden Fehler" given by Klaus Brunnstein as "no essential bugs" in RISKS-17.43 would be "no fundamental bugs". Subtle difference. PGN] ------------------------------ Date: Fri, 03 Nov 1995 12:22:41 +0000 (GMT) From: John Gilliver Subject: Another surname-extraction bug I have a VISA card supplied by the Co-operative bank here (in the UK); I don't have an account with them, just that they offered a free-of-charges-for-life card, so I took it. (At the time many of our VISA card operators were implementing annual fees.) Anyway: one feature which I liked at the time was that I could specify how my name was to appear on the card; I therefore have my degree qualification shown - "MR J P GILLIVER B SC". (I might not do that now, but anyway.) I have now received a letter from them (selling death insurance - I'd have thought they would know I have no dependents, but never mind), from which I see that the way they implemented the name-as-I-like-it in their database is that they have stored my name as "Mr J P Gilliver B SC". (I would have preferred "J. P. Gilliver, B. Sc.,", but the data processing world seems to have a horror of any punctuation, let alone lower case letters.) After my address, the letter starts: "Dear Mr SC". Whether this is just the result of a very dumb algorithm which just takes the last "word" in the address line as the surname, regardless, or whether the data was not entered into fields correctly, is not of course discernible; I just had a smile at it! The risks are not that obvious, though I suppose if some part of the system just extracted what it thought were surnames from the list, or for that matter sorted by what it thought were surnames, incorrect operation would ensue. (As an aside, the genealogy software I use - Brother's Keeper 5.2 - _does_ handle suffixes properly - it recognises many standard ones, such as Jr, II, and so on [can be bypassed if that really is the surname], and I think also recognises anything with a dot in it - so it _is_ possible to correctly handle these sort of things. That's a shareware package, too!) J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW, Essex, CM2 8HN, UK. john.gilliver@gecm.com Tel: +44 1245 473331 x 2133 [See RISKS-15.08 for an amusing collection of previous episodes from various sources, contributed by Mark Brader, and summarized in the table on page 198 of my book (Computer-Related Risks). PGN] ------------------------------ Date: Thu, 9 Nov 1995 17:29:38 +0100 (MET) From: Jacob Palme Subject: Faster computers will never make security safer! (Re: Kamens, 17.40) One often hears a statement, which sounds plausible as in the following quote from Jonathan Kamens in RISKS, 19 October 1995, Volume 17 Issue 40: > An aside: I suspect that one of the reasons why integrity-protection > and/or encryption weren't put into Kerberized NFS and AFS originally > was that such protection significantly increases the CPU load on the > servers and clients using it; however, CPU speeds have increased so > much in the past few years that perhaps now we can spare the cycles to > make our files secure. The problem is that CPU time becomes less costly at the same ratio for the encrypter as for the encryption breaker. Thus, less cost for CPU time may not make encryption more useful. [This is similar to Fred Brooks' Free Component Fallacy. I first ran into the FB-FCF in the 1960s, when someone at a conference suggested that memory was becoming so cheap (yes, 1960s) that ALL memory might as well be associative. Someone referred to Fred, pointing out that if associative memory were still 300 times the cost of ordinary memory, the suggestion did not make sense. But in Jacob's case, the make-or-break ratio need not grow linearly. There are some schemes for which the breaker has almost NO cost (for example, where the operating system is vulnerable to attack), and others where the breaker really has an exponentially growing difficulty. PGN] ------------------------------ Date: Fri, 10 Nov 1995 15:45:00 -0800 From: Marianne.Mueller@eng.sun.com (Marianne Mueller) Subject: regarding Java security This response was recently posted to comp.lang.java. Marianne Mueller , Java Products Group, Sun Microsystems, Inc. Article 4356 of comp.lang.java: Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm >From: mrm@puffin.Eng.Sun.COM (Marianne Mueller) Newsgroups: comp.lang.java Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE Date: 9 Nov 1995 00:50:27 GMT Organization: Sun Microsystems, Inc. Mt. View, Ca. Keywords: alpha3 hotjava security The paper written by the two students at Princeton describes possible attacks on the alpha3 HotJava browser, which have all been fixed in JDK beta. Granted, until this week, the source code for JDK beta wasn't available, so it's understandable that they analyzed the alpha3 source base. We understand people need more information on the security model, and we're taking time right now to document the security story more rigorously. A security FAQ, an updated whitepaper, detailed user documentation and detailed implementor's documentation are all being worked on. The Java security mechanisms include: Java language mechanisms * no pointers * private interfaces, classes and methods * class loader that enforces namespace divisions * runtime byte code verifier that enforces language type rules and name space divisions Browser mechanisms, used by JDK beta appletviewer and by Netscape Navigator 2.0beta * AppletSecurity: extends java.lang.SecurityManager; strict applet checks * AppletClassLoader: extends java.lang.ClassLoader; strict class loading The goal for JDK beta is to enable browsers to run untrusted applets in a trusted environment. The approach is to be conservative at first, and to add functionality when it can be added securely. So, JDK beta applets (and Netscape 2.0beta applets) may not do the following. 1. Files: Access Control Lists are greatly restricted in beta, as compared to the situation in the alpha3 HotJava browser. ACLs are initialized - only once - by the applet security manager, and are not user configurable. For a file not on the access control list, an applet cannot - check for the existence of the file - read the file - write the file - check the file type - check if the file is a directory - check the timestamp when the file was last modified - check the file's size - create a directory - rename the file - list the files in this file (as if it were a directory) Applets cannot - create a FileInputStream - create a RandomAccessFile, either for reading or writing - Open file descriptors 2. Sockets: Applets cannot - Create socket connections other than to its own host - Create a socket factory 3. Loading/linking: Applets cannot - Create class loaders - Access a package in the sun.* hierarchy - Define a new class in the java.* hierarchy - Link dynamic libraries using System.loadLibrary() - Disable or override the AppletSecurityManager 4. Process control: Applets cannot - Define native methods - Fork processes - Manipulate threads or thread groups outside of the applet's thread group - Exit the virtual machine (e.g., the browser or the appletviewer) 5. awt: Applets cannot - Create toplevel windows that don't have a warning banner Applets can use network connections only to connect to the host they originate from, to download files that are part of the applet's implementation. Those files might be java bytecode class files, or they might be input files used by the applet (GIF, JPEG, audio, other data files.) Taking a look at the specific attacks mentioned in the paper - alpha3 HotJava JDK ---------------------- --- 1. socket accept() and applets cannot use listen() aren't protected accept() and listen() adequately, allowing a browser to eavesdrop 2. applets can connect to applets cannot connect the SMTP (mail) port on to the SMTP port on some web server and use the computer the applet that as a covert channel is visiting 3. InetAddress.getByName() applets cannot use is public and does not InetAddress to inquire check the security mode about hosts they are before making DNS request not already allowed to connect to 4. applets can use DNS to applets may not get the create a covert channel internet address of any host 5. Access Control Lists (ACLs) ACLs are greatly restricted for reading and writing in JDK beta. files are not strict enough Reading/writing files is disabled for web browsers, such as Netscape Navigator 2.0. 6. applets can use the System.getenv() is obsolete System.getenv() method and is not part of the JDK to gather information about API the computer that it is running on 7. applets can change the applets cannot read or alter property manager database client properties 8. applets can change the The fields that hold the HTTP and FTP proxy server HTTP and FTP proxy names are private. The values are stored in a property manager database that an applet cannot read or write. It's very difficult, if not impossible, for a web browser to completely prevent denial of service attacks. The JDK applet API doesn't claim to prevent denial of service attacks. A "denial of service" attack is where someone writes an applet whose goal is to consume all available resources on your computer, forcing you to kill the browser you're running. For example, someone could write an applet that creates a million pop-up windows. The windows don't do anything, but creating a million of them might use up all the virtual memory on your computer and you'd have to kill the web browser to reclaim the virtual memory. Before people engage in too much wailing and gnashing of teeth about how applets have been too severely restricted - We want to enable applets to do interesting things, including making socket connections, and reading and writing to the file system. One way to enable that is to used a signed class loader. When a trusted applet is loaded, then the applet could be granted permission to do some of the things they are prevented from doing by default. The goal is to ensure that untrusted applets can't steal or damage information on a computer running a Java-enabled browser. Later, we can allow trusted applets to do things that untrusted applets are not allowed to do. Since an implementation bug in a trusted applet could open a loophole that could be exploited by an untrusted applet, design matters. Marianne Java Products Group http://java.sun.com/people/mrm/ ------------------------------ Date: 6 September 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.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. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] 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. [...] 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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.45 ************************ 12-Nov-95 20:46:10-GMT,1762;000000000001 Received: by csla.csl.sri.com id AA03512 (5.67b/IDA-1.4.3.12 for risko); Sun, 12 Nov 1995 12:46:09 -0800 Date: Sun, 12 Nov 1995 12:46:09 -0800 Message-Id: <199511122046.AA03512@csla.csl.sri.com> To: owner-risks@csl.sri.com From: ladkin@techfak.uni-bielefeld.de Subject: Compendium of Commercial Fly-By-Wire Problems >From ladkin@techfak.uni-bielefeld.de Sun Nov 12 20:45:56 1995 Received: from techfac.TechFak.Uni-Bielefeld.DE by csla.csl.sri.com with SMTP id AA03506 (5.67b/IDA-1.4.3.12 for /homes/server/majordomo/wrapper resend -l risks -h csl.sri.com risks-outgoing); Sun, 12 Nov 1995 12:46:03 -0800 Received: from sisyphos.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA18074; Sun, 12 Nov 1995 21:45:57 +0100 Received: by sisyphos.techfak.uni-bielefeld.de (5.x/tp.29.0890) id AA11496; Sun, 12 Nov 1995 21:45:56 +0100 Date: Sun, 12 Nov 1995 21:45:56 +0100 From: ladkin@techfak.uni-bielefeld.de Message-Id: <9511122045.AA11496@sisyphos.techfak.uni-bielefeld.de> To: risks@csl.sri.com Subject: Compendium of Commercial Fly-By-Wire Problems There has been much recent discussion in RISKS of accidents and incidents involving the commercial fly-by-wire aircraft, the Airbus A319/320/321/330/340 series and the Boeing B777. I've collected the RISKS discussions since September 1993, along with synopses and a little commentary, in a hypertext compendium, entitled `Incidents and Accidents with Fly-by-Wire Commercial Airplanes', accessible through my home page http://www.techfak.uni-bielefeld.de/~ladkin/ I intend that more RISKS and other discussion will appear as time goes by. Comments, additions and corrections welcome. If you have technical material that really should be linked, please let me know. Peter Ladkin