Subject: RISKS DIGEST 17.45

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" <[email protected]>
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: [email protected] (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 [email protected]

[Also noted by Philip R. Moyer <[email protected]>. PGN]

------------------------------

Date: Sun, 12 Nov 1995 23:30:22 -0500 (EST)
From: Educom <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 - [email protected] - +44 (0)1223 441 256

------------------------------

Date: Fri, 10 Nov 1995 15:44:54 +0000 (GMT)
From: "Clive D.W. Feather" <[email protected]>
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 [email protected]

------------------------------

Date: Thu, 9 Nov 95 14:05 EST
From: [email protected]
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 <[email protected]>
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 [email protected] [email protected]

[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 <[email protected]>
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. [email protected] 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 <[email protected]>
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: [email protected] (Marianne Mueller)
Subject: regarding Java security

This response was recently posted to comp.lang.java.
Marianne Mueller <[email protected]>, Java Products Group, Sun Microsystems, Inc.

Article 4356 of comp.lang.java:
Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm
>From: [email protected] (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: [email protected]
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 <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

CONTRIBUTIONS: to [email protected], 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, 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: <[email protected]>
To: [email protected]
From: [email protected]
Subject: Compendium of Commercial Fly-By-Wire Problems

>From [email protected] 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: [email protected]
Message-Id: <[email protected]>
To: [email protected]
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