Subject: RISKS DIGEST 17.38

RISKS-LIST: Risks-Forum Digest  Sunday 8 October 1995  Volume 17 : Issue 38

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

 Contents:
Fly NorthWest Airlines to unknown destinations (Peter Ladkin)
Text substitution in a fax program (Henry Troup)
More 2000 date problems: Court computers in countdown to chaos (Peter Ilieve)
Dutch phone books not available (Thomas Tonino)
Citizen Intercepts 911 Calls; Helps Police (Steve Bauer)
Billing problem and consequences (Hiranmay Ghosh)
Polymorphism can apply to email.... (Espen Andersen)
Airliner crashes (Charles Smith via Dave Ketchum)
Re: STRATUS success story: an old Univac episode (William Johnson)
Re: The latest maths bug in a Microsoft product (Jim Coffey)
Re: European Encryption control proposal? (David Swarbrick)
ABRIDGED info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Sun, 8 Oct 1995 17:14:49 +0100
From: [email protected]
Subject: Fly NorthWest Airlines to unknown destinations

The International Herald Tribune for Monday Oct 2, p1, has a report on a
DC10, NorthWest Flight 52, on its way to Frankfurt from Detroit.  They
landed in Brussels, much to everyone's surprise except for the passengers,
cabin crew and air traffic control.

A controller in Shannon changed the destination in the en-route computers
for some reason no-one has fathomed. So everyone after that sent NW52
merrily on the way to Brussels. The cabin crew and passengers noticed,
because the cabin flight-path display was showing them going to Brussels
rather than to Frankfurt (the cities are 200miles=325km away from each
other).  The flight crew first noticed when they broke out under the clouds
on approach to Brussels, and noticed that the layout of the airport was not
similar to Frankfurt.  Sensibly, they decided to continue the landing. And
will remain landed until the investigation figures everything out. A
spokesman for NorthWest pointed out that the crew *should* have known where
they were.......

That reminds me of the time I was flying Chicago to SFO and following the
ground on my WAC (World Aeronautical Chart). The routing went south of the
Colorado/Wyoming boundary, past Aspen, and then over the Green river canyon,
which is some 250km past Aspen. Just then, the captain announced "We're just
passing Aspen, Colorado, out of the left window." But we got there OK.  Even
United pilots can recognise the Mina and Coaldale transitions to the Modesto
arrival when it hits them ;-)

Peter Ladkin.

------------------

Date:  Wed, 4 Oct 1995 08:37:00 -0400
From: "henry (h.w.) troup" <[email protected]>
Subject:  Text substitution in a fax program

I have a fax that I have received from the Systems Engineering Society.  In
the footer, it says "Internet: SESociety508-420-0210ol.com" Since I know
that the address is @aol.com, it seems that something has substituted the
outgoing fax number for the "@a".

The root cause appears to be that the formerly rare character "@"
has become more frequently used, making it no longer appropriate
as an escape sequence.
  Henry Troup - [email protected] (Canada) - BNR is not committed to anything I say

------------------------------

Date: Wed, 4 Oct 1995 12:56:49 +0100
From: [email protected] (Peter Ilieve)
Subject: More 2000 date problems: Court computers in countdown to chaos

The following is taken from a report in the Independent (a UK quality paper)
for Tuesday 3 October 95. The headline is `Court computers in countdown to
chaos'.

Programming work is underway to prevent thousands of court cases being
called for 31 Dec 99.

`The Lord Chancellor's department is implementing the scheme to prevent
legal chaos caused because aging court computers cannot speak Latin or
understand the concept of eternity.'

The problem is that many cases are adjourned `sine die' (literally `without
date') when they need to be disposed of without reaching any sort of verdict.
The intention is that they are never seen again. The computers used for
scheduling court hearings can't cope with this so clerks in some courts
have been entering the latest date that the machine knows about---31 Dec 1999.
This means that on 30 December these systems will print a huge list of
all these cases, for hearing the next day. The article suggests that up
to 25,000 cases may be involved in some inner city courts. The exact size of
the problem is unclear as other clerks in other courts may have used other
tricks to get round the problem. A computer `expert' is quoted:

`When the first systems were introduced 25 years ago, the last day of 1999
was still a long way off and it did not matter if these cases were adjourned
until that date. It is only just over four years away and we have got to
do something about it. Fortunately, computer software has advanced and the
courts will not have to record false dates under the new system.'

My comments: the concept of `sine die' has been around for hundreds of years,
it really should have been in the original specification for the system.
Also, if 31 Dec 99 is the latest date the system can cope with, it has
bigger problems than just dealing with `sine die' cases. It won't be
able to adjourn any cases to known, fixed, dates in 2000 and beyond.

               Peter Ilieve            [email protected]

  [Also noted by Keith Bennett <[email protected]>. PGN]

------------------------------

Date: Fri, 6 Oct 95 22:29:26 +0100
From: [email protected] (Thomas Tonino)
Subject: Dutch phone books not available

It seems the phone monopoly, KPN, had some problems restyling the phone
directory of Utrecht. The restyling involved adding a 'yellow pages' kind of
index to the alphabetical section, and the possibility of advertisements in
the alphabetical section of the directory.  The Utrecht directory was
recalled because of a lot of errors; it seems that about 10% of entries was
corrupted one way or the other.  Newspapers reported at the time the cause
was 'computer error' while merging the list of subscribers with the list of
advertisers.

Now, nearly a year later, KPN/PTT still does not have its data right.  No
directories have been published since. For Amsterdam, where I live, this
means the directory will be published in January of February 1996 instead of
the original may 1995. Other cities will have approximately the same delays.

While the subscriber database is correct, the advertisers database is
not, it seems. The subsidiary of KPN responsible for the directories,
Telemedia, told me this:
- They are very busy calling all advertisers to confirm the data.
 Their databases seem messed up somehow.
- The information service doesn't have more detailed business
 information either. That is supposed to come from Telemedia, who
 don't have it.

The being unavailable of directories causes quite some problems. Phone
numbers tend to change quickly here, as it is often not possible to
keep your number even when moving to another part of the city. And even
government or business numbers are quickly given to private subscribers
who will then probably not be happy.

The RISK here is having a lot of calls arrive at the wrong destination.
Having a monopoly run the phone system is probably the biggest cause
here, followed by trusting your (computer) systems and procedures.

Thomas Tonino

------------------------------

Date: Tue, 03 Oct 1995 03:37:14 -0500
From: [email protected] (Steve Bauer)
Subject: Citizen Intercepts 911 Calls; Helps Police

Here is a great report about someone getting involved.

911 phone line crossed

RICHMOND, Va. (AP) -- When Rosa H. Dickson answered her telephone, the
caller requested an ambulance.  It took only a moment to figure out that the
caller had dialed 911 and got Dickson instead.  "When I realized what
happened, I dialed 911 and couldn't get 911," she said Monday.

 [This lasted for half an hour, beginning at 5 a.m.  Dickson then alerted
 the police of the problem, and kept passing info on to police, two calls
 for rescue crews and one for police.  One caller gave the wrong number,
 and then called in again later when nothing happened.  Bell Atlantic
 apparently messed up on maintenance following a system upgrade.  PGN]

------------------------------

Date: Sat, 30 Sep 95 17:30:51 IST
From: Hiranmay Ghosh <[email protected]>
Subject: Billing problem and consequences

For those who are not familiar with this part of the world, Delhi Electric
Supply Undertaking (DESU) is the name of a company that supplies electricity
to the city of Delhi, the capital of a country called India. The company has
been using a computer to make the electric bills of its customers for quite
some time now (the trouble starts!).  One fine morning about a year back,
the computer decided to print wrong customer codes on the monthly bills it
produced for some privileged persons like me. Since the code is long (18
alphanumeric characters!), nobody noticed the mistake.

With good faith, I paid the bill. As you might expect, next month I saw an
arrear amount on my bill. When I took it to DESU's office, they had several
theories on how the error might have occurred. They did an ad hoc correction
on the bill (hardcopy). The same game continued for an year till, another
fine morning, I got a notice for disconnection, the ultimate punitive action
from DESU for non-payment of bills!

A number of panic-calls to the top-brass of the company later, I came to
know the reason. The mystery of the misbehaviour of the computer is still
unknown -- it could probably be a software bug!  More stunning was the fact
that while some of the dealing clerks knew about the problem, they pleaded
helplessness and seemed to be at the mercy of the computer. The matter
becomes worse as the responsibilities of the preparation of the bills,
receipt of payments and the issue of the notices rest with different
departments, with the computer gracefully occupying the centre- stage.

Though my immediate problem (disconnection threat) has been taken care of,
DESU cannot assure me that I shall get a correct bill next month or that I
shall not get yet another funny disconnection notice. As this moment, I remain
under the threat of the monster computer that is probably churning out yet
another wrong bill, either for me or for somebody else.

Though this story is a pretty low-tech one than those usually discussed at
the RISKS forum, the moral remains the same: Computers (for the matter,
technology in any form) should never become the boss!

Hiranmay Ghosh, Centre for Development of Telematics, Akbar Bhawan,
New Delhi 110021, INDIA +91 11 672533,677525 [email protected]

------------------------------

Date: Thu, 5 Oct 1995 09:36:02 +0000
From: "[email protected]" <[email protected]>
Subject: Polymorphism can apply to email....

I am currently setting up my own Web site, through MASSInternet (a
subsidiary of PSInet).  I wanted to call this site espen.com, and to have my
email address be [email protected], which I thought had a nice OO ring to it.
Registering the domain name takes about 6 weeks, so in the meantime PSI gave
me the email address [email protected] (rather grand, but it works fine).

You can probably guess the rest: A number of email systems have a feature
called copy_to_self, and apparently some users think the CC: field is where
to turn this feature on.  A transitory problem, to be sure, and so far the
email copies I have received have not been really interesting....

Espen Andersen <[email protected], soon to be [email protected]>

------------------------------

From: [email protected] (Dave Ketchum)
Subject: Risks to the public
Date: Wed, 27 Sep 1995 01:07:29 GMT

[Via "Will Tracz" <[email protected]>, editor, ACM Software Eng. Notes]

NOTE::: I believe that professionals involved in hardware components of
flight control systems are required to be identifiable and accept
responsibility for the quality of the work they sign off on.

THE FACT THAT SOME COMPONENTS OF SUCH SYSTEMS NOW CONSIST OF COMPUTER
SOFTWARE SHOULD HAVE no EFFECT ON THE ACCOUNTABILITY RULES - but, I
do not remember this being enforced adequately!

>Numb : 274 of 294                            Date   : 09/21/95 11:13am
>Conf : 1975 - alt.politics.datahighway

>From: [email protected] (Charles Smith)
>Subject: AIRLINER CRASHES

[...] Two final notes on the crash of CAL-140: Japan's 23 major insurance
companies will pay a total of $78 million to the families of those killed in
the crash of CAL-140.  In addition, the Japanese National Police are
investigating the crash of CAL-140 under the heading of "MURDER".

Aviation Week and Space Technology

Charles R. Smith [email protected]
Richmond, VA  804/275-7472 web http://www.shore.net/~adfx/2292.html

------------------------------

Date: Thu, 5 Oct 1995 15:17:40 -0700
From: "Johnson.William" <[email protected]>
Subject: Re: STRATUS success story: an old Univac episode

In regards to the `success' story about the STRATUS system, where a room
full of computers survived baking in 120oF heat for 3-4 days with only 2
disk drives failing, this story is remarkable in that it completely
overlooks the inevitable degradation of the electronic equipment at that
site that did NOT fail immediately during the overheating episode. Excessive
temperatures degrade electronic components and reduce their life expectancy
considerably.  For 3-4 days the hardware baked itself in 120oF conditions
without notifying anyone of the underlying problem.  Over the weeks and
months to come after this episode, the owners can expect a
higher-than-normal failure rate of the equipment so exposed.

Had the STRATUS system included a temperature alarm to a central office,
something on the order of, "Hey, guys, my A/C is out and it's over 100 in
here - HELP!"  STRATUS might have not only saved the drives that immediately
failed due to the heat but also the other equipment that will inevitably
fail early as well.

In a sense, this reveals another RISK of modern computers/electronic
equipment; the inability to always diagnose and report to the operators what
is REALLY wrong with the system, even if you have designed a sophisticated
diagnostic/reporting capability into the system.

   ***

This reminds me of a story told by my faculty advisor back in college.  In
his graduate school days he worked on one of the original UNIVAC mainframes
in the country.  That machine comprised dozens of racks of vacuum
tube-technology logic boards stacked in banks up to the ceiling in their
computer room.  Each board controlled a different function in the computer
and he said that after a while he could tell from the error returned in a
malfunction not only which board had failed but also the most likely vacuum
tube that had gone out.  Usually the failure was blamed on excessive heat,
because even with the room's central A/C going full blast the heat from the
tubes kept it nice and toasty in there, especially around the ceiling.

His EE department was always complaining about the high tube failure
rate due to excessive heat so finally the school ordered a newer,
bigger A/C for them.  Unfortunately, when they came to install it, the
electricians forgot to tell anyone that they were shutting off the A/C
power at the breaker box.  So the computer kept running...

..the first anyone knew what was happening was when they heard explosions
from the computer room, as boards blew up starting from the top racks and
then down to the bottom racks, one bank at a time.  My advisor said it took
them 3 months to rebuild the system and when they finished, they welded the
A/C panel box shut.

The RISKS of the right hand not knowing what the left had is doing are
obvious.

------------------------------

Date: 28 Sep 1995 10:16:10 PDT
From: "Coffey, Jim@ARC Mail" <[email protected]>
Subject: Re: The latest maths bug in a Microsoft product (Palmer, RISKS-17.36)

> If you do this on a Macintosh (Excel v5.0a on a PowerMac 8100/110) you get a
> result of 1.40737488355328 = 1.28, proving that the Macintosh is 6 times (as
> powerful as a PC) ...

Interestingly enough., Excel v5.0a on a Mac IIsi also yields .64; however,
if you paste the original number as text and then perform a math operation,
Excell yields the correct result.

What I find interesting (and disturbing) is not that some number that most
people will never use behaves oddly, but that the program behaves oddly.
I'm working on a project that will use digital controls for power plant
applications, and as part of that we need to verify that the system responds
as expected during operations and transients.  I wonder how we will be able
to test for obscure bugs such as this (since if one number does this, what
other features haven't we yet encountered).  More importantly, we need to
design the system to tolerate such undiscovered flaws and not go nuts when
it does (a daunting task).

Jim
  [I have heard some reports that this flaw is actually an intentional
  feature intended to detect copyright ripoffs.  Music publishers and
  dictionary editors have been doing similar things for years.  PGN]

------------------------------

Date: Tue, 03 Oct 95 06:51:04 GMT
From: [email protected] (David Swarbrick)
Subject: Re: European Encryption control proposal? (Anderson, RISKS-17.36)

In Risks v17 no36 Ross Anderson reported a proposal from the Council of
Europe to ban strong encryption within Europe, and to introduce a
'Euro-Clipper'.  I have to say that I think the article he reports jumps
the gun somewhat.  The actual proposal reads (in the relevant section)

"V. Use of Encryption
 ---------------------

 14. Measures should be considered to minimise the negative effects of the
 use of cryptography on the investigation of criminal offenses, without
 affecting its legitimate use more than is strictly necessary."

The UK already allows a Police Constable to obtain a warrant requiring
a suspect to produce all information on his computer 'in legible format'
ie de-crypted, and I suspect this is all that will be required to meet
the proposal.

This is not of course to say that there are not people about contemplating
doing just what Ross relates.  They are usually sat on a fat surveillance
budget, and wondering how they will justify it next year.

David Swarbrick, Swarbrick & Co, Solicitors, 22 Bradford Road Brighouse
HD6 1RW| UK    Tel 01484 722531 [email protected]

------------------------------

Date: 6 September 1995 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED info on RISKS (comp.risks)

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
  INFO     [for further information]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.  [...]
[Back issues are in the subdirectory corresponding to the volume number.]
  Individual issues can be accessed using a URL of the form
    http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
    ftp://unix.sri.com/risks  [if your browser accepts URLs.]

------------------------------

End of RISKS-FORUM Digest 17.38
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.