The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 21 Issue 20

Saturday 13 January 2001


Dell, Unisys and Microsoft -- DUMvoting 1.0!
Gene N Haldeman
San Francisco Airport radar phantom flights
Cell phone in luggage alarms avionics
David Kennedy
Testimony before the U.S. Civil Rights Commission
Douglas W. Jones
No human finger will actually pull a trigger...
Daniel P. B. Smith
Swiss debit-card system broke down
Andre Oppermann
Subject: Re: The Chinook Crash
Peter B. Ladkin
Mike Beims
Armchair Chinook RISKS analysis is misplaced
Nathan K. Pemberton
Since when is Northern Ireland considered a war zone?
Chris Warwick
Oregon Jurors summoned for 1901
Aydin Edguer
Y2K bug in Millennium clock
Mike Palmer
Re: 54 weeks in a year?
'o-Dzin Tridral
Paul van Keep
Info on RISKS (comp.risks)

Dell, Unisys and Microsoft -- DUMvoting 1.0!

<Gene N Haldeman <>>
Fri, 12 Jan 2001 17:56:28 -0500 (EST)

  [It is never too early for April to roll around.  PGN]

"This Message Can Not Be Considered Spam, Even Though It Is.
Some Law That Never Was Enacted Says So."

Dell, Unisys and Microsoft have joined together to produce:
  DUMvoting 1.0!

DUMvoting 1.0 is a simple 375k zipped download which you can install on
your machine tonight, and vote for President tomorrow!  Worried about
hanging chad?  Not with DUMvoting 1.0!  No, your vote will travel over
HEALTHY SAFE Internet connections to our new DUMvoteCenter, located in my
next-door neighbor's basement where a 16-year-old computer genius known as
SWORDGANDALF will convert it into paper ballots in between Dungeons and
Dragons games.

(Note: During installation, a pop-up box may notify you that Back Orifice
is being installed.  This is normal.  For best results, please disable all
anti-virus software before installing DUMvoting 1.0)

NEVER AGAIN will you walk to a voting booth in the rain.  NEVER AGAIN will
you have to associate with the kind of people (and you know what I'm talking
about, I don't have to spell it out for you, do I?) who hang around the
voting area.  NO MORE messy contact with neighbors.  We have got it ALL
WORKED OUT for you.

And with our new SPEEDYEXITPOLL (c), you won't have to wait till midnight
for the outcome!  We will be sending our projections the day before the
elections, and our exit polls by 11:30 am on election day, saving you both
time and anxiety.

You must act fast, but DUMvoting 1.0 can be rushed to you for the low, low
price of $299.00 from our website at  In addition, we will
send you OILMAN 3.2, the exciting new game from Microsoft:  Alaska's Up For
Grabs, And You Have Just Been Appointed To The EPA!  Plunder as you will,
but watch out for the charging caribou; we're told they have a "thing" for
the pipeline!

Order without delay.  Please include your Social Security number and any
recent medical bills.

*Sent by the Dell/Unisys/Microsoft Consortium:  "DUMideas Last Forever."

  [Note that DUM spelled backwards is MUD.  Must be symbolic.  PGN]

San Francisco Airport radar phantom flights

<"Peter G. Neumann" <>>
Tue, 9 Jan 2001 14:48:49 PST

The effort to install a new ground radar system for collision avoidance has
been set back by the appearance of phantom planes.  In earlier tests, a
Fremont-based component created ghost images for six nonexistent planes,
giving the appearance that two planes were heading for the same runway.  The
bug has finally been identified (according to a radio report), but it must
now be fixed, whereupon tests will continue.  [Source: Wire services, 8-9
Jan 2000]

Cell phone in luggage alarms avionics

<David Kennedy CISSP <>>
Fri, 12 Jan 2001 02:18:54 -0500

Reuters noted that a Slovenian Adria Airways airplane made an emergency
landing in Ljubljana on 9 Jan 2001 because of a cell phone in the baggage
hold had been left on.  It is asserted that the ringing phone corrupted
plane avionics and triggered a fire indicator.  [PGN-ed from]

I'm not certain how this should be classified:
  Remarkable detection of RFI without instrumentation?
  Remarkable instance of RFI?
  Remarkable instance of attributing flight instrument irregularities
    to RFI after an aborted flight?

Rhetorical:  If this had occurred in the US, would the incident have
counted against the airline's on-time statistics?

Dave Kennedy CISSP Director of Research Services TruSecure Corp.

  [Also noted by Aydin Edguer at

Testimony before the U.S. Civil Rights Commission

< (Douglas W. Jones,201H MLH,3193350740,3193382879)>
12 Jan 2001 22:46:04 GMT

My testimony before the United States Civil Rights Commission hearing on
allegations of election-day irregularities in Florida, Jan 11 2001, is
indexed on the Web at

My testimony was presented as part of the Expert Panel on Voting Technology,
along with testimony from Kimball Brace (Election Data Services) and John
Ahmann (Election Supplies Inc, the major Votomatic vendor).  My testimony
and Brace's testimony were in strong agreement on key issues involving
information that must be reported in the canvass of an election that is very
irregularly reported today.  I made strong statements about the risks of
standardizing election technology, as opposed to setting performance
standards, and I pointed out major problems with the current regulation of
computer software used in elections.

It was covered live on CSPAN, and if the USCRC follows its usual procedure,
multimedia transcripts of the oral testimony (audio and video) will be on
their web site in about a month.

Doug Jones <>

No human finger will actually pull a trigger...

<"Daniel P. B. Smith" <>>
Fri, 12 Jan 2001 16:10:55 -0500

"Hemos," in an article in Slashdot, called my attention to
This describes a weapons system under development, in which a Boeing 747
will carry an airborne laser capable of shooting down missiles.  According
to the article:

  No trigger man

  No human finger will actually pull a trigger. Onboard computers will
  decide when to fire the beam.

  Machinery will be programmed to fire because human beings may not be fast
  enough to determine whether a situation warrants the laser's use, said
  Col. Lynn Wills of U.S. Air Force Air Combat Command, who is to oversee
  the battle management suite.

  The nose-cone turret is still under construction

  "This all has to happen much too fast," Wills said. "We will give the
  computer its rules of engagement before the mission, and it will have
  orders to fire when the conditions call for it."

  The laser has about only an 18-second "kill window" in which to lock on
  and destroy a rising missile, said Wills.

  "We not only have to be fast, we have to be very careful about where we
  shoot," said Wills, who noted that the firing system will have a manual
  override. "The last thing we want to do is lase an F-22 (fighter jet)."

"I should've done better, didn't mean to be unkind.
Y'know that was the last thing on my mind..."

Daniel P. B. Smith <>

Swiss debit-card system broke down

<Andre Oppermann <>>
Wed, 10 Jan 2001 01:23:39 +0100

On the day before Christmas Eve, usually the day with the highest turnover
of the year in all shops, the whole Swiss debit-card (EC-Card) processing
system of Telekurs broke down for more than two hours. Also getting Money
from ATM's and the processing of on-line MasterCard credit card payments,
which is handled by the same company, was interrupted.

In Switzerland the debit card "EC card" is quite popular and nearly everyone
with an bank account has one of these and also most people use it more or
less often. With the EC card, you can get money on ATM's and pay your goods
in shops and restaurant by swiping the card and entering your PIN code (no,
I don't go into that) like an credit card but the amount is deducted
directly and immediately from your bank account.

Now on Saturday 23 Dec 2000 at 13:15, a tape robot in an automated tape
library in the data center of Telekurs, the sole operator of all EC card
transactions, drops a tape on the floor which in turn leads to an error
propagation which shuts down the whole EC and MasterCard card processing for
approximately two and a half hours until 15:25.

The impact was quite unpleasant: thousands of frustrated people unable to
pay the Christmas presents for their loved, high revenue losses for the
shops on the most important day of the year and more than 100,000
transactions rejected.

What do we learn from this? The usual story: don't put all your eggs in the
same basket; have better failure recovery procedures in place for such an
important system, it should not be possible that a dropped tape brings the
processing of all transactions to a grinding halt.

For reference coverage by the media (in German):$72NB6$T.html

Andre Oppermann

Re: The Chinook Crash (Risks 21.18-19)

<"Peter B. Ladkin" <>>
Wed, 10 Jan 2001 13:09:16 +0100

O'Connor (Risks 21.18) and Payne (Risks 21.19) have recently discussed the
1994 RAF Chinook transport helicopter crash on the Mull of Kintyre. And then
there is Ryan O'Connell's contribution, of which more later.

This is a very public discussion in the UK. It is said to be the first time
that the Royal Air Force has put an accident report in the public domain
(J.M. Ramsden, "RAF Safety after Chinook", Pilot, November 2000, p22) and
the controversy is sufficiently well developed for the UK defence minister
at the time of the accident, Sir Malcolm Rifkind, to have requested one of
his successors, Geoffrey Hoon, to set aside the finding of gross negligence
reached by Sir William Wratten (op.  cit., p23). It is probably the first
time ever that an Air Chief Marshall with authority to determine an accident
finding has written an article in the "popular" aviation press to explain
his finding (Air Chief Marshall Sir William Wratten, "Why those Chinook
pilots were `grossly negligent'", Pilot, August 2000, pp20-21).

Here is a brief description of the controversy. The Kintyre peninsula is
long, narrow, hilly (one hesitates to say "mountainous") piece of Scotland
whose end, the Mull of Kintyre, attains a height of 1404ft MSL (above mean
sea level) and is some 20km (13 miles) or so across the North Channel from
the nearest point of Northern Ireland. There is a lighthouse on the west
side of the Mull, directly below the "peak" (Ordnance Survey, Routemaster
Series, Number 3, Western and Central Scotland, ISBN 0-319-23003-1).

The flight was performed under a Visual Flight Rules (VFR) flight plan.
Visual flight was performed over the North Channel. Close to the lighthouse
on the Mull, the aircraft flew into Instrument Meteorological Conditions
(IMC) and hit ground at 810 feet, some 2,000ft below Instrument Flight Rules
(IFR) Safety Altitude for this sector of the planned route, calculated to be
some 2,800ft MSL, at a groundspeed calculated by the Air Accident
Investigation Branch to be some 150kts (Wratten, op. cit., p20. 1 knot (kt)
is 1 nautical mile (nm) per hour; 1 nautical mile is about 1.15 statute

The aircraft was equipped with a "SuperTans" GPS-based navigation computer
(Ramsden, op. cit., p21), and a VFR flight plan waypoint change was made, to
a waypoint some 87nm beyond the lighthouse, less than one nm from what was
to be the point of impact (Wratten, op. cit., p20).

The accident flight was equipped with neither a flight data recorder nor a
cockpit voice recorder. All parties to the controversy agree that we can
never know exactly what happened or why. We want to know why those highly
trained and experienced pilots flew into IMC on a VFR flight plan, and why
they did not perform regulation and trained maneuvers for such an
eventuality (slow down, climb immediately to at of above IFR Safety Altitude
for that sector, and immediately initiate a turn away or a 180-degree
reversal of course out of the IMC and back into the Visual Meteorological
Conditions (VMC) from whence you have just come. Wratten, op. cit., p20). We
shall never know the answers to these questions.

Flying into IMC while under VFR is one of the biggest killers of general
aviation pilots and their passengers. It also kills lots of professional
"bush" pilots in places such as Alaska. Every pilot, *every pilot*,
including students, is explicitly trained both to avoid doing that, and in
what to do if you do it anyway (namely, the maneuvers described above, which
are universal).

The Chinook helicopter, known as an HC.2 in UK military service, is a
twin-rotor heavy transport helicopter. It has one rotor fore, just behind
and over the cockpit, and one rotor full aft of the long fuselage. The HC.2
has a history of engine control system malfunctions (it is equipped with
Full Authority Digital Engine Control, FADEC), including uncommanded
"run-ups" (Ramsden, op. cit., p21). I take this to mean either an
uncommanded increase in power output or an uncommanded increase in rotor RPM
or both, but I don't know the exact history. Ramsden refers to Squadron
Leader Bob Burke, an RAF Chinook test pilot who has experienced "uncommanded
HC.2 rotor runaways" (op.  cit., p23). Furthermore, on the day of the
accident flight, one of the flight crew asked groundcrew to check the
navigation computer for "unusual GPS satellite tracking data. This check was
completed with `no fault found'" (Ramsden, op.cit., p21).

RAF Rule AP.3207.8.9 requires that there be no doubt in the case of a
finding of pilot negligence (Ramsden, op.cit., p21).

The controversy is briefly as follows. ACM Sir William Wratten asserts that
there is no doubt that the pilots flew into IMC conditions on a VFR flight
plan, and that there is no evidence of any technical malfunction which could
have caused them, against their training, to do so. His most reasonable
critics believe that there is indeed such doubt: for example, an uncommanded
run-up of the sort previously seen on the HC.2 could have caused the flight
pattern out of VMC into IMC and impact with the Mull (for example, Ramsden,
op. cit., p23, cites specific critics and an article in Pilot, October 1999,
which I have not read). Sir William replies that there is incontrovertible
evidence that the decisions and action of the pilots that led to flight into
IMC occurred independently of the occurrence of any such technical problem
or other factors presumed by some critics to be relevant (Wratten, op.cit.,

Much of the debate centers on the nature of RAF accident investigation
procedures, the nature of doubt and what kinds of considerations and
evidence lead to it (the nature of hypothesis, plausibility, and their place
in accident reports), the nature of justification and sufficient
justification under conditions of uncertainty, the purpose of accident
reports according to the RAF and whether the RAF's finding in this case
fulfills that purpose, whether there is a "culture of blame" in RAF incident
investigations, whether certain kinds of potential evidence was ignored, and
whether it should have been, and the effects of the finding on military
personnel as well as bereaved families, as well as the nature and role of
secrecy and openness in accident investigations.

I believe that civil societies need to consider such issues, and it is clear
that the RAF investigators and their commanding officers, as well as their
more reasonable critics, are acting in good faith and the controversy is
intellectually serious. I believe the debate is socially healthy. But then I
would, wouldn't I, given my interests in the analysis of complex system
failures? Well, not inevitably. I contrast the Chinook debate with that over
the 1988 Airbus A320 accident at Habsheim, on which debate I have expressed
my views, based on a first-level Why-Because Analysis, elsewhere (Section 5
of "Causal Reasoning About Aircraft Accidents, pp 344-355 of Computer
Safety, Reliability and Security, Proceedings of the 19th International
Conference, SAFECOMP 2000, ed. Koornneef and van der Meulen, Lecture Notes
in Computer Science, Volume 1943, Springer-Verlag, Berlin, Heidelberg, New
York, 2000).

Back to the RISKS contributions.  O'Connell (Risks 21.19) seems to believe
that the distinction between VFR and IFR doesn't exist for the UK military,
that the pilots "would have" been operating under some other unspecified
flight rules than VFR or IFR, that they were using terrain-following radar,
and that it is OK to perform terrain-following flight in IMC in the vicinity
of steeply-rising terrain, and that they might well have been doing that
because they were worried about anti-aircraft fire from terrorists.

Whereas O'Connor's and Payne's intellectual VFR has kept them and RISKS
readers well clear of clouds, O'Connell is flying, thankfully solo, into
IMC. Lighthouse keeper PGN, observing right on the border between VMC and
IMC, failed to notice despite his sense of smell that O'Connell was flying
directly into the Mull. It remains for our moderator only to explain the

Peter Ladkin

Re: Chinook (Risks-21:18 and Risks-21:19)

<Mike Beims <>>
Thu, 11 Jan 2001 16:18:49 -0500

The current debate about the June 2nd 1994, RAF Chinook Flight ZD 576 crash
into the Mull of Kintyre centers on the Full Authority Digital Engine
Controller (FADEC) used by that helicopter.  The FADEC was built by the
Textron company.

In Risks 21:18 John O'Connor makes a case for Controlled Flight
Into Terrain due to pilot error compounded by weather factors.

In Risks 21:19 Phil Payne makes a case that an additional risk was
not having a recording of the flight data.

Also in Risks 21:19 Ryan O'Connell makes a case that a risk mitigator for
low level flight in fog is the on-board terrain following radar and the
military pilots training for "Nap of Earth" flying.  My understanding is
that even with radar, "Nap of Earth" flying is a high workload activity.

A search of the United States' National Transportation Board's (NTSB)
found three FADEC related helicopter crashes, and also the fact that the

FADEC itself permanently records some flight data.

The accidents are:
(1) FTW96LA395; September 21, 1996, a Bell 407 helicopter; registration:
(2) MIA97RA005; OCT-09-96; a Bell 407 helicopter; registration: N1117P
(3) FTW97RA055; NOV-20-96, a Bell 407; registration: ECGJC

Note the closeness of the dates and two of the registrations.

All of these crashes were considered pilot error.  Readers of this forum may
recognize a human factors risk in the interface and procedures for recovery
from FADEC failure.  From the FTW96LA395 accident report:

"According to the Bell 407 Rotorcraft Flight Manual, when the FADEC FAIL
warning light illuminates in flight, the pilot should accomplish the FADEC
FAILURE procedure as prescribed in paragraph 3-3-K.  The procedure is,
immediately retard the throttle and hold it to the 90% throttle bezel
position; maintain Nr (rotor) with collective only; depress the FADEC MODE
switch one time regardless of switch indication, FADEC will switch to MANUAL
mode 2 to 7 seconds after this action if it is not already in manual mode;
maintain Nr 95% to 100% with throttle and collective; land as soon as
possible, and perform a normal shutdown if possible. There is a warning that
2 to 7 seconds after the FADEC FAIL warnings, FADEC may be in MANUAL mode
without any pilot action.  Nr may increase very rapidly and overspeed to
110% which will result in an engine flameout unless the pilot takes
immediate manual control of the FADEC with the throttle."

The fact that FADECs have a permanent record of their data comes from the
Statement of Mike Poole to the Transportation Safety Board of Canada
speaking about the September 2nd, 1998, SwissAir MD-11 crash off Peggy's
Cove: "the FADEC from the Number 2 engine gave us data in those last six
minutes of the flight where the recorders had already stopped. So, in this
case, the non-volatile memory was extremely useful."

The procedure for recovering from failure, the risk of engine failure if the
procedure is not followed and the existence of non-volatile memory in the
Textron FADEC are confirmed by the Bell Helicopter/Textron website:

A probable cause for the June 2nd 1994, RAF Chinook Flight ZD 576 crash into
the Mull of Kintyre may include a human factors risk in the interface and
procedures for recovery from FADEC failure.  This would be aggravated by a
high workload flight regime.  Data for whether or not there was a FADEC
failure should have been available in the non-volatile memory built into the

Mike Beims <>

Armchair Chinook RISKS analysis is misplaced

<"Nathan K. Pemberton" <>>
Wed, 10 Jan 2001 09:59:59 -0800

In my opinion, the armchair analysis of the Chinook crash by RISKS
participants is a pointless exercise. The military does not operate in a
risk-free environment. They regularly take on risks which would be
unacceptable to the general public. This does not imply that they should be
absolved in cases of recklessness, but the tone of the discussions so far
seems to be alarmist. For a bunch of computer jocks to try to tell the
military its business when it comes to operations is the height of

For a picture of the types of risks involved in military helo ops, read the
book "Black Hawk Down" by Mark Bowden. Not having served in the military
myself, I cannot attest to its accuracy, but it was well received by
soldiers involved in the actions described. Some of the book also appears
with supplementary material on the Philadelphia Enquirer web site:

Nathan Pemberton <>

Since when is Northern Ireland considered a war zone?

<Chris Warwick <>>
Wed, 10 Jan 2001 13:08:48 -0500

Re: Chinook (O'Connell, RISKS-21.19)

The Officer in Charge has been held responsible, he/she died in the crash.
Given that the Board of Inquiry does not indicate that the aircraft was
under ground control, I presume that someone on board, likely the pilot, was
the Officer in Charge, and made the decisions that lead to the crash.

A Military Board of Inquiry is made up of both peers and superiors of the
Officer in Charge. The function of the Board is to examine all the factors
leading to an incident, and to examine whether the Officer in Charge made
correct or reasonable decisions along the way. In this case the Board has
evidence that decisions made and risks taken were NOT appropriate for the
threat environment.

The Captain usually goes down with his ship, whether he/she lives or dies is a
separate matter.

The risk is we overlook a potential cause for future problems, because this
ruling implies that the aircraft operated flawlessly.

In this case the "cause" of the accident is clear, but we may still need to
examine why the aircraft intersected the ground. If for no other reason than to
make future Nape-Of-The-Earth operation as safe as it can be...

Oregon Jurors summoned for 1901

<Aydin Edguer <>>
Thu, 11 Jan 2001 18:24:38 -0500

In Multnomah County, Oregon, about 3000 residents have been summoned to
show up for jury duty in 1901.  One person responded that he couldn't
possibly get there in time because he had not yet been born.
[Source: Michelle Roberts, *The Oregonian*, 3 Jan 2001; PGN-ed]

Y2K bug in Millennium clock

Wed, 10 Jan 2001 12:14:11 -0500

I received one of those countdown to the millennium clocks for Christmas
1999.  It counted down the days/hours/minutes/seconds to Jan 1, 2000.  When
it reached zero, the displayed stayed at all zeros and flashed.

Everything worked great.  It has a mode function that you can get it to
count down to Jan 1, 2001 (they call this scientific mode as opposed to
celebration mode).  After New Years 2000, I set it to scientific mode and
forgot about it.  A couple of days before New Years 2001, I dug the clock
out and noticed that the count down was off by a day.  It was displaying 1
day and several hours to new years on Dec. 29th.  I figured that it had lost
a day sitting in my drawer.  When I checked the actual day (you can set it
to be just a date/time clock as well), it was correctly set to Dec. 29th.
It turns out that the date/time software/firmware correctly dealt with leap
year 2000, but the countdown code missed the boat.  It must have been hard
coded to count down to Jan 1, 2000, and then they probably added 365 days
for the count down to 2001.

My Millennium clock has a millennium bug.

Mike Palmer

Re: 54 weeks in a year? (RISKS-21.18)

<"'o-Dzin Tridral" <>>
Fri, 12 Jan 2001 12:44:50 -0000

Doesn't the problem of 54 weeks in a year depend on how week numbers are

The problem of 54 weeks seems to depend on starting weeks on a Sunday and
counting Week 1 as being the week containing 1st January.  Hence in the case
of 2000 you get a Saturday fragment in Week 1, 52 Weeks running Su-Sa, and a
Sunday fragment in Week 54.

The web page appears to make these

The ISO standard for dates and times (ISO 8601) works differently by
starting weeks on a Monday (that's not the important bit) and making Week 1
of a year the week containing the first Thursday.  Hence week 1 of 2000
began on 2000-01-03 and the preceding Saturday and Sunday belonged to Week
52 of 1999.

I've tried to find year that has 54 weeks using the ISO definition, but

The standard is at and there are useful
links from

I think that this standard becomes ever more important now that we're in the
low year numbers of the century.  We'll look back on dates like 03/05/02 and
wonder what on earth it means, given the YY/MM/DD, DD/MM/YY, MM/DD/YY (and
other) possible interpretations.

I hope this doesn't prove to be a week argument and that people will be
encouraged to make a date with a standard.

'o-Dzin Tridral, Senior Computer Officer, UIS, Cardiff University, PO Box 78
CF10 3XL +44 29 2087 6160  W

Re: 54 weeks in a year? (RISKS-21.18)

<Paul van Keep <>>
Thu, 11 Jan 2001 12:43:35 +0100

PGN wrote: The year 2000 began on a Saturday and ended on a Sunday; ergo, 54
calendar weeks.

It is highly unlikely that week numbering was part of the cause [of the
Norwegian anomaly].  Norway and the rest of Europe adheres to a different
definition of the week than the US, where the week starts on Monday. There
is also an ISO spec that defines week numbering.  That spec states that week
1 of a year is the first week that has at least 4 days in that year.  So if
the year starts on a Friday, Saturday or Sunday, those first days still
belong to the last week of the year before.  If we look at 2000, the first
two days are week 52 (they are part of the last week of 1999) and 31
December is exactly the last day of week 52 of the year.

Paul van Keep

  [But some people use U.S. calendar software written by non ISO-aware
  folks!  PGN]

Please report problems with the web pages to the maintainer