[risks] Risks Digest 22.19

From: RISKS List Owner (riskoat_private)
Date: Mon Aug 19 2002 - 15:54:58 PDT

  • Next message: RISKS List Owner: "[risks] Risks Digest 22.20"

    RISKS-LIST: Risks-Forum Digest  Monday 19 August 2002  Volume 22 : Issue 19
    
       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, caveats, etc. *****
    This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.19.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents: [Back from long trip.  PGN]
    Name filtering affects police officer (Fuzzy Gorilla)
    Massive ATM fraud after security problems due to Sept 11 (Tom Van Vleck)
    A universal Turin machine? (PGN)
    Win32 API utterly and irredeemably broken (Monty Solomon)
    Microsoft EULA asks for root rights -- again (Monty Solomon)
    FTC Stamps Microsoft's Passport (Monty Solomon)
    Keystone SpamKops (Edward W. Felten)
    Re: Listen to TCAS, not the controller (Peter B. Ladkin)
    An automation-related AIRPROX incident (Peter B. Ladkin)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Thu, 15 Aug 2002 18:41:31 -0400
    From: "Fuzzy Gorilla" <fuzzygorillaat_private>
    Subject: Name filtering affects police officer
    
    It is not clear that we will ever solve the problem of computerized
    filtering based on "lewd" names when even humans can't get it right.
    
    The badge of El Paso police officer Christine Lynn O'Kane (and her e-mail
    address) identified her as C. O'KANE (which unfortunately looks like
    'cocaine').  After leaving the force for personal reasons and later
    reapplying, she was denied reinstatement on the grounds that her name was
    inappropriate -- despite her good service record that included an explicit
    recommendation her work file supporting her reinstatement.  Although her
    appeal to the Civil Service Commission resulted in her being rehired, she 
    has now reverted to her maiden name (Whitaker).
      [Source: Cop In Trouble Over Name, AP, 12 Aug 2002; PGN-ed]
    
    http://dailynews.yahoo.com/news?u=/ap/20020812/ap_on_fe_st/c__o_kane_1
    
    ------------------------------
    
    Date: Mon, 5 Aug 2002 20:18:08 -0400
    From: Tom Van Vleck <thvvat_private>
    Subject: Massive ATM fraud after security problems due to Sept 11
    
    http://fr.news.yahoo.com/020805/5/2pe9c.html
      [This is in French, but not yet reported in English.  
      Translation with the help of Babelfish.  thvv]
    
    4000 people are suspected of taking a total of $15 million in ATM overdrafts
    from the NY Municipal Credit Union, whose computer system was damaged by
    9/11 attacks and the phone and electric outages that followed.  The CU chose
    to allow withdrawals of up to $500/day without checking.  Word got around.
    One person withdrew over $18,000 in 54 transactions.
    
    ------------------------------
    
    Date: Mon, 19 Aug 2002 15:06:53 PDT
    From: "Peter G. Neumann" <neumannat_private>
    Subject: A universal Turin machine?
    
    Seeing the number 4000 in the foregoing message from Tom Van Vleck reminded
    me of an article I read 12 days ago in *The Herald Tribune* Italian edition
    supplemental highlights from *Corriere della Sera* in English, 7 Aug 2002:
    Police probe credit card scam.  Turin police obtained a cigarette-pack-sized
    machine that been used by an up-scale restaurant to make about 4000
    perfect-copy credit cards from cards used by customers, including mag
    stripes.  The Clone Arranger Strikes Again.  (The Shrewd of Turin?)
    
    ------------------------------
    
    Date: Mon, 19 Aug 2002 12:44:53 -0400
    From: "monty solomon" <montyat_private>
    Subject: Win32 API utterly and irredeemably broken
    
    Thomas C Greene in Washington, 7 Aug 2002 
    
    Windows might possibly be the most insecure piece of viral code ever to
    infect a computer, according to Chris Paget who's found a fascinating hole
    in the Win32 Messaging System which he believes is irreparable, and which
    he posted to the BugTraq security mailing list.
    
    The research leading to this discovery was inspired by MS Veep Jim Allchin,
    who testified to the effect that if flaws in the Windows Messaging System
    were sufficiently understood, national security would be deeply compromised,
    CRUISE missiles would be launched remotely, and /bin/laden would most likely
    find some novel way of raping your daughter with his big bad mou Paget has
    brought at least some of Allchin's fears to fruition ...
    
      http://www.theregus.com/content/55/25883.html
    
    ------------------------------
    
    Date: Sun, 4 Aug 2002 23:03:51 -0400
    From: Monty Solomon <montyat_private>
    Subject: Microsoft EULA asks for root rights -- again
    
    Andrew Orlowski in *The Register*, London, 2 Aug 2002
    
    An addition to Microsoft's End User Licensing Agreement has alarmed
    *Register* readers.  Windows XP Service Pack 1 and Windows 2000 Service Pack
    3 contain a new condition which asks you to allow Windows to go and install
    future updates.  "You acknowledge and agree that Microsoft may automatically
    check the version of the OS Product and/or its components that you are
    utilizing and may provide upgrades or fixes to the OS Product that will be
    automatically downloaded to your computer," is the new bit you'll be
    interested in.  ...  http://www.theregister.co.uk/content/4/26517.html
    
    ------------------------------
    
    Date: Fri, 9 Aug 2002 18:05:42 -0400
    From: Monty Solomon <montyat_private>
    Subject: FTC Stamps Microsoft's Passport
    
    FTC Stamps Microsoft's Passport
    
    Yesterday Microsoft settled a complaint by the Federal Trade Commission that
    its Passport user-ID service had violated its own privacy policy and was
    insufficiently secure. Almost every outlet featured the story prominently,
    and the Wall Street Journal e-mailed one of its infrequent Technology Alerts
    yesterday after the FTC/Microsoft conference call.  ...
      http://newsletter.mediaunspun.com/index000018770.cfm#a86817
    
    ------------------------------
    
    Date: Fri, 16 Aug 2002 09:45:06 -0400
    From: "Edward W. Felten" <feltenat_private>
    Subject: Keystone SpamKops
    
    I recently set up a web site at www.freedom-to-tinker.com.  It's a weblog
    containing my commentary on various issues.  Earlier this week, my ISP shut
    off the site, because the site had appeared on a list of "spammers"
    published by an outfit called SpamCop.
    
    Apparently, this happened because one person, whose identity I was not
    allowed to learn, had sent SpamCop an accusation saying that he had received
    an unwanted e-mail message, which I was not allowed to see, that did not come
    from me but that did mention my web site.  On that "evidence" SpamCop
    declared me guilty of spamming and decreed that my site should be shut down.
    Never mind that I had never sent a single e-mail message from the site.
    Never mind that my site was not selling anything.
    
    Naturally, I was not allowed to see the accusation, or to learn who had
    submitted it, or to rebut it, or even to communicate with an actual human
    being at SpamCop.  You see, they're not interested in listening to
    complaints from spammers.
    
    With help from my ISP, I eventually learned that the offending message was
    sent on a legitimate mailing list, and that the person who had complained
    was indeed subscribed to that list, and had erroneously reported the message
    as unsolicited.  Ironically, the offending message was sent by someone who
    liked my site and wanted to recommend it to others.  Everybody involved (me,
    my ISP, the person who filed the complaint, and the author of the message)
    agreed that the report was an error, and we all told this to SpamCop.
    Naturally, SpamCop failed to respond and continued to block the site.
    
    Why did my ISP shut me down?  According to the ISP, SpamCop's policy is to
    put all of the ISP's accounts on the block list if the ISP does not shut
    down the accused party's site.
    
    Note the similarities to the worst type of Stalinist "justice" system:
    conviction is based on a single anonymous complaint; conviction is based not
    on anything the accused did but on favorable comments about him by the
    "wrong" people; the evidence is withheld from the accused; there is no
    procedure for challenging erroneous or malicious accusations; and others are
    punished based on mere proximity to the accused (leading to shunning of the
    accused, even if he is clearly innocent).
    
    Note also that the "evidence" against me consisted only of a single unsigned
    e-mail message which would have been trivial for anyone to forge.  Thus
    SpamCop provides an easy denial of service attack against a web site.
    
    The only bright spot in this picture is that our real justice system allows
    lawsuits to be filed against guys like SpamCop for libel and/or defamation.
    My guess is that eventually somebody will do that and put SpamCop out of
    business.
    
      [By the way, there is more discussion of this incident on my blog site at
         http://www.freedom-to-tinker.com
      EWF]
    
    ------------------------------
    
    Date: Thu, 15 Aug 2002 11:38:00 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: Re: Listen to TCAS, not the controller (Morell, Risks 22.18)
    
    In RISKS-22.13, Bob Morell discusses the midair collision on 1 Jul 2002 over
    Southern Germany, in which a Bakshirian Airlines Tupolov 154, operating as
    BTC 2937, collided with a DHL Boeing 757-200, operating as DHX 611, although
    both were using ACAS II-compliant collision-avoidance systems, namely
    Honeywell TCAS II Version 7 systems [1] (TCAS is "kit"; ACAS II is the
    international designation for a requirement which TCAS II Version 7
    fulfills).
    
    Morell is right in saying that more comment is due on this accident.
    However, his comment is misleading, particularly because of its superficial
    plausibility.  Most misleading of all is the title suggestion that the crew
    of BTC 2397 (BTC CRW) should have listened to TCAS rather than the
    controller.  To the contrary, their cognitive model may well have been such
    that prioritising the controller's advisory over the Resolution Advisory
    (RA) from TCAS would have been the most rational decision to make, as I note
    below.
    
    An extended version of my comment is available as "ACAS and the South German
    Midair", RVS-Occ-02-02, on http://www.rvs.uni-bielefeld.de
    
    First, a brief explanation of how TCAS II avionics operates [2,3]. TCAS II
    broadcasts signals on the radar-interrogation frequency, and receives
    responses from other aircraft's transponders. A Mode C transponder is a
    device which responds to radar beams of a certain frequency with information
    on the aircraft's identity and its "pressure altitude" - the altitude at
    which it would be flying in an "international standard atmosphere" at the
    measured outside air pressure. Additionally, the Mode S transponder used
    with TCAS II may receive and transmit messages, a facility used essentially
    in TCAS II.
    
    TCAS II gives two types of advisories, Traffic Advisories (TAs) and
    Resolution Advisories (RAs). It displays the approximate relative position
    and separation of conflicting traffic visually on a display screen, and
    announces the advisory via simulated voice. TAs alert a crew to the presence
    of a potentially conflicting aircraft (determined by presence within a
    specified volume of surrounding airspace), and attempts to predict
    time-to-go to collision (TTG). When TTG reaches a certain threshold, a TA is
    generated; when TTG reaches a lower threshold, an RA is generated upon
    negotiation with the other aircraft's TCAS II, if it is so equipped. A TA is
    just a warning; pilots are not expected to manoeuvre in response to a TA. An
    RA is an advisory to climb, or to descend. An algorithmic negotiation
    between the TCAS II avionics on both aircraft ensures that one aircraft of a
    TCAS-II-equipped conflicting pair receives a climb RA and the other a
    descend RA.
    
    Morell speculates whether BTC CRW made a "mistake" or not, and suggests that
    the descent decision and action "if the reports on the Russian training are
    correct, was not, technically speaking, a mistake on the pilot's part...."
    
    It is not clear to me what Morell's concept of a "mistake" is. First, any
    pro forma operational suitability of BTC CRW's actions is determined by
    German aviation law and associated approved procedures in German airspace,
    not by any "Russian training". Second, in private correspondence, Morell
    suggested that the RTC CRW action was "obviously" a mistake, since the two
    aircraft collided. I don't know what it would mean for the action to be a
    mistake, but at the same time not to be "technically speaking" a mistake.
    Besides, the criterion offered is clearly insufficient: DHX CRW action led
    just as inexorably to the collision, but it would be anachronistic to refer
    to this action as a "mistake".
    
    I feel such speculation about possible pilot error without a careful
    analysis of the interactions in the cockpits, as contained on the cockpit
    voice recorder (CVR), is unwarranted. The CVR often provides the only means
    of assessing the quality of CRW decision making, and in this menage a trois
    equipes in which four of the five participants are dead, I think such
    analysis is essential.
    
    Morell says, astoundingly, that "TCAS is a highly tested system with a
    flawless record", apparently not counting this midair as a failure. On the
    contrary, the TCAS avionics were a causal factor in this accident: had
    neither aircraft been so equipped, the accident would not have happened (DHX
    CRW would have maintained altitude as cleared; BTC CRW would have descended
    as cleared and as they did; the aircraft would have missed each other by
    600ft).
    
    The TCAS system, like most complex systems which depend essentially on human
    action, does not have a "flawless record", even previous to this
    accident. There are significant operational issues with previous TCAS
    versions (such as 6.02 and 6.04a), which remain (while reduced) with TCAS II
    Version 7. Eurocontrol training materials say that TCAS "... cannot
    eliminate all risks of collision. Additionally, as in any predictive system,
    it might itself induce a risk of collision" [4, p17].  The Eurocontrol ACAS
    Operational Evaluation indicates a substantial history of false positives
    ("unnecessary RAs") [5]; the latest version, Version 7, shows a "40%
    reduction in unnecessary RAs" [6].
    
    False positive RAs are not merely a nuisance; in dense traffic areas, which
    is where RAs are most likely to be generated, manoeuvres in accordance with
    RAs disrupt ATC planning and generate immediately an unanticipated higher
    workload for a controller, which can be a safety risk when a controller is
    operating near the limits of higher capacities. There has been a significant
    rate of "nuisance" advisories, and one can anticipate pilots' reactions to
    the system crying "wolf" too often.  Lincoln Labs apparently reported that
    that over 50% of RAs occurring in U.S: airspace are ignored [5, Section 5.3,
    p19].
    
    Such operational issues arise with, for example, "stacks" of aircraft
    queuing for approach to an airport in instrument meteorological conditions,
    and in the European Reduced Vertical Separation Minimum airspace, introduced
    this year between Flight Levels 290 and 410 (between 29,000 ft and 41,000 ft
    in an "international standard atmosphere").  In both of these cases,
    aircraft are operating as cleared with only one thousand feet of nominal
    vertical separation. Altitude measuring equipment is allowed to be up to +/-
    64 ft deviant in RVSM airspace, and altitude reporting equipment reports in
    either 25ft or 100ft increments. Two TCAS-equipped aircraft operating as
    cleared may well "see" each other separated by less than 850 ft, sufficient
    to generate a "nuisance" TA. Add effects of turbulence, or of a
    non-perfectly executed levelling off manoeuvre at a new cleared altitude
    ("bump up" or "bump down") and a "nuisance" RA can easily be generated [7].
    
    One should not identify an ACAS II-compliant system with the TCAS II Version
    7 avionics alone.  The avionics influence an aircraft's flight path only
    through the crew's decisions and actions.  The procedures which crew are
    advised to follow, and their understanding of the situation (their
    "cognitive model") are essential components of the ACAS system.  Not only
    that, but it is possible for misleading controller advisories to alter the
    cognitive model of one or more of the crew involved, indicating that the
    controller's role must be considered in any safety analysis of ACAS
    operation.
    
    Facts already available concerning the July 1 midair collision highlight
    certain difficulties with ACAS operation, namely that ACAS does not handle
    some three-aircraft conflicts well. Consider the situation engendered by the
    circumstances on July 1.
    
    We may assume that BTC CRW and DHX CRW knew that there were only two
    ACAS-equipped aircraft involved in the conflict. This information would be
    displayed; BTC CRW would see DHX at their 10 o'clock position (60 degrees
    left of straight ahead). However, at 23:25:03, 7 seconds after the first RA,
    BTC CRW were informed by air traffic control that there was conflicting
    traffic at their 2 o'clock position (60 degrees right of straight ahead)
    [1].  This aircraft was not on their display - indeed was not there; the
    controller's advisory was a cognitive mistake. BTC CRW is now faced with the
    following situation: there is a conflict with traffic painted by TCAS at
    their 10 o'clock position and also with non-painted traffic at their 2
    o'clock position. Their cognitive model poses a three-aircraft conflict
    situation. (One of these aircraft is a "ghost" but they do not know it.)
    
    The importance of this scenario does not depend on what did or did not
    happen in the accident on July 1. We may find out from CVR and other
    evidence, or we may not, what BTC CRW's cognitive model actually was. The
    importance lies in that it is an ACAS scenario whose components have
    actually occurred, and therefore it must be analysed as part of a safety
    assessment of ACAS.
     
    Let me use "Aircraft A" for the DHX-similar aircraft, "Aircraft B" for the
    BTC-similar aircraft, and "Aircraft C" for the aircraft at Aircraft B's 2
    o'clock position. Since TCAS is not painting Aircraft C, Aircraft B CRW can
    suppose that Aircraft C will not be involved in any RAs. It is hard to say
    what cognitive model Aircraft A CRW have, since they might not have heard or
    assimilated the controller's mistaken advisory to Aircraft B CRW. So I shall
    not consider their cognitive model. Aircraft B CRW do not know whether the
    controller is in contact with Aircraft C or not, although it might be
    reasonable to suppose so. ATC has issued a descent instruction to Aircraft B
    to take Aircraft B out of conflict with Aircraft C. Further, Aircraft B have
    received an RA to climb. They can conclude that the RA was negotiated with
    Aircraft A, since their TCAS display is painting Aircraft A as the
    "intruder", and that Aircraft A has received a descent RA.
    
    There is a clear strategy for Aircraft B CRW to follow when both
    controller's advisory and RA agree. They follow it. They then come to be in
    further trouble only if Aircraft A manoeuvres in the reverse sense to their
    presumed RA.  However, a dilemma is directly posed if the controller's
    advisory and the RA do not agree in sense. One rational strategy could be
    termed "better the devil you know".  Aircraft B CRW can follow the
    controller's advisory to avoid Aircraft C, and attempt to use the TCAS
    display information to acquire Aircraft A visually and avoid it. They could
    also attempt to reduce speed to give greater TTG until conflict with
    Aircraft A.
    
    Risky as this is, I see no more rational strategy available to Aircraft B
    CRW.  Not even this meagre strategy is available if they are in Instrument
    Meteorological Conditions.
    
    The manoeuvres of BTC CRW on July 1 are consistent with this strategy, which
    violates the oft-repeated advice to pilots not to manoeuvre contrary to an
    RA. I suggest on the basis of this scenario that this advice is not
    universally applicable. Indeed, the benefit of ACAS in this situation to
    Aircraft B is in knowing roughly where Aircraft A is - a benefit provided
    equally well by TCAS I, which does not generate RAs at all.
    
    I believe this scenario shows that it is illusory to imagine that better or
    more uniform training will resolve ACAS operability problems.  Before
    solutions can be trained, we first need a solution, and I doubt there is one
    for this scenario based on ACAS technology.  I refer to my extended note for
    other cases, involving three ACAS-II equipped aircraft, for which it is also
    unclear to me that a solution exists.
    
    Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
    
    References
    
    [1] Bundesstelle fuer Flugunfalluntersuchung, Presseinformation,
    Zusamme nstoss am Bodensee (available also in English), reviewed July
    28th, 2002, http://www.bfu-web.de/aktuinfo-d28.htm
    
    [2] Mitre Corporation, Center for Advanced Aviation System Development
    (CAASD), Traffic Alert and Collision Avoidance System,
    http://www.caasd.org/proj/tcas/
    
    [3] Honeywell, Inc. Advanced Collision Avoidance Systems, at
    http://www.honeywelltcas.com
    
    [4] Eurocontrol, ACAS II Training Manual, Version 2, available from
    http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials
    -> Training Manual Version 2, May 2000.
    
    [5] Eurocontrol Experimental Center, European ACAS Operational
    Evaluation, Final Report, Eurocontrol Experimental Centar Report
    No. 316, July 1997, available at
    http://www.eurocontrol.fr -> Documents -> (Search) Final Report 316
    -> Reports for the Year 1997 -> 316.
    
    [6] Mitre Corporation, Center for Advanced Aviation System Development
    (CAASD), Traffic Alert and Collision Avoidance System,
    http://www.caasd.org/proj/tcas/
    
    [7] Eurocontrol, ACAS II Operations in the European RVSM Environment,
    Project ACTOR, available from
    http://www.eurocontrol.int -> Projects -> ACAS -> Training Materials
    -> Brochure f11, 2 August 2001.
    
    ------------------------------
    
    Date: Thu, 15 Aug 2002 16:07:31 +0200
    From: "Peter B. Ladkin" <ladkinat_private-bielefeld.de>
    Subject: An automation-related AIRPROX incident
    
    On 2 Oct 2000, there was a loss of separation (an AIRPROX incident in
    jargon) on the North Atlantic Track E from Europe to North America between
    an Airbus A330 and an Airbus A340 aircraft. The aircraft were operating
    under Reduced Vertical Separation Minima (RVSM), in which high-altitude
    aircraft may use a nominal vertical separation of 1,000 ft from each other
    for their operations instead of 2,000 ft, which has been standard. RVSM had
    been introduced for trials on the North Atlantic track system, and was
    introduced in European airspace in January 2002. RVSM depends essentially on
    participating aircraft using Airborne Collision Avoidance System (ACAS)
    equipment. Both incident aircraft were using Traffic alert and Collision
    Avoidance System (TCAS) Version 6.04 avionics.
    
    I shall describe the incident briefly, omitting some salient observations
    made in the report. Since the report is about eleven A4 pages of prose and
    data, I recommend reading it in full [1].
    
    The A340 was cleared at Flight Level (FL) 360 (the altitude at which the air
    pressure is the same as that at 36,000 ft in an International Standard
    Atmosphere), and the A330 at FL 370. The A330 was roughly abeam and slowly
    overtaking the A340, when the aircraft encountered clear air turbulence,
    described by the A340 captain as severe.
    
    The A340 entered a "zoom climb", and went up to FL384, some 2,400 ft above
    its assigned FL and 1,400 ft above the FL assigned to the A330.  Both
    aircraft had been receiving Traffic Advisories (TAs) on each other for some
    minutes before the incident, and during the incident received TCAS
    Resolution Advisories (RAs); the A340 was advised to descend and the A330 to
    climb. The A330 captain said that the A340 passed through his FL, some
    200-300ft to his left, before he had time to react to the RA. The maximum
    rate of climb of the A340 during the incident was recorded to be some 6,000
    ft/min.
    
    At the time the first RAs were issued, the aircraft were likely separated by
    some 800 ft, and the RAs were "nuisance" RAs due to the turbulence, as
    described in [2]. The A340 had not begun its zoom climb. About ten seconds
    later, though, the A340s flight control system captured "alpha prot", and
    the A340 commenced its climb. "Alpha prot" is a value of a flight parameter
    known as the "phase-advanced angle of attack" which triggered a change from
    the "normal" flight control law in the Airbus fly-by-wire control system to
    the "angle of attack protection" law, or AoA law. When both control
    sidesticks remain neutral, AoA law attempts to maintain the angle of attack
    (inclination of the aircraft's wing to the air it is flying through; the
    major parameter used in controlling lift in flight) at the value it has at
    the point of reversion. One may presume that the turbulence encountered had
    momentarily increased the angle of attack to a high value at the time that
    alpha prot was captured.
    
    Right before alpha prot was captured, the A340's airspeed briefly rose above
    its "limiting value" of 0.86 Mach (0.86 times the speed of sound at that
    altitude), due to the turbulence encounter. This triggered a Master Warning,
    and also disconnected the autopilot. The Fault Warning Computer prioritises
    warnings, and the autopilot disconnect warning was suppressed for about six
    seconds in favor of the Master Warning. It is surmised that the crew may not
    have registered the TCAS RA because of the interference of the other
    warnings. The crew responded right away (within five seconds) to the Master
    Warning by reducing thrust.
    
    The investigation suggests that, because of the fluctuations caused by the
    turbulence, the reversion from normal law to AoA law would likely not have
    been sensorily detected. Furthermore, this reversion is not possible under
    autopilot control. It is likely that the crew then had, for up to six
    seconds, no obvious reason to judge that the aircraft was operating in AoA
    law.
    
    The investigators say that "Such was the vigor of the A340's climb in AoA
    law, the aircraft could well have climbed through FL 363 (thus provoking a
    TCAS RA with revised software version 7.0) in a very short time, even if the
    crew had applied nose-down sidestick as soon as they heard the (delayed)
    autopilot disconnect warning. The climb to FL 363 would have been sufficient
    to generate a TCAS RA in any adjacent aircraft at FL 370 but, if the
    intruder aircraft continues its climb, there can be no guarantee that an
    aircraft directly above it could respond in sufficient time to avoid a
    collision."
    
    The incident raises the issue of operations under RVSM. The investigators
    recommended suggested that such an incident is relevant to the safety case
    being made at that time for the introduction of RVSM in Europe. The incident
    shows that that a combination of a turbulence encounter, automated flight
    control, and RVSM could prove deadly, with or without improved versions of
    TCAS.
    
    Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
    
    References
    
    [1] U.K. Air Accidents Investigation Branch, AAIB Bulletin 6/2001,
    Ref. EW/C2000/10/2,
    <A HREF="http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm">
    http://www.aaib.dft.gov.uk/bulletin/jun01/cggwd.htm>
    
    [2] Eurocontrol, ACAS II Operations in the European RVSM Environment,
    Project ACTOR, available from
    <A HREF="http://www.eurocontrol.int">http://www.eurocontrol.int> ->
    Projects -> ACAS -> Training Materials
    -> Brochure f11, 2 August 2001.
    
    ------------------------------
    
    Date: 29 Mar 2002 (LAST-MODIFIED)
    From: RISKS-requestat_private
    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)
     if possible and convenient for you.  Alternatively, via majordomo,
     send e-mail requests to <risks-requestat_private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoat_private .
     If Majordomo balks when you send your accept, please forward to risks.
     [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
     this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
     Lower-case only in address may get around a confirmation match glitch.
       INFO     [for unabridged version of RISKS information]
     There seems to be an occasional glitch in the confirmation process, in which
     case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
       .MIL users should contact <risks-requestat_private> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallat_private>.
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
     http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
     The full info file will appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
    => ARCHIVES are available: ftp://ftp.sri.com/risks or
     ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
       [volume-summary issues are in risks-*.00]
       [back volumes have their own subdirectories, e.g., "cd 21" for volume 21]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       Lindsay Marshall has also added to the Newcastle catless site a
       palmtop version of the most recent RISKS issue and a WAP version that
       works for many but not all telephones: http://catless.ncl.ac.uk/w/r
     http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
     http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
    ==> PGN's comprehensive historical Illustrative Risks summary of one liners:
        http://www.csl.sri.com/illustrative.html for browsing,
        http://www.csl.sri.com/illustrative.pdf or .ps for printing
    
    ------------------------------
    
    End of RISKS-FORUM Digest 22.19
    ************************
    



    This archive was generated by hypermail 2b30 : Mon Aug 19 2002 - 16:50:18 PDT