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 18 Issue 29

Wednesday 31 July 1996

Contents

o Another Ruling Against Communications Decency Act
Edupage
o Bringing Design to Software, Terry Winograd
PGN
o Where Wizards Stay Up Late, Katie Hafner and Matthew Lyon
PGN
o Crisis management, National Research Council report
PGN
o Clinton Anti-Terrorism Plans Called Threat to Civil Liberties
Edupage
o Olympic bomb warning call
Steven Bellovin
o System Testing Begins When System Is Tested
Keith Farkas
o More on: Problems with Olympic Information System
Tom Rowe
o Y2K hits divorcing couples in the UK
Mike Hanafin
o Safety vs. money, always a problem
Geoff Kuenning
o Risks of electronic credit card operations
Robert Schwanke
o Computers Causing Power Outages
D.C. Sessions
o Re: Mark Stalzer and Western Outages
Phil Hammons
o Re: Western power outages: Errata for RISKS-18.28
Paul Green
o Re: Cleaning person inadvertently kills patients
Prabhakar Ragde
Geoff Kuenning
Steve Kilbane
o Ariane 5 failure - due to register overflow
Hans-Martin Adorf
o Findings of the Ariane 501 inquiry board
Kristiansen
o Info on RISKS (comp.risks)

Another Ruling Against Communications Decency Act

Edupage Editors <educom@elanor.oit.unc.edu>
Wed, 31 Jul 1996 11:11:37 -0400 (EDT)
Echoing a decision made last month by federal judges in Philadelphia, a
three-person panel of federal judges in Manhattan rule the Communications
Decency Act (part of the Telecommunications Act of 1996) to be
unconstitutional.  The Act makes it a felony to transmit "indecent" or
"patently offensive" material over computer networks where children might
have access to it.  The law suit involved an Internet-based newsletter
opposed to legislation banning indecent but constitutionally protected
speech on the Internet.  The newsletter's author says it was "laced with
four-letter and multisyllabic obscenities familiar to anyone and, frankly,
the day I published that article, I had some very real fears of going to
prison.  But I felt so deeply that our rights were violated by the law, I
had an obligation to fight it."  The Justice Department is appealing the
Philadelphia decision to the U.S. Supreme Court.  (*The New York Times*, 30
Jul 1996, A7; Edupage, 30 Jul 1996)


Bringing Design to Software, Terry Winograd

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 31 Jul 96 9:03:03 PDT
RISKS has since its inception 11 years ago (1 Aug 1985) noted the importance
of up-front efforts in avoiding risks.  Having sound requirements and a
sound design tends to save great agonies further down the line.  A new book
provides a fascinating collection of chapters that present various different
approaches to software design:

  Bringing Design to Software
  Terry Winograd (editor)
  Addison-Wesley (Reading, Massachusetts)
    and ACM Press Books (New York)
  1996
  ISBN 0-201-85491-0

Although the topics are intentionally quite diverse, there seems to be
something useful for everybody.  Chapter contributors include Mitch Kapor,
David Liddle, Gillian Crampton Smith and Philip Tabor, John Rheinfrank and
Shelley Evenson, Paul Saffo, Peter Denning and Pamela Dargan, John Seely
Brown and Paul Duguid, David Kelley and Bradley Hartfield, Donald Schon and
John Bennett, Michael Schrage, Shahaf Gal, Donald Norman, Laura De Young,
and Sara Kuhn.


Where Wizards Stay Up Late, Katie Hafner and Matthew Lyon

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 31 Jul 96 9:52:18 PDT
  Where Wizards Stay Up Late: The Origins of the Internet
  Katie Hafner and Matthew Lyon
  Simon and Schuster, New York, NY
  1996
  ISBN 0-684-81201-0

At first glance, this new book might not seem sufficiently risks related for
me to comment on it here.  However, one of the biggest risks involving many
people in computer-related fields seems to be a lack of a sense of history
-- except for a few old-timers such as me (but we forget!) and a few younger
folks who have assiduously tried to study the past (except that it is
usually not well documented).  The RISKS archives strongly suggest that the
same kinds of problems keep recurring, and that knowledge of the past can
help significantly to avoid those risks in the future.

This book will make fascinating reading for those of you who don't know the
early history of the ARPAnet.  It points out how only a very few people and
almost no corporations foresaw the incredible potential of the emerging
networking technology.  The book details how the network evolved
nevertheless -- primarily because of the tremendous energies and visions of
a few farsighted people.

Let me add an editorial note.  With its emphasis on advances in connectivity
(for example, packet switching, high availability, alternative routing, and
scalability), there was quite consciously very little emphasis on network
security in the early ARPAnet days -- and not enough emphasis on host-system
security.  You might think that is coming back to haunt us now, with all the
security flakiness relating to the Internet.  However, confidentiality can
be enforced by the use of end-to-end cryptography, and authentication is a
natural burden of the hosts anyway, so the burden falls more strongly on the
operating systems.  Nevertheless, prevention of denials of service is still
in part a networking problem -- although we certainly don't need attacks in
order to have performance degradations!  Recently, while in Massachusetts, I
had repeated serious problems with network reliability telnetting back to
California.  On one occasion, I discovered that two of the major
transcontinental nodes on which I had to depend were *each* dropping about
40% of their packets, over a prolonged period of time.  Perhaps the real
problem is that the wizards are no longer staying up late enough, or that
the new quasiwizards are not familiar enough with history and the sense of
accomplishment that prevailed in the ARPAnet days.  Mayhaps this book will
help.


Crisis management, National Research Council report

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 30 Jul 96 11:57:51 PDT
Computing and Communications in the Extreme:
  Research for Crisis Management and Other Applications
Computer Science and Telecommunications Board,
National Research Council,
National Academy Press, 1996

The full text is available <http://www.nap.edu/readingroom/books/extreme>.

This book is the results of ongoing investigations of the Workshop
Series on High-Performance Computing and Communication.  The steering
committee was chaired by Ken Kennedy of Rice University, and included
Frances Allen, Vint Cert, Geoffrey Fox, Bill Scherlis, Burton Smith,
and Karen Sollins.


Clinton Anti-Terrorism Plans Called Threat to Civil Liberties

Edupage Editors <educom@elanor.oit.unc.edu>
Wed, 31 Jul 1996 11:11:37 -0400 (EDT)
To fight terrorism, the Clinton administration is proposing a number of
measures which civil libertarians say pose a serious threat to the freedoms
of innocent users of phones and computers.  A spokesman for the American
Civil Liberties Union says: 'The president is using the bombing in Atlanta
as a pretense to getting more wiretap authority.  The answer to terrorism
isn't to limit the freedoms of Americans. If we do that, the terrorists have
already won.''  (*San Jose Mercury News*, 30 Jul 96; Edupage 30 July 1996)


Olympic bomb warning call

Steven Bellovin <smb@research.att.com>
Tue, 30 Jul 1996 12:33:43 -0400
Before the bomb exploded at Centennial Olympic Park in Atlanta, there was a
call to the 911 emergency number warning of it.  But there was a 10 minute
lag between when the call was received and when a police officer was
dispatched.  Why?  According to the Associated Press, the dispatchers needed
a street address for the park because the computer system they're using
requires one in order to transmit the information.

  [Also noted by Sean Smith <sean@c3serve.c3.lanl.gov>.  PGN]


System Testing Begins When System Is Tested (Edupage, IBM Olympics)

Keith Farkas <farkas@eecg.toronto.edu>
Sat, 27 Jul 1996 11:36:06 -0400
Complaining about the computer system that failed in the opening days of the
Olympics to provide timely and accurate information about competitive
events, journalists asked Billy Payne, the president of the Atlanta Olympics
Organizing Committee, "Why wasn't the technology system tested?" Payne
replied that "there is no way to duplicate the totality of the Olympic
condition before the start of the games."  [Source: Edupage, 25 July 1996,
quoting *Atlanta Journal-Constitution* Olympic City p34]

  [I was told yesterday during a panel session at the WICS summer course on
  Internet Security at Stanford that the system is no longer Olymping along,
  and that everything seems to be working well now.  I haven't tried it
  myself.  PGN]


More on: Problems with Olympic Information System

<<Tom.Rowe@news.doit.wisc.edu> trowe@aae.wisc.edu>
29 Jul 1996 15:33:56 GMT
IBM stated that typically they need 30-60 (or 60-90, I forget which) days to
set up the type of networking systems used in Atlanta that journalists are
complaining about.  In many cases they had 2-3 days because of delays in the
committee deciding on venues.  I don't know who took the most foolish risk,
the games committee for giving so little time for such a complicated system,
or IBM for accepting such restrictive conditions.  Tom Rowe UW-Madison


Y2K hits divorcing couples in the UK

Mike Hanafin <hanafinm@glas.cork.rtsg.mot.com>
Tue, 30 Jul 1996 12:19:48 +0100
Yet another example of our impending millenium change causing trouble.
This time ordinary people, rather than companies, are directly affected.

>From the *Electronic Telegraph* of 30 Jul 1996:

> PLANS to split the pensions of divorcing couples have been delayed
> until the next century because of problems with the Department of Social
> Security computer, the Government admitted yesterday. ...
> Although the Government sees the need for a change in the law to give
> partners equal rights to pensions, he said the new legislation would not
> be implemented until after 2000 because a big shake-up of the database
> of National Insurance numbers was now underway."

The RISK is: How many more government databases worldwide will be affected
by Y2K? And if more are, do they realise it and are they actively working on
fixing the problem?  They may not always be able to legislate around this
issue.

Mike Hanafin  Motorola  Cork, Ireland  hanafinm@cork.cig.mot.com


Safety vs. money, always a problem

Geoff Kuenning <geoff@ficus.cs.ucla.edu>
Tue, 30 Jul 1996 10:46:58 -0700
I heard an advertisement on the radio the other day which highlights one of
the difficulties we face in designing reliable, safe systems.  The announcer
touted a new feature on BMW automobiles which detects whether a passenger is
present.  This information is used to suppress deployment of the
passenger-side airbag in accidents when appropriate.  The reason for the
feature, and the point made by the ad, is that replacing an airbag costs
about $2500 (actually, they quoted the price for a competitor, not their own
car).  So why inflate the bag if there's nobody to be saved?

RISKS readers are probably shuddering at this concept.  A well-designed
failsafe system would err on the side of unnecessary deployment, not saving
a few dollars.  One would hope that the passenger sensor is designed to fail
into the "passenger present" mode, but it is difficult to imagine a
technology which could be guaranteed to do so in all cases.  The fundamental
problem is that the detection subsystem is designed to suppress a
safety-related behavior in the main system, rather than to redundantly
encourage it, all to save money.  This makes the entire system dependent on
the correct operation of the subsystem.

I cannot help suspecting that a few years from now, when the passenger
sensors and wiring begin to wear out, BMW will suffer some lawsuits
because passenger airbags should have deployed, but didn't.

Geoff Kuenning  g.kuenning@ieee.org geoff@ITcorp.com
http://fmg-www.cs.ucla.edu/geoff/


Risks of electronic credit card operations

Robert Schwanke <rws@scr.siemens.com>
Wed, 31 Jul 1996 11:15:49 -0400 (EDT)
I just went through an amusing process of trying to pay my son's college
tuition by credit card.  The university provided the authorization form by
which to do it, and it has worked in previous semesters.

However, I got a phone call from the university cashier, saying the charge
was declined by the bank.

I called the bank, and was told that the charge was declined because it was
over $5000.  As a security precaution, they expect the cashier to phone in
for a verbal authorization.  They marked my account with my verbal OK, and
said the cashier could phone them directly for a verbal authorization.

I called the cashier back.  She said she can't do anything unless her
computer calls her bank, her bank calls my bank, and my bank okays the
transaction.  I asked her if I could give her my bank's phone number so she
could call and find out what's going on.  She said sure.

She called back later and left a message saying the charge had been declined
again.  I called my bank to see if she had called them, and they said no, it
would have been noted on my account records.  They explained that the
cashier probably had no procedure for handling a verbal authorization; that
many places can no longer do it "the old-fashioned way".  But they would
call her themselves and try to make it happen.

They called the cashier, who had left for the day, but left a message with
another cashier giving the authorization code.

The next day the cashier called me again to tell me that the charge was
still being declined.  I asked if she had called my bank.  She said she had
given my bank's number to her bank, and they had promised to call.  They had
called her back to say that the charge had been declined.

I said, okay, let's split it into two transactions.  Please put the first
one through for $4999.  Okay, she said, that went through.  I said, okay,
now put through a second transaction for the balance.  Okay, she said, that
went through, too.

So much for security.

Robert.Schwanke@scr.siemens.com  rws@scr.siemens.com  (609) 734-6546 Fax -6565
Siemens Corporate Research, Inc., 755 College Rd. East, Princeton, NJ 08540


Computers Causing Power Outages

"D.C. Sessions" <dc.sessions@tempe.vlsi.com>
Tue, 30 Jul 1996 09:34:44 -0700
Every year we add to the "intelligence" of our electrical appliances,
notably computers but also more mundane items such as microwave ovens, air
conditioners, microwave (yup!)  clothes dryers, etc.  Requirements such as
power-factor correction accelerate this trend.  As a result, the electrical
distribution load net is slowly shifting from a constant-impedance line
(electric light) to a constant-power line (computer power supplies).

The RISK?  Constant-power loads exhibit negative resistance: as the voltage
drops, the current *increases*.  As a result, the old-fashioned 'brownout'
is a thing of the past.  The electrical distribution network is becoming
more and more unstable.  Currently it's only unstable at the low-voltage end
of the supply curve, but eventually the instability will reach normal
operating levels.

I got a taste of this in an industrial-automation system a while ago.  If
you think the Year 2000 problem is going to be fun, just *imagine* trying to
manage the power-distribution network in a few years.

D. C. Sessions  dc.sessions@tempe.vlsi.com


Re: Mark Stalzer and Western Outages

"Hammons, Phil" <HAMMONSP@ms1.aes.com>
Mon, 29 Jul 96 10:49:00 -
I wonder where Mark lives to develop the model he is using. Living in the
west where we can see several problems with his model from the front door.

1. To use an economic model to describe a physical entity is at best unwise
and mostly worthless. The only legitimate comparison is that Government
agencies are involved in both and neither is well respected( which has
nothing to do with reliability).

2. He speaks of Redundant Networks of different grades of service. Two
issues:
     A. In a world where it takes multiple organisations to build one grid,
     Where do we find the organizations to build these additional grids?
     B. In the WEST, where do we find the redundant paths for these grids
     without destroying the environment that  many of us came west for?

3. In your competitive model, who fixes the following situation which is
necessary and too, too common. A young lady goes to visit a friend living in
a hillside home. After the visit, she loses control of her van and crashes
the power pole that supplies power to my house (among many others). Power to
our neighborhood is out for 17 hours. The pole must be replaced, crews work
all night, and service is finally restored. Who's going to do the job in
your model? This is real life, last Friday to be exact.


Re: Western power outages: Errata for RISKS-18.28

<Paul_Green@vos.stratus.com>
Fri, 26 Jul 96 13:07 EDT
The abbreviation "CPU" should read "DPU".  8 hours downtime per
year is about 99.9% reliable, not 99% as I had said.  My thanks
to Dr. Marty Ryba of MIT for catching this.

Paul Green, Stratus Computer

["DPU" corrected in SRI archive copy.  PGN]


Re: Cleaning person inadvertently kills patients (RISKS-18.28)

Prabhakar Ragde <plragde@plg.uwaterloo.ca>
Fri, 26 Jul 1996 10:55:01 -0400 (EDT)
Mike Crawford submitted in RISKS-18.28 an apparently doubly-forwarded item
about a cleaner in a South African hospital unplugging a life-support system
every Friday to plug in her floor polisher. I found the news item on the Web
site of the Cape Times. It was changed considerably by the time of its
appearance in RISKS: somewhere along the line, implausible bits about the
"screams and death rattle" of the victims and about a hospital spokesperson
"sending a strong letter to the cleaner" was added. The original said only
that a hospital spokesperson denied knowledge of the incident, and that only
one of the deaths (all of which happened two years ago) was under
investigation by the Free State Health and Welfare Department.

The item was also at an odd location in the Independent Online Webspace:
http://www.inc.co.za/online/news/editorial/film_reviews/topmovies.html.
I'm dubious.

Prabhakar Ragde, Department of Computer Science, Univ. Waterloo, Waterloo,
Ontario CANADA N2L 3G1 (519)888-4567,x4660  http://plg.uwaterloo.ca/~plragde


Re: Cleaning person inadvertently kills patients (RISKS-18.28)

Geoff Kuenning <geoff@ficus.cs.ucla.edu>
Thu, 25 Jul 1996 15:56:14 -0700
Michael D. Crawford writes:

> I don't know if this is true, but it sounds plausible.

It has the ring of urban legend to me.  If a hospital was losing people
every Friday, don't you think they would fairly quickly set up a watch on
that bed?  Also, if the deaths had really happened and the mistake admitted
as readily as quoted, one suspects that there would be lots of news stories
about the subsequent lawsuits.

Geoff Kuenning  g.kuenning@ieee.org   http://fmg-www.cs.ucla.edu/geoff/


Re: Cleaning person inadvertently kills patients (RISKS-18.28)

<Steve_Kilbane@cegelecproj.co.uk>
Fri, 26 Jul 1996 08:41:54 +0100
> I don't know if this is true, but it sounds plausible.
> [Similar cases have been reported previously in the RISKS archives.]

Oh, it happens, although not necessarily with such consequences. I happened
to be in the office recently unplugged the UNIX box next to mine in order to
plug the vacuum in. "Oh, did I unplug something?" she asked, in apparent
surprise. Gurgle. Are there really places that put power cables into
sockets, just to keep the sockets free of dust, or what?

steve


Ariane 5 failure - due to register overflow

Hans-Martin Adorf <adorf@eso.org>
Mon, 29 Jul 1996 12:37:12 +0200
Excerpt from http://sspg1.bnsc.rl.ac.uk/Share/ISTP/ariane5rep.htm

[...]

The launcher started to disintegrate at about H0 + 39 seconds because of
high aerodynamic loads due to an angle of attack of more than 20 degrees
that led to separation of the boosters from the main stage, in turn
triggering the self-destruct system of the launcher.

This angle of attack was caused by full nozzle deflections of the solid
boosters and the Vulcain main engine.

These nozzle deflections were commanded by the On-Board Computer (OBC)
software on the basis of data transmitted by the active Inertial
Reference System (SRI 2). Part of these data at that time did not
contain proper flight data, but
showed a diagnostic bit pattern of the computer of the SRI 2, which was
interpreted as flight data.

The reason why the active SRI 2 did not send correct attitude data was
that the unit had declared a failure due to a software exception.

The OBC could not switch to the back-up SRI 1 because that unit had
already ceased to function during the previous data cycle (72
milliseconds period) for the same reason as SRI 2.

The internal SRI software exception was caused during execution of a
data conversion from 64-bit floating point to 16-bit signed integer
value. The floating point number which was converted had a value greater
than what could be
represented by a 16-bit signed integer. This resulted in an Operand
Error. The data conversion instructions (in Ada code) were not protected
from causing an Operand Error, although other conversions of comparable
variables in the same place in the code were protected.  [...]


Findings of the Ariane 501 inquiry board

Kristiansen <ekristia@xs4all.nl>
Sat, 27 Jul 1996 21:45:28 +0200 (MET DST)
The inquiry board investigating the loss of the first Ariane 5 launcher has
presented its conclusions. I have not seen the actual report of the board,
but I have access to an official summary. Even the summary is a rather
lengthy document, so I have extracted the parts which directly concern the
sequence of events, and the causes of the failure. The extracts are
verbatim, except for my possible typos.

- During the launch preparations and the count-down no events occurred which
were related to the failure. The meteorological conditions were acceptable,
and no other external factors have been found to be of relevance.

- At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer
within the back-up inertial reference system, which was working on stand-by
for guidance and attitude control, became inoperative. This was caused by an
internal variable related to the horizontal velocity of the launcher
exceeding a limit which existed in the software of this computer.

- Approx. 0.05 seconds later the active inertial reference system, identical
to the back-up system in hardware and software, failed for the same reason.
Since the back-up inertial system was already inoperative, correct guidance
and attitude information could no longer be obtained and loss of the mission
was inevitable.

- As a result of its failure, the active inertial reference system
transmitted essentially diagnostic information to the launcher's main
computer, where it was interpreted as flight data and used for flight
control calculations.

- On the basis of those calculations, the main computer commanded the
booster nozzles, and somewhat later the main engine nozzles also, to make a
large correction for an attitude deviation that had not occurred.

- A rapid change of attitude occurred which caused the launcher to
disintegrate at 39 seconds after H0 due to aerodynamic forces.

- Destruction was automatically initiated upon disintegration, as designed,
at an altitude of 4 km and a distance of 1 km from the launch pad.

- The inertial system of Ariane 5 is essentially common to a system which is
presently flying on Ariane 4. The part of the software which caused the
interruption in the inertial system computers is used before launch to align
the inertial reference system and, in Ariane 4, also to enable a rapid
realignment of the system in case of a late hold in the countdown. The
realignment function, which does not serve any purpose on Ariane 5, was
nevertheless retained for commonality reasons and allowed, as in Ariane 4,
to operate for approx. 40 seconds after lift-off.

- During design of the software of the inertial reference system used for
Ariane 4 and Ariane 5, a decision was taken that it was not necessary to
protect the inertial system computer from being made inoperative by an
excessive value of the variable related to the horizontal velocity, a
protection which was provided for several other variables of the alignment
software. When taking this design decision, it was not analyzed or fully
understood which values this particular variable might assume when the
alignment software was allowed to operate after lift-off.

- In Ariane 4 flights using the same type of inertial reference system there
has been no such failure because the trajectory during the first 40 seconds
of flight is such that the particular variable related to horizontal
velocity cannot reach, with an adequate operational margin, a value beyond
the limit present in the software.

- Ariane 5 has a high initial acceleration and a trajectory which leads to a
build-up of horizontal velocity which is five times more rapid than for
Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the
40-second timeframe, the excessive value which caused the inertial system to
cease operation.

- The specification of the inertial reference system and the tests performed
at equipment level did not specifically include the Ariane 5 trajectory
data. Consequently the realignment function was not tested under simulated
Ariane 5 flight conditions, and the design error was not discovered.

- Post-flight simulations have been carried out on a computer with software
of the inertial reference system and with a simulated environment, including
the actual trajectory data from the Ariane 501 flight. These simulations
have faithfully reproduced the chain of events leading to the failure of the
inertial reference systems.

Please report problems with the web pages to the maintainer

Top