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 20 Issue 63

Saturday 16 October 1999


o Rome railway station shutdown
Peter B. Ladkin
o Washington DC Metrorail to Replace Relay System
George Beuselinck
o Aircraft computer redundancy and airline safety
Julian Olson
o Y2K creates "horseless carriages"
Jim Griffith
o INS Irony
Paul Robinson
o Re: Signal 109 near Ladbroke
Robert Evans
o Re: Mars Climate Orbiter units confusion
Clive Page
o Extra information in Word documents
Steven M. Bellovin
o Cyberwarfare: The Business Opportunity
Monty Solomon
o Millennium Bugs?
Rick Downes
o You can't get where you want to go today
J Fieber
o Odd synchronicity in items in RISKS-20.62
Chris Smith
o Re: Cyber-Speak
Martin Minow
o Bell Atlantic forgets: exchanges are not unique between area codes
Jonathan I. Kamens
o Yet another case of credit-card 'security'
E. Lange
o CFP: FTCS-30 & DCCA-8 Int'l Conf on Dependable Systems and Networks
Philip Koopman
o Info on RISKS (comp.risks)

Rome railway station shutdown

"Peter B. Ladkin" <>
Wed, 13 Oct 1999 18:50:27 +0200
Traffic at Rome's main railway station was disrupted for the fourth day on
Tuesday 12th October as trains were rerouted and cancelled due to a
malfunctioning new computer system. The station was shut down at the weekend
for installation of the new command system and apparently it didn't work
properly when passengers arrived Monday. Arrivals have been delayed up to 2
hours and departures by up to 50 minutes (or infinity)

Source: International Herald Tribune, Wednesday Oct 13, p2

Prof. Peter Ladkin Ph.D.
University of Bielefeld, Germany

Washington DC Metrorail to Replace Relay System

"George Beuselinck" <>
Fri, 15 Oct 1999 05:13:04 -0400
The Washington DC Metro has had rampant failures among its electronic
relays, and as a result has been running the entire system manually since
April 1999.  The relays had a life expectancy of 70 years, having been
installed in the 1970s, with an expected malfunction rate of one every 50
years.  Although the source of the premature aging is still unknown, it has
been decided to replace all 20,000 relays with new ones -- which is expected
to permit resumption of automatic operation by May 2000.  [PGN-ed,

"In December, a train was told to go 45 mph on a stretch of track with a 15
mph speed limit. In February, a train was directed to travel at 0 mph when
it should have been ordered to move at 15 mph. And in March, a train was
halted when it got a red, or stop, signal, but the rail ahead was clear, and
it should have received a green signal to proceed."

  [Typo in 20,000 fixed in archive copy.  PGN]

Aircraft computer redundancy and airline safety

"Julian Olson" <jolson@CAM.ORG>
Wed, 13 Oct 1999 11:12:39 -0400 (EDT)
We recently flew from Montreal to Washington by way of Detroit (an
interesting way for the deregulated market to deal with our fuel resources).

A few minutes after the scheduled departure time in Detroit, the captain
informed us that there would be a delay while a technician was summoned to
deal with a malfunctioning computer. After inspection of the situation, it
was determined that we would take off as soon as the twenty-minute shutdown
procedure had been carried out. "We are allowed", said the captain "to take
off even if this backup computer is not working". There was no explanation
of why the builder of the aircraft would have gone to the expense of
including an unnecessary computer.

This may have been a quite benign situation and the policy entirely
reasonable - I am not qualified to judge it - but I couldn't help wondering
who did the allowing. It wasn't hard to imagine some bean counter weighing
dollars against safety and deciding that such cases should be resolved in
favor of expediency.

Since this was an A320, reputed - fairly or not - to depend very heavily, if
not excessively, on computers to stay in the air, it didn't encourage a
sense of security. I would be grateful for enlightenment from someone who
understands the issues.

Julian Olson <>

Y2K creates "horseless carriages"

Jim Griffith <>
Tue, 12 Oct 1999 16:28:44 -0700 (PDT)
AP reports that a Y2K glitch has caused 2000 new vehicle registrations in
the state of Maine to bear the classification "horseless carriage".
Apparently, the DMV software misread the 2000 model year as 1900, and it is
hardwired to classify any vehicle with a model year before 1916 as a
horseless carriage.

INS Irony

Paul Robinson <>
Sat, 16 Oct 1999 09:54:55 EDT
The following item was reported in the UK's Silicon.Com weekly round-up:

The US government admitted this week that it had accidentally issued more
visas for foreign high-tech workers than it had intended - 20,000 to be
precise. Why? Because of a computer glitch. Irony once again rears its ugly
head and slaps the authorities around the face with a wet fish.

Re: Signal 109 near Ladbroke (RISKS-20.62)

Robert Evans <>
Wed, 13 Oct 1999 01:02:18 +0100 (BST)
I'm sure that others have also pointed these out, but there are some
errors in the source you used for the information on the train crash.

> The latest head-on collision occurred at the same Signal 109 near Ladbroke
> Grove in Western London as the collision that occurred two years ago (almost
> to the day).

The Ladbroke Grove crash happened on the same line, but some distance
away from the Southall crash of two years previously.  Signal 109 was
not involved in that incident, but has been involved in near-misses

> The train had an Automatic Train Protection System, but it was
> switched off because it was ``not operational''.  Its operation might have
> helped, although it reportedly would not by itself have prevented the
> accident.

The Great Western train from Cheltenham did have ATP which was disabled, but
it would have made absolutely no difference, as the Great Western train had
a green signal.  At the very last minute a signal operator has noticed that
the Thames commuter service had passed SN109 at danger (red), and changed
SN120 to red for the Great Western service, but this was moments before the
collision, far too late for even the best braking systems to have made any
difference.  The Thames Trains service did not have ATP.

Sources for the above are the BBC News website, the *Independent* newspaper,
and many hours of TV coverage (being a regular traveller on the line).

Re: Mars Climate Orbiter units confusion

Clive Page <>
Wed, 13 Oct 1999 09:30:21 +0100 (BST)
Observatory magazine ( reports a NASA press
release dated 11 Sep 1998 11 on the Mars Climate Orbiter which originally

"It is 7.6 feet (25 metres) high, 6.4 feet (21 metres) deep, and 5.4 feet
(18 metres) wide".

This press release ( is
still on-line but was last edited only a few days ago. Perhaps if this
unconventional conversion from Imperial to Metric units had been noticed
sooner, the mission might have survived?

Clive Page, Dept of Physics & Astronomy, University of Leicester,
Leicester, LE1 7RH,  U.K.    +44 116 252 3551

Extra information in Word documents

"Steven M. Bellovin" <>
Tue, 12 Oct 1999 15:19:44 -0400
We've seen many stories, over the years, of information leaking via Word
documents.  Perhaps the most amusing such story is reported in Salon
magazine.  According to,
Microsoft's annual report was written on a Macintosh computer...

Cyberwarfare: The Business Opportunity

Monty Solomon <>
Sat, 9 Oct 1999 00:10:06 -0400,1185,6870,00.html

Cyberwarfare: The Business Opportunity

Grab your digital trench coat - and your business plan. The U.S. has
announced that it will enter the cyberspook business in earnest by
establishing a new center to combat (and practice) online espionage.  On its
face, this was not a business story, and outlets played it straight,
allowing generals and senators to speak gravely of cyberwarfare. But between
the martial drumbeats, a few hints fell to the effect that this initiative
could help U.S. businesses in a big way.

Millennium Bugs?

Sat, 01 Jan 2000 00:37:14 +0000
It is now finally clear to me what all the hysteria about Y2K is really
all about.

It is not about stingy COBOL programmers using two BCD bytes instead of four

It is not about embedded systems collapsing, rendering our traffic
intersections, our satellite systems, and other vital technologies useless.

It is about the latest in a long debilitating line of systemware products
from Redmond, Washington, USA.

This week I received the WinNT Magazine newsletter, with an introduction
from Paul Thurrott, who describes himself as a "recovering Windows 2000
(Win2K) beta tester". Thurrott is largely positive about this monster, but
does add that hardware requirements "have risen from a lowly Pentium to a
300MHz Pentium II with 128MB of RAM" and winds up by saying:

"But I suspect that when the Win2K beta ends, a lot of testers are going to
find themselves balking at the upgrade, at least for the short term.
Suddenly, that wonderful ugly duckling we know as NT 4.0 doesn't look so bad
after all."

It just dawned on me - namely that the great, great majority of PC users
world-wide are home computer enthusiasts, and the great, great majority of
these enthusiasts use their computer primarily - or even exclusively - to
access the Internet, and that they demonstrably do not need anywhere near
the kind of machine necessary to run Win2K to do that, and that they don't
need Win2K at all.

And it dawned on me further that this would hardly change anything. Home
computers running 16 bit operating systems might be perfectly capable of
rendering an enjoyable cyber experience, and I believe Compaq and Netscape
have shown that if one only wants to surf the net that one does not need an
operating system - and one certainly does not need Windows - at all.

But it would be quite unrealistic to assume that the market analysts and
spin doctors in Redmond have suddenly, after decades of incredibly clumsy
successes, suddenly got it all wrong. A gray shadow of unreality creeps
closer, hovering, threatening, foreboding, and I can literally feel it. Here
we have an operating system destined to be one of the greatest and most
bugged monsters of all time offering us literally nothing most of us will
ever need and forcing us, moreover, to upgrade our hardware at a great
expense - and all of this is _for naught_, all of this gives 95%+ of the
world's computer users absolutely _nothing_ - and yet we all know how things
are going to go in the long run anyway, don't we?

The boggle continues. Ballmer insisted Windows 95 would run on a 386 with
4MB RAM. I knew he had to be crossing his fingers behind his back and so I
went out and bought a machine with a Pentium and a walloping 16MB RAM and it
turned out I was right. Yet the quantum leap from a 386 and 4MB to a Pentium
and 16MB is nothing compared to the leap expected now. I have for several
years run courses in NT programming using first the NT 4 Shell Technology
Update and then NT 4 itself, with MSVC running on top, with only 32MB RAM
installed on low-end Pentium machines, and we have never had a hitch. We
have of late attempted to demonstrate Win2K on classroom machines with far
faster processors and many times the RAM and had to abandon our
efforts. Windows 2000 simply peaks the CPU meter even in idle and then
calmly stands still.

I keep thinking about that comment from Microsoft that another RISKS reader
recounted to me: "that's not the way we do things at Microsoft - when it
gets too slow we just throw more hardware at it." And for those of you that
followed the ripples from these forums in the Daily Telegraph's Connect
supplement, yes my company today does have that "Windows Explorer"
replacement mentioned there, and it does not consume a quarter of a megabyte
on disk as its Redmond counterpart, but only 26KB. 26,624 bytes. As one user
wrote to us: "I can finally throw that Microsoft Windows Explorer in the
trash bin where it belongs."

It is important to realize that our conditions were not better than
Redmond's - quite on the contrary. We did not have access to, or ever
consider availing ourselves of a staff several times the size of
Redmond's. We did not work long hours in our offices and sleep on our futons
as one is expected to do in Redmond. We just wrote the program.  Like
anything else we write. And over a time span considerably more realistic
than Redmond used for Windows Explorer.

Bloat is not unavoidable. Bloat is not a necessary evil.

Bloat is always, has always been, and will always be a totally indefensible
blot on computer science.

I fail to see how anyone - even a band of zonked-out Microserfs - can take
what was almost an operating system - NT - almost totally based on, if not
identical with DEC's VMS, and systematically turn it into the biggest, most
bloated bug farm in the history of computer science - and, for every turn in
the road, for every day and week that went by, not _improve_ the code and
make the system run _faster_, but literally _ruin_ the code and make the
system run _slower_, or run not at all. I truly think that the ordinary laws
of logic, of human intelligence, somehow fail to apply in the Pacific
Northwest, and am starting to facetiously wonder if David Lynch wasn't onto
something after all. Is Laura really Melinda French? Doesn't WHG3 have the
faintest resemblance to her father, and SB a bit too much in common with
Kyle's night porter?

For those fanatics who said all along we should leave the big cities, that
people would drop like flies in droves from the hypothermia - I am beginning
to wonder. For the first time I am getting scared of the Millennium - and
not for the COBOL bug, but for the Redmond Millennium Bug. The wife is now
negotiating with the realtors at Prayer Lake to see if they will part with
some of their precious real estate and thereby help save a few more lives.

PS. Anyone who wants a further peek at this "Explorer killer" of ours to see
for themselves that it really can be done is welcome to drop a line at the
address below. We'll send along a complimentary copy.

Rick Downes, Radsoft Laboratories

You can't get where you want to go today

Tue, 12 Oct 1999 23:13:12 -0500 (EST)
I've had a number of experiences making me wary of route planners, though
not as dramatic as those reported in 20.62 (which I have not personally
verified).  Most curious are the can't get there from here journeys.  The
latest impossible trip I booked, ultimately with the assistance of a real
travel agent, was from Indianapolis USA to Glasgow Scotland on

According to Expedia, you can't do that.  According to Northwest's online
booking, you can't do that.  Well, of course, both appear to use the same
Microsoft software.  I'll grant that going to Glasgow via Amsterdam isn't
the shortest way, but it is certainly possible and the only way you are
going to get there on Northwest/KLM.  I know you can get there from here
because I've gone there from here more than once.

In the same way that Internet search engines leave me wanting to know the
scope of their database, harvesting policies, and details of their indexing
and retrieval machinery, travel planning services leave me wanting to know
more of their route planning machinery.  Why though?  I certainly don't
worry about the algorithms my local human travel employs.

It isn't about the imperfectness of the search.  A human agent won't always
find the optimal flight either...the first time around at least.  You see,
the human doesn't need a perfect search algorithm because the human agent
has that amazing exception handling code known as called common sense.

If the electronic travel agent has no common sense to spot suspicious
results from an imperfect algorithm.  When faced with a possible failure, it
should should solicit help from the most convenient repository of common
sense, the user.  In this case, letting me tell it "Yo!  Expedia!  Here is a
hint: Amsterdam is Northwest/KLM's main European hub.  Maybe try a route
through there?" would have done wonders.

But not in the World According to Microsoft where users are idiots and
Wizards claim a monopoly on common sense.  I want smart software, but if I
can't have that, I want dumb software that knows it is dumb and comes to me
for help, not dumb software that thinks it is smart and tells me lies it
believes to be true.

Odd synchronicity in items in RISKS-20.62

Chris Smith <>
Thu, 14 Oct 1999 16:23:57 -0400 (EDT)
I noticed in RISKS-20.62, item 17...

 "Where do you want to be *mis*directed today?"
> From: Laurel, Maryland
> To: Baltimore-Washington International Airport, Maryland
> Driving Distance: 5865.1 miles
> Time: 9 day(s) 3 hour(s) 22 minute(s)
> Driving Directions
>  36:35 Turn left onto Local road(s) (4543.1 mi)
> 219:22 Arrive Baltimore-Washington International Airport, Maryland

And then I noticed in RISKS-20.62, item 18 (yes, the next item [NO

 "Maybe Microsoft owns stock in Canada?"
> Summary
>    From:                 Hastings, Minnesota
>    To:                   Saint Charles [St. Charles], Minnesota
>    Driving Distance:     6758.6 miles
>    Time:                 9 day(s) 17 hour(s) 30 minute(s)
>   Driving Directions
>    50:43           Turn left onto Local road(s) (SE 4543.1 miles)
>    233:30           Arrive Saint Charles [St. Charles], Minnesota

Can someone tell me -- is it really 4543.1 miles from the actual location
indicated to *BOTH* St.Charles, Minnesota *AND* to Baltimore-Washington

Or, similarly - if someone has the detailed directions for the first
(abridged) example - do you actually end up at the same location just before
the last leg?

(For both of these, we would need the unabridged directions from the first
example to see if the previous location was "At Bay Bulls, turn right onto

And might this location be the easternmost reachable point in North America
by car? If so, this appears to be an implementation of that well-known
solution to driving in the wrong direction; just drive around the world. Of
course, once you run out of roads, it's clear that (1) you really can't just
keep going, and (2) after all that driving, you must be at least close.
Just take the local roads for that last little bit.

Chris Smith <>

Re: Cyber-Speak (RISKS-20.61)

Martin Minow <>
Fri, 01 Oct 1999 19:53:09 -0700
Ira J. Rimson notes that printer software delivered on CD-ROM includes a
utility to copy the printer drivers so they can be installed on systems that
lack a CD-ROM and asks,

>  Am I missing something obvious here?

The manufacturer is probably assuming that the customer has at least one
computer with a CD-ROM, but that the printer may be used by other computers
-- presumably on a network -- that lack a working CD-ROM drive.

The CD-ROM probably includes drivers for a variety of operating systems, as
well as PDF copies of the manual, sample images, etc. etc.

CD-ROM mastering costs are quite low (on the order of $0.50 each for 10,000
copies and one-week turnaround).  I suspect that adding a floppy
distribution would add about $2 or more to the manufacturing cost without
adding anything substantial to the overall usability of the product.  So,
from my point of view, it seems like a nice gesture on HP's part, rather
than a chicken/egg problem.

Martin Minow <>

  [Many other similar comments.  PGN]

Bell Atlantic forgets: exchanges are not unique between area codes

"Jonathan I. Kamens" <>
Fri, 8 Oct 1999 14:50:58 -0400
I received a mailing from Bell Atlantic yesterday which was entitled,
"Important Notice for our Brattleboro (254, 257, 258) Exchange Customers."
It starts out:

  Because of growth in the number of telephone lines in your local
  calling area, your exchange will be changed from rate group 6 to 7,
  and rates will be affected as described below.

  Under the Vermont tariff (P.S.B. - Vt. - No. 20 Part A, Section
  5.1.3) exchanges are classified by rate groups according to the
  number of telephone lines in the local calling area....

The problem is that I don't live in Brattleboro.  I don't even live in

It would appear that a Bell Atlantic DB Admin searched for all Bell Atlantic
telephone numbers starting with 254, 257 and 258, regardless of area code.
How much do you think they wasted in postage and printing costs to send out
all those bogus notices?  How many hours are going to be wasted by customer
service representatives answering questions about them?  And why didn't
somebody realize that the number of notices being sent out was more than the
number of customers which could fit in three exchanges?

I spoke to a very friendly Bell Atlantic customer service representatives
who said that she didn't know exactly how widespread the problem was, but
she confirmed that at the very least it went out incorrectly to all
Massachusetts "254" customers.  On the bright side, she confirmed that it
also went out to all the people who were supposed to receive it.  She also
said she thought the mailing created "job security" for people like her.

The unamusing thing about all this is that our telephone rates go up to pay
for stupid blunders like this one.

Jonathan Kamens

Yet another case of credit-card 'security'

E. Lange <>
Fri, 1 Oct 99 20:46:03 JST
Recently I received a new credit card by mail, as an old card was soon to
expire. The envelope was strangely mangled: both the outline of the credit
card and the embossed numerals and letters on the card were clearly
impressed in the envelope and the three layers of paper between envelope and
credit card.

My best guess: someone must have taken an impression of the credit card
through the envelope! (The pressure must have been high, as even the black
paint on the embossed numerals and letters had partially been transferred to
the enclosed letter.)

Needless to say, I called the credit card company and cancelled the credit
card before it became active. I offered to send in the mangled envelope, but
the representative said she wouldn't know what to do with it, and that she
had not heard of any similar case.

The risks: 1) This way of transportation is unsafe: credit card information
can be captured in transit with primitive means; at least some cardboard
would be needed to make sure that cards can not be imprinted through the
envelope.  2) There seems to be no information gathering and warning system
in place to stop new scams (possibly with high criminal energy) in its

And the non-risk: unencrypted credit card transmissions might be
*comparatively* safe, after all...

CFP: FTCS-30 & DCCA-8 Int'l Conf on Dependable Systems and Networks

Philip Koopman <>
Fri, 15 Oct 1999 17:41:00 -0400
                      CALL FOR CONTRIBUTIONS
    The International Conference on Dependable Systems and Networks
                       (FTCS-30 and DCCA-8)
                         New York City, NY
                         June 25-28, 2000

Conference Submission Deadline:    November 5, 1999
Workshop Submission Deadlines:     see

The International Conference on Dependable Systems and Networks represents a
new beginning in the field of dependable computing, as well as the
continuation of long-established traditions.  Formed from the combination of
two established conferences - the International Symposium on Fault-Tolerant
Computing (FTCS) sponsored by the IEEE Computer Society and the Working
Conference on Dependable Computing for Critical Applications (DCCA)
sponsored by IFIP WG 10.4 - this inclusive conference is designed to capture
the wide range of activities in this increasingly important technical area.
The conference scope spans system, software, hardware, and network
issues. Major topics include, but are not limited to, Architectures for
Dependable Computer Systems; Transaction Processing; Fault Tolerance in
Distributed, Mobile, and Real- Time Systems; Safety-Critical Systems;
Dependability of High- Speed Networks and Protocols; Quality of Service;
Fault Tolerance in Multimedia Systems; Software Reliability, Fault
Tolerance, Testing, Validation, and Verification; Dependability Modeling and
Prediction; and Dependability in VLSI.

For information and submission deadlines about the events comprising
the International Conference on Dependable Systems and Networks, check .

Conference General Chair:
      T. Basil Smith (USA)

Conference Program Chairs:
      Doug Blough (USA)
      Karama Kanoun (France)

Workshop on Dependability despite Malicious Faults Program Chair:
      Yves Deswarte (France)

Workshop on Dependability of e-business Systems Program Chair:
      Nick Bowen (USA)

Workshop on Dependability of IP Applications, Platforms and Networks
Program Chair:
      Yennun Huang (USA)

Please report problems with the web pages to the maintainer