The RISKS Digest
Volume 12 Issue 44

Tuesday, 8th October 1991

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…

Contents

RISKS of Highway warning signs
Jim Hofmann
US Coast Guard's user fiendly software [sic]
Dave Schmidt
Fiber optics can spontaneously destroy themselves!
Jeffrey Sorensen
911 Glitch Delayed Help in Fatal Mt. Prospect Fire
W.F. Wicks via Mark Brader
Risks of owning a modem
Geoff Kuenning
Emergency phone dialer in Contra Costa county
Darren Alex Griffiths
ECC == Error CAUSING Code? Tape drive overcorrects itself...
John Board
Re: AT&T "Deeply Distressed"
Bob Colwell
Re: Back quotes print wrong
Dick Karpinski
Simson L. Garfinkel
Re: Space Station Software Hubris
Stephen G. Smith
Schipol Airport
Peter De Graaf via Mark Kennedy
Computer Mediated Ethical Discussion: An Invitation
Peter Danielson
ACM Computer Security Day
Beth Olson
Info on RISKS (comp.risks)

RISKS of Highway warning signs

Jim Hofmann 5577 <hofmann@itd.nrl.navy.mil>
Fri, 4 Oct 91 13:10:05 EDT
On 3 Oct 91 just after midnight, an accident occured partly BECAUSE of the
electronic warning signs.  Woodrow Wilson bridge in Washington D.C. is a
drawbridge, which, when it goes up is supposed to notify three signs each in
Maryland and Virginia.  The signs are programmed to flash a warning message ---
presumably to slow down cars and trucks coming towards the traffic.  In this
case, the sign operators were not notified and hence a truck barrelled into a
queued car and killed the driver.  The implication is that had there been no
signs, the driver might have been more cautious.  But since there WAS a sign
and it was not flashing a warning signal, the driver did not slow down.

The obvious fix here is that if the signs are broken or not notified in
time, the bridge should not be allowed to raise.
                                                       J.B.Hofmann

      [This saga had some strange background.  There are separate controls
      for each side of the river, and the programming is done upon request
      by telephone, via a dedicated phone line.  Apparently there were many
      hours of delay between the receipt of the request to open the bridge
      and the reported attempt to notify the ``programming'' staff, so that the
      notification was not attempted until after prime shift.  The programming
      staff insisted the phone never rang, even though someone was required
      to be in the room at all times and even though the phone rang louder than
      anything else in the room.  The bridge is opened something like 400 times
      per year.  This one was for a sailboat.  Source: Washington Post 4Oct91
      and various news broadcasts.  PGN]


US Coast Guard's user fiendly software

Dave Schmidt <daves@amc.com>
Tue, 1 Oct 91 12:03:40 PDT
(No, I didn't misspell it!)

I recently tried to be a good little citizen and pay the new USCG boat tax.
This involves paying some money, for which you get a nondescript sticker for
your boat; this supposedly prevents hassles with the Coast Guard.

USCG does not have it's own personnel taking orders; you call an 800 number
and either order the sticker with a credit card (!) or order an order form
to use to order the sticker with a check.

The order form we sent was evidently misread, as our address was completely
messed up. When I called back to find out what happened (after 2 months), the
phone droid said:
    "No problem. We'll send you a claim form....Uh oh. The computer won't
    let me fix your address. The claim form will go to the same address
    that the sticker was sent to - you know, the one that the post office
    couldn't figure out?"

Isn't it nice that with all of the work done on making user friendly software,
that people still overlook obvious functions like correcting data entry errors?
If this isn't "user fiendly", I don't know what is...

David Schmidt  WB7RDI  daves@amc.com            Applied Microsystems, Inc


Fiber optics can spontaneously destroy themselves!

Jeffrey Sorensen <sorensen@spl.ecse.rpi.edu>
Tue, 1 Oct 91 15:04:48 EDT
In the Sep 28 issue of _Science News_ there is an article about a recently
discovered property of fiber optic cables that could lead to all kinds of
risks.

It turns out that a fiber optic in an environment "where the temperature
can suddenly increase" can result in the complete destruction of a fiber
optic in what is known as a fiber "fuse" effect.  "For certain types of optical
fibers...damage can occur when the visible-light laser power transmitted...
is as low as 4 milliwatts..."

The damage to the fiber is a series of bullet-shaped cavities that form
at equidistant spacings from the sight of heat damage tracing back towards
the laser light source.  "The damage effectively (ruins) the fiber as a
medium for transmitting light.  One test showed that a single flare could
damage 1.5 kilometers or more of fiber."  The damage travels at a rate of
about 1 meter per second!

The causes of the phenomena are being researched and the sides of the debate
are presented in the article (pp. 200-201).  The effect is related to the
germanium concentration and fibers with high concentrations are at the most
risk.  The temperatures required to cause the effect are between 700 'C and
1,000 'C.

On the risks involved: "It's a lot more catastrophic than just cutting a
line...you basically destroy the fiber."  Anyone using these types of fibers
in, say, a nuclear reactor or for a critical sensor would be well advised to
check this out.
                   Jeff Sorensen    sorensen@ecse.rpi.edu    (518) 276-8202


911 Glitch Delayed Help in Fatal Mt. Prospect Fire (comp.dcom.telecom)

Mark Brader <msb@sq.com>
Fri, 4 Oct 1991 22:42:00 -0400
Date: 2 Oct 91 13:29:45 GMT
From: wickswf@adobe.rtsg.mot.com (William F. Wicks)
Newsgroups: comp.dcom.telecom
Subject: 911 Glitch Delayed Help in Fatal Mt. Prospect Fire
Organization: TELECOM Digest
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 11, Issue 786, Message 7 of 8

Something of interest from the suburbs of Chicago.  In the September 26 issue
of the Northwest Edition of the {Chicago Tribune} was the following article:

  "A computer glitch in the new enhanced 911 system serving six northwest
suburbs caused the system to malfunction as a Mt. Prospect man tried to alert
authorities to a fire that killed his wife and mother, authorities said.

  The incident led Centel to discover and correct the problem before anyone
else was affected.  Mt. Prospects fire officials said the system's failure did
not contribute to the deaths of the two women, who they believe died before the
emergency phone call.

  The 911 error was caused by a record-keeping procedure in Centel's system,
which listed the man's neighbor's phone number (where he placed the 911 call)
both to the home in Mt. Prospect and to another address in Des Plaines which
had previously had the number.  In processsing the call, the 911 computer
software saw two addresses for the same phone number, which is not permissible
in its programming and eliminated one.  When the man called 911 and the
computer read the Des Plaines address, it played a recording saying that the
community was not hooked up to the 911 system.  At this point the call should
have been routed to the Northwest Central Dispatch System, but it did not.  The
recording directed the man to call an operator, who put him in contact with the
emergency dispatcher in Des Plaines.  That dispatcher called Northwest Central
Dispatch officials who sent firefighters to the scene."

Although in this case it was determined that nothing could have been
prevented if the error had not existed, this could have been a very costly
error.  It was found that 26 other people had wrong addresses in the computer.
I found this story very interesting because I live in Schaumburg which just
recently converted to E-911 (not this same system though).

William Wicks   Motorala, Inc.   wickswf@adobe.rtsg.mot.com

[Moderator's Note: I saw the same story. Thanks for passing it along.  Our
Chicago 911 operates pretty well considering the heavy load on it this past
summer with the warfare going on here for the past few months. Those suburbs
with their own 911 (ie, phone exchanges unique to their community) also do
okay. The troublesome ones are as the story noted, those communities with
overlapping phone exchanges where one has 911 and the other does not.  PAT]


Risks of owning a modem

Geoff Kuenning <desint!geoff@uunet.UU.NET>
Sat, 5 Oct 91 02:38:29 PDT
As you may notice from the header of this message, it is about 2:30 A.M. on
Saturday morning (or Friday night, if you prefer).  I just got a knock on my
door, which was astounding in itself.  It turned out to be a couple of cops.
They asked me if I owned a certain phone number, which is the one I use for my
modem (and nothing else).  Apparently it had dialed 911.  In itself, this is
nothing unusual.  I have seen similar reports on RISKS before.  But my L.sys
file has no number containing the sequence 911!  A check of my uucp logs showed
successful calls at 2:01 and 2:08, followed by a failure at 2:23.  Presumably
this last was the cause of the 911 call (we have good police response times
here).  There are two numbers for the 2:23 call, both of which contain the
sequence "166".  Now how did that get turned into 911?  Maybe my dyslexic modem
turned the digits upside down, then got confused about what was repeated :-)?
Seems moderately unlikely.

For what it's worth, it's a Telebit T-2500.  The cops said it happens fairly
often.  Personally, I'm upset.  Those guys have better things to do than chase
spurious calls from modems.  But I have no idea what I can do to prevent a
recurrence.  I've only had the thing a couple of months.  I sure hope this
isn't a "feature".  If so, perhaps the police department has a way for me to
tell them to ignore 911 calls on that line.
                                            Geoff Kuenning   geoff@ITcorp.com

                              [We have had several items on this topic before,
                              but the problem does not seem to go away.  PGN]


Emergency phone dialer in Contra Costa county

Darren Alex Griffiths <unisoft!dag@ucbvax.Berkeley.EDU>
2 Oct 91 18:36:44 GMT
I noticed an interesting news story in the San Francisco Examiner a couple
of days ago.  It seems that a bay area county (Contra Costa) has set up a
system to dial every phone in the county in case of emergencies.  The system
can be setup to dial all the phones (about 30,000) within a few hours in the
event of a toxic spill or other disaster, or it can call every phone within
a few blocks and ask people to look out for a lost child.

Initially this sounds like a good thing, and it probably is, but there are
certainly some questions.  I've never heard of this type of system before,
is Contra Costa the first one to have it?  Also, I assume they didn't test
it by calling all of the phones, so how do they know it will really work?
There are also some interesting risks associated with it.  By definition the
system is connected to the phone network, I wonder what the chance of some
piece of pond scum breaking in to it and sending fake messages to people are?
What if the system breaks and goes wild at 4:00am calling up numbers all over
the world?  Where does it get the address information from as well?  I wonder
if it uses the 911 database or if it has it's own built by the city?

Ahhh, so many questions, so little time.

Darren Alex Griffiths    dag@unisoft.com (for now)   dag@ossi.com (RSN)


ECC == Error CAUSING Code? Tape drive overcorrects itself...

<jab@egr.duke.edu>
Tue, 1 Oct 91 11:19:32 -0400
Product manager's worst nightmare: creating a feature designed to enhance
reliability (in this case of data stored on tape) which, in fact, reduced it
(in this case by sometimes causing data losses).  The RISK of allowing
marketing to force one bell or whistle too many into a design?  Reminds me of
the "Uninterriptable Power Supply" we had in our lab which caused system
crashes by putting spikes on the "protected" side of the supply whenever its
internal cooling fans cut in, but I digress.  I excerpt from a letter recently
received from IBM.  I applaud their frank and rapid disclosure of a potentially
dangerous technical flaw; I find their tone ("well, you don't really need ECC
anyway because our drive is so good") somewhat amusing, a luxury I am permitted
since we experienced no losses.  My opinion might be harsher if we had been
adversely affected by the problem....

  "IBM has discovered that the Error Correction Code (ECC) function in the IBM
150MB 1/4-inch tape drive is not performing to our satisfaction. [...]  This
ECC implementation is unique to this ... drive, and was intended to provide an
additional margin of data protection beyond commonly accepted reliability
levels.  However, a problem has been found which has the potential for causing
loss of data when the drive is reading a tape made with ECC.  There are no
error codes to indicate that this condition has occurred.

  This problem will have no impact on the system until the tape is read,
because the data is recorded correctly on the tape, but may be read back
incorrectly under certain unusual circumstances.  Most users will not
experience this set of circumstances.

  Since the [...] drive provides all the recognized industry standard checking
features such as Read after Write and redundancy checking in addition to ECC,
ECC is not required in order to provide commonly accepted reliability levels
[...]."

John Board, Asst. Prof., Dept. Electrical Eng'g and Dept. Comp. Sci., Duke
University, Durham NC USA +1 (919) 660-5272   INET: jab@ee.egr.duke.edu


Re: AT&T "Deeply Distressed" (RISKS-12.43)

<colwell@ichips.intel.com>
Mon, 7 Oct 91 15:12:25 -0700
   An [AT&T] executive told the FCC that AT&T was ``deeply distressed by the
   lapses in procedure'' that led to a network failure in New York City last
   month.
   ...
   4. Nationwide, AT&T has stepped up plans to spend $200 million over the next 12
   months to improve the reliability and backup of its power systems, which is
   expected to greatly diminish the risk of similar equipment problems.

I get the uncomfortable feeling that the real risk here is being
intentionally ignored. What caused this service outage was human error.
What caused Chernobyl was human error. Ditto for Three Mile Island and the
Kansas City Hyatt hotel walkway collapse. Design engineers can try to
anticipate how machinery and materials will interact with each other. But
it's devilishly hard to predict how something as complex and unpredictable
as a human being, especially one that becomes emotional and possibly
irrational under duress, will react to the system.

It's clear that the human component of the AT&T outage was what caused the
outage. That's the link that needs more attention in the engineering and in
the analysis of failure.

Bob Colwell, Intel Corp.  JF1-19, 5200 NE Elam Young Parkway, Hillsboro,
Oregon 97124        colwell@ichips.intel.com       503-696-4550


Back quotes print wrong (Risks of computerized typesetting)

Dick Karpinski <dick@ccnext.ucsf.edu>
Fri, 4 Oct 91 13:12:59 PDT
I ran into this problem myself and have repeatedly reported the problem both to
NeXT and to Adobe.  For me, with Courier, the back quotes are correct on the
screen and wrong on the laser printer.  Frustrating and dangerous.  It is
possible to see the difference between forward and back quotes in the printer
output, but it is not easy.  Forward quotes print as forward quotes which are a
bit heavier on the top whereas back quotes print as forward quotes which are a
bit heavier on the bottom.

After such a disaster as recently reported, it ought to be easier to get the
vendors involved to fix the problem.  I hereby solicit anyone's assistance in
reporting the problem to appropriate authorities so that it can be fixed.
                                                                           Dick


Back quotes explained (was: Risks of computerized typesetting)

Simson L. Garfinkel <simsong@nextworld.com>
Fri, 4 Oct 91 14:54:09 PDT
After several helpful messages from the net, we have finally figured out what
happened with our Courier font.

Apparently, a few years ago Adobe did a silent change to their Courier font.
Backquotes were changed from the regular character with a negative slope to a
regular forward quote character which happens to be a little wider at the
bottom then at the top.  (The normal forward quote character is a little wider
at the top than at the bottom.)

Thus, the ` and ' characters in the current Adobe Courier font *are* different
characters, but you can't tell the difference unless you look at them under
a magnifying glass.

Happily, Adobe made this substitution without telling anybody, and without
changing the name of their Courier font.

As several people pointed out, we could have avoided this problem by providing
our publisher with our own copy of the Courier font.  The publisher, ORA, has
now started doing this with all of their books sent out to be typeset and
printed.

Ah, standards.                                -s


Re: Space Station Software Hubris

Stephen G. Smith <sgs@grebyn.com>
Thu, 3 Oct 91 20:39:28 -0400
In RISKS-12.42 David Bremner writes:

>... but what worries me is the attitude that writing ( working ! ) 10
>million line programs is a solved problem, that all we have to do is use Ada
>(TM AJPO) and mil-std 2167A, and everything will work fine.
>                                                                 David

Unfortunately, the "MIL-STD" snake oil promises exactly this.  This is
extremely attractive to the bureaucratic mentality — "Follow the written
procedures *exactly* and it will all work".  Anything that doesn't work will be
traced to a failure of somebody (invariably a junior non-manager) to follow the
standard properly.

Note also that in the Washington Post employment ads, "Software Engineer" is a
code phrase for "Junior Programmer with a working knowledge of Ada".

No wonder things don't work.

Steve Smith     Agincourt Computing    sgs@grebyn.com    (301) 681 7395


Schipol Airport

<hvlpb!mkenned@att.att.com>
Fri, 4 Oct 91 14:39 MET
[The following article appeared recently in a Dutch newspaper, possibly
"de Volkskrant."  I have freely translated it into English, so please
excuse any errors I have made with either the translation or with the
English.  Thanks!]

  Scrabble on Schipol, The Letter "A" May Not Be Used Anymore

  Schipol celebrated its 75th jubilee in a sober way on Thursday.
The airport is busy with rebuilding and expansion, and regarded the
"mess" as a cause for a celebration.  A new, fifth pier is being
constructed.  This "E-pier" must be delivered in May.

  But the E-pier will never be called the E-pier.  At the same time
as the opening of the new pier, all of the other piers, exits and
docking locations for airplanes, are receiving new letters and numbers.
A non-trivial operation, which shall be executed overnight and cost around
2 million Dutch guilders.

  The letter descriptions of the piers are being pushed up 2 places in
the alphabet.  The A-pier will now be called the C-pier, the B-pier
D-pier, etc.  The new E-pier will become the G-pier.

  The descriptions are changing to avoid confusion between languages.
The letter "A" in English is pronounced the same as the letter "E" in
Dutch [a long "ayyy" sound].  For example, the airplane to Malaga from
departure gate A12 is, in English, called up as [ayyy 12, or E2 in Dutch].
Less seasoned Dutch travellers could become completely panicked, and
speed off toward the other side of the airport.  "And that is a very long
walk, especially as you must also come back again", says a spokesman from
the airport.

  If the letter A is henceforth taboe in Schipol, that does not apply for
the letter B.  It is true that the new pier descriptions are beginning from
C, but that is being done to allow the small, future extension in front of
pier C to be called B.

  There is still a second reason for the roundabout and costly name changes,
which must be carried out not only on all of the boards, but also in
all of the computer systems.  The descriptions of the exits presently
consist of one [number] with two digits.   Exits have, in the past decade,
been regularly numbered in this way.   There exists, therefore, only one
exit 12, and that is on the A-pier; one 42, on the C-pier; and one 83, on
the B-pier.

  The number of exits and docking locations are threatening to exceed
100 with the expansion of the airport.  They should then be described
with a letter and three numbers.

  This gives problems not only with Schipol's computer system,  but it
could also lead to confusion  with the flight numbers, which consist of
two letters and 3 numbers.

  "Flights from British Airways, for example, are described with BA and
3 numbers.  That can then look suspiciously like a number from the
B-pier," explains the spokesman.  If there is a little bit of noise in the
communication line, it leads to a great confusion.  This applies not only
for the passengers, but also for the pilots and employees in the control-
tower.

  To avoid such communication failures, all number descriptions are
becoming adjusted.  So that Schipol, in the coming days, will never need
to use a number above 100.
                    Peter De Graaf

    = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Note: There are a large number of obvious risks in using a system which
has many potential communication faults, especially when air traffic
control is involved.

  One quick point is that Schipol airport will be facing the same
problem again if it ever expands to include, after the H-pier,
an I-pier.  The letter I is pronounced in Dutch like an English E, and
the Dutch interpret an English spoken I as an "ij", a Dutch "substitute"
for the letter Y.

  Confusing?  Definitely.  Solution?  Perhaps using distinct names for
the piers instead of letters would be the best method.  I seem to recall
one airport which used color coded piers, such as Red pier and Green pier,
etc.

  Mark Kennedy, Explorations Dept., Huizen, AT&T Network Systems Nederland
  mkenned@hvlpb.ATT.COM

[If you get to where you think you are supposed to be and find nothing,
you might find Nay-Pier's Bones.  X-Pier-imental evidence may lead to
N-Pier-ical results, especially in Leap-Piers.   PGN]


Computer Mediated Ethical Discussion: An Invitation

Peter Danielson <danielsn@unixg.ubc.ca>
Fri, 4 Oct 91 14:18:16 PDT
    COMPUTER ETHICS THROUGH THICK & THIN

Computer Ethics through Thick & Thin is a three year research project funded by
an Applied Ethics Strategic Grant from the Social Science and Humanities
Research Council of Canada. The project will investigate the ethical potential
of computer mediated communication by creating two virtual colloquia that
differ in the information available to their members. The Thick group will know
each other only as continuing pseudonyms; the Thin group will be able to access
whatever information its members will contribute.

The two colloquia are based on e-mail in order to encourage wide membership.
The groups will discuss ethical issues raised by computer technology, such as
privacy and ownership and control.

For a description of the project and information about how to join either
group, please contact:

Prof. Peter Danielson, Centre for Applied Ethics, University of British
Columbia, 1866 Mail Mall E-165 Vancouver, B.C. Canada V6T 1Z1
danielsn@unixg.ubc.ca            (604) 822 4658   FAX (604) 822 8627


ACM Computer Security Day

Beth Olson <OLSON@ACMVM.BITNET>
Fri, 04 Oct 91 12:33:03 EST
STUDENT DISCOUNT AVAILABLE FOR COMPUTER SECURITY SEMINAR SERIES

The sponsors of the Computer Security Day Seminars are offering
a Special Discount to Students.

The normal fee of $195 for attendance is reduced to $35 for
students.

Each attendee will receive as part of the program three
excellent books on Computer Security:

    COMPUTERS UNDER ATTACK — Edited by Peter Denning

    COMPUTERS AT RISK      — Published by the National
                              Research Council

    COMPUTERS VIRUSES      — Published by the ADAPSO
                              Computer Committee

Together with posters and a checklist of 53 Ways to Observe Computer Security,
the student attending will get this entire package, excluding lunch for $35.
Call 1-800-524-4023 today to register for the seminar in the city of your
choice.  See the following announcement.

                      COMPUTER SECURITY DAY
                         DECEMBER 2, 1991

Computer Security Day will focus the attention of corporate executives and
computer professionals on those safeguards which are essential, considering the
risk of intrusion into personal privacy and potential disasters that can cause
economic and personal loss.  This program will emphasize that attaining
increased computer security is not only a technical matter, but a management
and social issue as well.

                             SYMPOSIA

In preparation for Computer Security Day on December 2nd,
half-day symposia will be presented in the following metropolitan
areas.  These symposia will provide corporate executives and
computer professionals with practical information to make their
installations more secure.

Tuesday, October 8       Phoenix             Sheraton Phoenix
Monday, October 21       Atlanta             Atlanta Hilton & Towers
Tuesday, October 22      Los Angeles         Los Angeles Hilton & Towers
Friday, October 25       Detroit             Novi Hilton
Tuesday, October 29      Chicago             Palmer House
Wednesday, October 30    Minneapolis         Minneapolis Metrodome Hilton
Monday, November 4       Houston             Westchase Hilton & Towers
Wednesday, November 6    Philadelphia        Univ. of Pennsylvania Faculty Club
Thursday, November 7     Boston              Back Bay Hilton
Friday, November 8       New York            New York Hilton & Towers
Friday, November 15      San Francisco Bay   Sunnyvale Hilton
Monday, November 18      Washington, DC      National Institute of Standards
                                               and Technology (NIST)

For further information, contact: Don Nowak, Program Manager, ACM, 11 W 42nd
Street, New York, NY 10036, (212) 869-7440, Extension 223 nowak@acmvm.bitnet

Sponsored By: ACM SIGSAC, ADAPSO, American Express, Computerworld, Ernst & Young

Beth Olson, ACM Local Activities, 11 West 42nd Street, New York, NY  10036
voice: 212/869-7440; fax: 212/944-1318   olson@acmvm.bitnet

Please report problems with the web pages to the maintainer

x
Top