The RISKS Digest
Volume 21 Issue 41

Wednesday, 23rd May 2001

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


A Hard Left-Cruise Ship's Autopilot blamed for sharp turns
Kelly Bert Manning
Another backhoe reminder
Bernd Felsche
New Bell Canada service: free calls
Dave Isaacs
The Faith-Based Missile Defense
What's New via David Farber
Time to bury proposed software law
Dan Gillmor via Monty Solomon
NZ Electoral Web Site
Richard A. O'Keefe
Osprey, cont'd
Peter B. Ladkin
Our software is *never* wrong
Erann Gat
Risks in scuba equipment
Carl Page
More on that college network/spam
Danny Burstein
Apple Powerbook 'bomb' shuts Burbank airport
Monty Solomon
Re: Space Station software problems predicted four years ago
Bob Frankston
The new Taiwan $1000 bill got the globe backwards
Dan Jacobson
Police frequencies and fake calls
William Colburn
Power safety
Marcus L. Rowland
Ship to Internet
Donn Parker
2002 ACM Symposium on Applied Computing: SAC '2002
Cliff Jones
Info on RISKS (comp.risks)

A Hard Left-Cruise Ship's Autopilot blamed for sharp turns

< (Kelly Bert Manning)>
Mon, 21 May 2001 13:06:10 -0400 (EDT)

Over 70 people were injured, 13 requiring treatment, when the ship docked in
Victoria, British Columbia. Some refused to get back on board but did so
after the US Coast Guard investigated and cleared it to continue without
using the autopilot. Two injured passengers remained in Victoria for care.

  "It was like the Titanic. People were flying around in chairs. The gift
  shop was destroyed."  USA Coast Guard Lt. j.g. Scott Casad is reported to
  have said that the autopilot malfunction appeared to have been caused by a
  computer error.  The investigation will also look into whether the
  autopilot should have been used in the Strait of Juan de Fuca.

It will be interesting to see exactly what sort of "computer error" this
was. A crew member disengaged the autopilot after the second turn.

Another backhoe reminder

<Bernd Felsche <>>
Fri, 18 May 2001 10:48:03 +0800 (WST)


  Telstra [Australia] estimates 50 to 80 per cent of customers
  affected by yesterday's phone outage in New South Wales have had
  their phone services restored and says the remainder should be fixed
  very soon.

  Technicians have worked through the night to fix a cable which was
  severed by a backhoe on the central coast yesterday, cutting phone
  services from North Sydney to the Queensland border.  Initially,
  Telstra hoped to have the cable repaired early yesterday afternoon
  but the company says the damage was worse than first thought.

  Spokesman Paul Levins says the delays are due to the complex nature
  of the cable repairs.  "Inside the encasement are thousands of tiny
  hairlike fibre optics," he said.  "It's like knitting each one of
  those back together, it is like microsurgery and it is highly
  technical.  But they've got to get the sequencing right so you
  don't end up attempting to ring your mother down the street and wind
  up at the pizza shop."

Bernd Felsche - Innovative Reckoning, Perth, Western Australia

New Bell Canada service: free calls

<"Dave Isaacs" <>>
Mon, 21 May 2001 13:56:06 -0400

According to an articles in *The Toronto Star* and *Wired*
Bell Millennium payphones users were given a rare treat last week:
free access to Telehop's Dialaround low-charge long distance service.

A glitch in the access software allowed anyone who entered 10-10-620 into a
Bell Millennium pay phone to make unlimited free calls to anywhere in the
world.  Word spread quickly on Internet newsgroups, until people were
literally camping out by the phones to wait their turn.

It is interesting that the hole was known by the public for 6 days before it
was fixed.  Why the delay?  Did it take 6 days to discover the problem?
According to the article, Bell didn't start monitoring the network closely
until [a] store containing the pay phones called to complain that the crowds
were disrupting their business.  I also wonder if Bell and Telehop knew
about the problem for some time, but did not count on the exploit being
described on the Internet.

Dave Isaacs

   [Also noted by Aaron PooF Matthews.  PGN]

The Faith-Based Missile Defense (What's New for May 11, 2001)

<David Farber <>>
Sat, 12 May 2001 21:27:17 -0700


Last week, you will recall, President Bush called for a global missile
shield, including space-based elements, but he was pretty short on specifics
(WN 4 May 01).  This week, Defense Secretary Donald Rumsfeld called a press
conference to talk about military uses of space.  Many of us expected he
would fill in some of the missing details from the President's speech.  He
didn't.  Rumsfeld devoutly believes that an effective missile defense is out
there somewhere, but neither he nor the President seems to have any idea of
what the shield would involve or any evidence that such a thing is even
feasible, much less what it would cost, when it might be deployed or whether
it even has to work.  Rumsfeld wanted to talk about the management and
organization of a new national-security space initiative; it would be given
the task of filling in the missing details.  Not a bad strategy — opponents
of a missile shield are left with nothing specific to attack.

  [For IP archives see: ]

Time to bury proposed software law (Dan Gillmor)

<Monty Solomon <>>
Sun, 13 May 2001 18:14:02 -0400

UCITA, the ``Uniform Computer Information Transactions Act,'' is the
technology industry's version of Dracula. It's designed to suck money from
overmatched consumers, and it keeps emerging from the coffin.  Just about
every serious pro-consumer official and organization has denounced UCITA, a
proposed uniform state law that would tilt the balance in software
transactions strongly toward the seller.  But UCITA's backers, mostly in the
computer industry, are not giving up — and they may be on the verge of
getting help from key public officials who, acting in good faith, would harm
the people they're sworn to protect.  [Dan Gillmor, Time to bury proposed
software law, *San Jose Mercury*, 13 May 2001]

NZ Electoral Web Site

<"Dr Richard A. O'Keefe" <>>
Wed, 23 May 2001 14:25:42 +1200

There's a saying in Australia and New Zealand: "when the Americans have a
'cute' idea, we wait a couple of years until they've proven that it's really
really dumb, and THEN we copy it."

*Otago Daily Times*, 22 May 2001, front page.

  Voters will be able to enrol on the electoral roll and update their
  details online using services on an elections web site.  Associate Justice
  Minister Margaret Wilson said the service would be particularly useful for
  people living in remote areas or overseas, as well as the disabled.  She
  also hoped it would encourage young people to enrol to vote.  The site is

I just hope the "disabled" people she has in mind are not the ones with poor
visual acuity, because in Netscape 4.7x or Amaya on a SPARCstation, the page
is unreadable; in Netscape on a Mac it is unreadable, and while it is
marginally readable in iCab, it somehow managed to kill iCab.

The site is slow and confusing.  I have made repeated attempts today to view
my own record, and always arrived at a page saying who was eligible to

What would anyone reading comp.risks confidently predict would be used to
identity a potential voter, so that no-one else can scribble on your record?
SSN (which we call Tax File Number, TFN, and do NOT use except for tax
purposes).  Nope.  It's better than that.

Full name and date of birth.

Maybe the fact that I can't get to my record even _with_ that
information is the security feature I was hoping for....

Osprey, cont'd [Ladkin, Risks 21.33, 21.38}

<"Peter B. Ladkin" <>>
Thu, 17 May 2001 07:36:52 +0200

I advised RISKS readers in Risks 21.33 and 21.38 of three documents
concerning the troubled V-22 Osprey tilt-rotor development and deployment
program - the briefing material from the US GAO review of the program, the
briefing transcript concerning the results of the investigation into the
December 2000 crash, and the report of the Blue Ribbon Panel appointed by
then-Secretary of Defence Cohen to evaluate the program.

The briefers on the accident investigation (the JAG report) into the
December crash pointed unambiguously to a software problem, what they called
a "software anomaly". They said that the Primary Flight Control System
(PFCS) did not behave as it should have (namely, that in a particular
situation, it commanded significant control system changes when it should
have done "nothing") and that this was due to the software. [Ladkin,

The Blue Ribbon Panel report devoted less than a page to software
reliability. Their recommendations focused on methods effective for
determining the characteristics of complex control systems in their
operational environment, and did not include certain standard methods for
assessing and repairing safety-critical software known to contain
errors. [Ladkin, RISKS-21.38]

Define a software error to be a failure of the software implementation to
meet the design specification, or a failure of the software design to meet
PFCS requirements. The JAG briefing indicated that a software error had been
discovered; the Blue Ribbon Panel report led me to suspect whether this had
indeed been the case.

I spoke with Professor Eugene Covert, one of the four members of the Blue
Ribbon Panel, on Tuesday, 15 May 2001, and I put to him the argument of my
RISKS-21.38 note. Although a significant amount of his information is
privileged, he was able to confirm that no software error as above had been
implicated in the December accident and that the range of scenarios I
suggested in RISKS-21.38 broadly represented likely scenarios for the
genesis of the control behavior exhibited.

Peter Ladkin, University of Bielefeld.

Our software is *never* wrong

<Erann Gat <>>
17 May 2001 09:52:48 -0700

The other day I got an e-mail from my on-line credit-card company telling me
that my e-mail preferences had been updated.  Trouble is, I hadn't logged in
to my account for weeks, and I could not remember ever setting any e-mail
preferences.  So my risk radar said, "Hack!" and I called the company.

The rep assured me that my account had not been broken into.  How did they
know, I asked.  "I've got your account right here and I can tell that no one
has tried to break in."  Yes, but *how* can you tell that?  Well, because if
someone had tried to break in it would have said so, and it didn't, so no
one has.

I explained to the rep about the e-mail that I got which could only be
explained by either someone breaking in or a bug in their software.  And if
there was a bug in their e-mail software there might also be a bug in their
hack-detection software.  It should come as no surprise that this made
little impression on the rep.

Risks in scuba equipment

<"Carl Page" <>>
Fri, 11 May 2001 20:34:00 -0700

Scuba divers make a fetish out of safety, for good reason.
I found the list of problems identified by testing by this outfit to be
instructive, and perhaps generalizable.
Thought you might enjoy it for RISKS digest.
Revelations: ScubaLab tests have led to many important revelations, including:

a. A regulator that actually shut off the air supply (a voluntary recall
   by the manufacturer was initiated).

b. Regulators that were advertised as upgraded and yet actually had
   increased work of breathing.

c. Regulators that could not deliver adequate air flow below 100 feet.

d. Regulators that were not adequately prepared for use as delivered.

e. Add-on fittings for regulators, such as swivels, that changed a
   regulator's performance from acceptable to unacceptable.

f. BCs that were supposedly improved with new airways or weight systems,
   but that actually performed worse on tests.

g. BCs with advertised buoyant lift capacities that were significantly
   different from the actual values.

h. BCs with mismatched inflator and ambient hose lengths, disabling the
   remote exhaust function.

i. BCs with excessive inherent buoyancy.

j. BCs with excessive body squeeze.

k. A dive computer that "lost" four minutes during decompression.

l. Dive computers that allowed continuous deep bounce diving.

m. Dive computers that caused compasses to read incorrectly.

n. Hoseless dive computers that lost their signal when other electronics
   were used.

o. Dive computer PC interfaces that did not work.

p. Dive computer instructions that were not correct.

Setting the Record Straight

More on that college network/spam (tls, RISKS-21.39)

<danny burstein <>>
Fri, 11 May 2001 22:16:48 -0400 (EDT)

In RISKS-21.39, of 11-May-2001, your correspondent,, discussed
the problems with the way a local university had recently set up an open
802.11 (wireless) network.

He commented that while this was an arguably defensible decision for a
university, he was quite concerned about its potential use by spammers. To
quote him:

> The RISK?  Their campus mail-handling machines will relay mail to
> any inside or outside destination if it's received from an address
> "inside" their campus network.  The network architecture they've
> chosen for their wireless deployment dictates that anyone can walk
> onto their (large,  urban) campus, or even just park his car outside,
> and spam away freely  with hundreds of megabits per second of
> bandwidth to most points on the Internet.

Having tried exactly what describes (except that I sat in an
air-conditioned van and only sent some test messages...).  I can confirm
that this university's mail servers work as he fears.

Furthermore, any mail coming through them will have an envelope indicating
it came from a well known and trusted source. Meaning not only would people
be more likely to let it through their filters (whether computerized or the
Mark One Eyeball method of glancing at the "from" and "subject" line), but
they're also far more likely to open it.

Meaning this type of service can easily be used to spread all sorts of
nastiness. And not just limited to e-mail viruses and trojans.

Getting back to spamming: this system doesn't block outgoing "port 25"
access, meaning a spammer could set up their own mail server and
pseudo-anonymously engage in all sorts of socially deviant activities.

The RISK? If you leave your front door open on the Internet, you're
leaving everyone else's front door ajar.

Apple Powerbook 'bomb' shuts Burbank airport

<Monty Solomon <>>
Sun, 13 May 2001 18:11:09 -0400

Apple Powerbook 'bomb' shuts airport, article by Drew Cullen, 23 Apr 2001

A California airport was closed for six hours [20 Apr 2001], following a
bomb scare.  And the 'culprit'? Step forward the Titanium Powerbook
G4. Operators of an x-ray machine installed at Burbank airport were unable
to get a high-enough res look at a machine trundling through security. They
called in back up for some chemical analysis. Swabs revealed "residues"
which caused some concern The police and the FBI were called in, flights
were cancelled, and hundreds of customers were left milling the booking

After six hours, the police determined that the Powerbook was indeed
a Powerbook and not a bomb - its hapless owner was released from
questioning, and the airport was free to return to its business.

The scare was blamed on the titanium used in the laptop casing -
officials said this could have given a false reading

Let's hope this mix-up had something to do with the x-ray machine,
rather than some magical shielding properties possessed by the
Titanium PowerMac G4. If somehow it's the latter, Apple could have an
awful lot of product liability suits on its hands.

Re: Space Station software problems predicted four years ago

<"Bob Frankston" <>>
Sat, 5 May 2001 00:16:09 -0700
   (Gross, RISKS-21.39)

Given that I'm in a plane and have time to catch up on old reading (but not
follow URLs — at least until Boeing deploys their IP-to-the-Seats
infrastructure!), I might as well continue to take the contrarian role and
defend the value of risk. There is no way to escape risk so might as well
revel in it.

In this case, I can't resist wondering how one can debug complex software
before deploying it. The danger is more in assuming one can and not
preparing for failure than in not doing complete debugging. This doesn't
mean one should not do any testing, just that the limits must be recognized.

I'm a great admirer of MIR — the ability to keep it going with just the
"chewing gum and bailing wire" (to use an old metaphor) impresses me more
than a design which is "perfect".

In general those who can experiment and survive have a major advantage over
those who must put their energy into trying to avoid risk. If one never
fails, one never succeeds.

In the case of the Space Station, the real question is how the overall
system is architected. Do point failures propagate or are the quenched? What
are the fallback procedures? Is there an attempt at efficiency that tends
towards depending on each module doing what it is supposed to do or is there
the necessary mutual distrust.

I fear that a procurement process that is overly specific actually increases
the risk by making it more difficult to learn by doing.

Bob Frankston  http://www.Frankston.Com

The new Taiwan $1000 bill got the globe backwards

<Dan Jacobson <>>
19 May 2001 08:41:52 +0800

The day I discovered this error, the chief had to call two press conferences
the same day to deny it.  If he admitted it, then he would have had to
recall all the bad bills and print new ones (I suppose not to confuse
counterfeit detection systems).  It would not be possible to admit errors
without revising the note. Tel886-4-25854780

Police frequencies and fake calls (Re: Hutto, RISKS-21.39)

<Schlake (William Colburn) <>>
Sat, 12 May 2001 15:32:55 -0600

I am a volunteer Field Coordinator for the New Mexico State Police (District
11).  The Albuquerque Metropolitan area (District 5 SP) has been plagued by
problems like this, but from cell phones and FRS (Family Radio Service)
radios, not on police frequencies.  Even so, police frequencies are nothing

The quote "The police department's emergency radio system uses two sets of
security identification codes and a computer to prevent unauthorized
access." sounds like media hype to make it sound like something special was
done.  All police frequencies are well known, they are available from the
FCC web page.  The "identification codes" are most likely the sub-audible
tones which tell the repeater how to process the signal.  These are also
well known.  If I were to take my radio to Denver, I could probably be
operating on their frequencies within a matter of minutes.

The "modification" of the radio is also media hype.  Almost any radio,
except those purchased from Tandy, can be modified without any effort.  You
open the back of the radio, and (in most major brands) you will see a single
copper wire amongst preprinted circuit boards.  Anyone want to guess what
happens if you cut the wire?  The FCC laws require commercial radios to be
fixed frequency.  These laws were made for crystal radios, and shouldn't be
on the books anymore.  Most manufacturers make one radio, and just pack and
wire it differently in different cases for different applications.

The computer is most likely just the data link between the cars and the
dispatcher that uploads and downloads information to the in car computers.

As for bogus radio calls, we have had a veritable plague of fake distress
calls from FRS radios and cell phones.  Most cell phones will call 911
without a service provider or SIM card, which allows anonymous untraceable
crank calls.  SAR teams and emergency personnel have responded to crashed
airplanes, automobile accidents, lost hikers, and lots more.  They solved
this problem by asking for a phone number that they can call to verify the
callers identity.  One real hiker was saved because he refered us to the car
company that he rented his car from.  A woman "lost in the mountains" was
ignored because she wouldn't give her name, a name of a friend or relative,
or a phone number where anyone who knew her could be contacted.

Power safety (RISKS-21.36)

<"Marcus L. Rowland" <>>
Sat, 12 May 2001 23:28:24 +0100

I said

>A couple of years ago we rebuilt two labs and were able to replace two
>of these units with normal earth leakage and circuit breakers; there
>has since been no trouble, nobody has been electrocuted, and we have
>never had any loss of power in those labs. I'm now trying to get the
>rest replaced.

And as if by magic I've just heard that they're going to be fixed in the
next holiday, apparently because my complaints finally convinced the
school management that the cure is worse than the disease. Many thanks
to everyone who made suggestions on this in e-mail.

One point did arise in several messages, a suggestion that we have
separate ring mains put in for the computers. Apart from expense, there
was a serious safety issue with this; as mentioned in the original post,
the room is running with the electrical supplies at about -110v
negative, +110v positive, rather than the 0 negative, 220-230v positive
of normal UK ring mains. If a separate supply was put in it would run at
the normal voltage, and possibly a different phase, which could lead to
much more serious problems if the two systems were ever linked.

Marcus L. Rowland

Ship to Internet

<Donn Parker <>>
Sat, 12 May 2001 09:27:36 EDT

Some cruise ships (Renaissance R Two) now have Internet cafes using
satellite services.  I was able to do all of my e-mail work 24/7 for two
weeks ($100 fee) in the Mediterranean from Venice to Barcelona — except for
one day in Naples Harbor.  On that day, the ship was in a position that
precluded the dish line-of-sight to the satellite.  The funnel was in the
way.  I received no refund.  Donn Parker (retired in the nick of time and
glad of it).

  [That would be known as A Napoli Day.  Clearly, A Napoli Day Keeps the
  Internet Away.  But there should also be a Napoli Woods in honor of the
  late movie actress.  PGN]

2002 ACM Symposium on Applied Computing: SAC '2002

<Cliff Jones <>>
Mon, 21 May 2001 10:24:49 +0100

   2002 ACM Symposium on Applied Computing (SAC '2002), CALL FOR PAPERS
                      Madrid, Spain, 10-13 March 2002
       	Special Track on Inter-disciplinary Approaches to the Design
                   of Dependable Computer-Based Systems
           All submissions must be received by September 1, 2001.

A special track on inter-disciplinary Approaches to the Design of Dependable
Computer Systems will be held at SAC'2002. Society's dependence on
computer-based systems continues to increase. The systems themselves --
embracing humans, computers and engineered systems - become ever more
complex as they feed an insatiable appetite for new and extended
functionality.  Furthermore, these trends coincide with pressure for systems
to be brought to market faster and at lower (and more predictable)
cost. Achieving sufficient dependability in these systems, and demonstrating
this achievement in a rigorous and convincing manner, is of crucial
importance to the whole fabric of the modern Information Society.

Although progress has been made in achieving high dependability in computer
hardware and software, wider systems involving computers, people and business
or social organisations are often disastrously unsuccessful and the cause of
huge financial losses or worse. It has become clear in recent years that
satisfactory resolution of this situation demands an inter-disciplinary
approach targeted at understanding the fundamental problems that arise in
attempts to build systems involving complex interactions amongst numbers of
computers and human beings. Inadequate understanding of the complete
organisational and cultural context of use is often a significant cause of
lack of dependability of major new computer-based systems, and will be a
major focus of this track.

By bringing together computer scientists, psychologists and sociologists who
share an interest in the problems of dependability, the proposed track will
make an important contribution to fostering this inter-disciplinary approach.
Submissions will be invited on (but not limited to) the following themes:

     *	Architecture and organisation of systems, processes and their
	environment, e.g., use of diversity in systems and processes
     *	Work and its relationships with technological systems and artifacts,
	e.g., collaboration and interaction, organizational culture and trust
     *	Reasoning about dependability attributes, e.g., temporal
	predictability 	and responsiveness of systems and processes, security
	and confidentiality, formal methods
     *	Socio-technical approaches to systems design and development, e.g.,
	knowledge management and process change, co-evolving work and
     *	Assessment and management of risks involved in system development
	and deployment

Original papers from the above-mentioned or other related areas will be
considered. Each submitted paper will be fully referreed and undergo a blind
review process by at least three referees. The accepted papers in all
categories will be published in the ACM SAC'2002 proceedings.

Please report problems with the web pages to the maintainer