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 6 Issue 57

Thursday 7 April 1988


o "Drive-by-light" automobile to be demonstrated
Jon Jacky
o Air Force replacing flight training with simulation
Jon Jacky
o Cockpit Automation Risks
Alan M. Marcum
o Ada and exploding missiles
Jon Jacky
o Bank money machines
Rick McTeague
o Re: On UnTimely RISKS (RISKs of political consideration)
Eugene Miya
o How Computers Get Your (Clarified) Goat!
Glen Matthews
o Philosophy and discrimination
John Lavagnino
o Comment on "Diving Risks"
Phil Pfeiffer
o Re: The risks of rumours
Henry Spencer and Ken De Cruyenaere
o Re: High Tech Trucking
George Michaelson
John Haller
o Block mode terminals
Steve Bellovin
o Info on RISKS (comp.risks)

"Drive-by-light" automobile to be demonstrated

Jon Jacky <>
Wed, 06 Apr 88 21:45:51 PDT
The following article about a "drive-by-light" automobile appeared in the 
column OPTONET: INDUSTRY BRIEFS in the newspaper OE REPORTS, April 1988, 
p 16.  OE REPORTS is a publication of SPIE (Society of Photo-Instrumentation

"A fibre-optic LAN-controlled automobile will be demonstrated this month at the
Hanover Trade Fair. ... The automobile uses polymer optical fibre (POF)
components and systems.  In the fibre-optic automobile, everything from
headlamps to electronic trunk locks will be controlled by a few meters of POF
and networking techniques."

(There was a diagram of the car showing modules labelled only "module 1" etc.
with lines connecting them up.  There were a lot of modules in the passenger
compartment and dashboard and one under the middle of the hood, but none
in the wheel wells.  I get the impression this is actually supposed to be
more of a trade-show attention-getter than an attempt to develop a practical
way to build a car.)
                              - Jonathan Jacky, University of Washington

Air Force replacing flight training with simulation

Jon Jacky <>
Wed, 06 Apr 88 21:31:34 PDT
The following report appears in ELECTRONICS, March 3 1988, in the 
MILITARY/AEROSPACE NEWSLETTER column.  No author is named:


The Air Force is cutting in half the number of aircraft used for training and
relying more heavily on simulators to train fighter pilots and gunners.  "It
used to be that 25% of all our aircraft were for training, but now we're going
to 12.5%," says (an Air Force spokesperson). ... The $30 million system (to
simulate the F-15E trainer) which includes five mainframe computers and 25
video displays, will get a real workout: the Air Force expects eight flight
crews to work two-hour shifts on the simulator every day."

- Jonathan Jacky, University of Washington

Cockpit Automation Risks (Re: RISKS-6.50)

Alan M. Marcum <>
7 Apr 88 23:42:54 GMT
In RISKS DIGEST 6.50, (Jon Jacky) related stories
from the NY Times regarding cockpit automation risks.  Two of these, in my
opinion, are more the result of poor procedures than the result of cockpit

The China Airlines 747 incident (where the crew lost control of a 747 after
losing an engine) was really caused by the captain failing to follow
established Boeing procedures for handling loss of one engine.  Proper
procedures stipulate that the autopilot should be disengaged upon failure of
one engine during cruise; the captain left the autopilot engaged, leading to
the results described in Mr. Jacky's message.  (Incidentally, loss of one
engine while enroute in a 747 is NOT considered an emergency.)

The Eastern Airlines L-1011 crash in the Everglades was a direct result of the
flight crew's neglecting their primary job: flying the airplane.  It was not so
much a matter of an inadvertent disengagement of the autopilot as it was the
flight crew's failure to perform their primary duty that caused the accident.

(The Eastern L-1011 has become a classic case study in aviation circles.  A
re-enactment of the accident, in a simulator using text from the transcript
of the cockpit voice recorder, was video taped a few years ago.  The video
tape is used by numerous airlines in their crew training.  The tape was also
shown as part of a _Nova_ episode entitled, "Why Planes Crash."  That
re-enactment is, simply, the most frightening thing I have ever seen.

Alan M. Marcum              Sun Microsystems, Technical Consulting
marcum@nescorna.Sun.COM         Mountain View, California

Ada and exploding missiles

Jon Jacky <>
Wed, 06 Apr 88 21:21:30 PDT
> In RISKS 6(36), Jerry Harper asks:
> (Is it true that missiles were recently destroyed on launch that had
> their guidance systems coded in Ada?

I very much doubt it.  I researched the Ada story quite thoroughly about two 
years ago for an article I was writing.  At that time, almost no software
about to be fielded in weapons was being coded in Ada, despite DoD
requirements.  The reason was that compilers then available either did not
produce code at all, or did not produce sufficiently high-performance code,
for the small processors used in missiles and other weapons.  I have been
following the story since then and things appear to have improved a little
but there is still a problem, moreover lead times are quite long.  So I
doubt Ada could have been at fault.

I have not heard of any recent missile losses caused by software faults.
In fact the only case I know of was the very famous loss of Mariner I in
1962, which has been discussed at length in RISKS.  (I notice that a company
called Northwest Instrument Systems, Inc. of Beaverton, Oregon has been 
advertising an embedded code debugger with full page ads featuring a photo
of a missile exploding a short distance from a launcher, captioned "The
ultimate bug."  The ad has appeared in ELECTRONICS and ELECTRONIC ENGINEERING
TIMES.  I presume that a certain amount of license has been taken, in that
the pictured incident is not to be literally attributed to a software 

> Didn't some famous computer scientist express grave reservations about Ada?

Yes.  C.A.R. Hoare of Oxford used the occasion of his Turing Award lecture
in 1980 to say:

"I appeal to you, representatives of the programming profession of the United
States, and citizens concerned with the welfare and safety of your own country
and of mankind:  Do not allow this language in its present state to be used in
applications where reliability is critical, i.e., nuclear power stations,
cruise missiles, early warning systems, anti-ballistic missile systems.  The
next rocket to go astray as a result of a programming language error may not
be an exploratory space rocket on a harmless trip to Venus: It may be a
nuclear warhead exploding over one of our own cities.  An unreliable
programming language generating unreliable programs constitutes a far greater
risk to our environment and to our society than unsafe cars, toxic pesticides,
or accidents at nuclear power stations.  Be vigilant to reduce that risk, not
to increase it."

C.A.R. Hoare, "The emperor's old clothes," COMMUNICATIONS OF THE ACM, 24(2),
Feb. 1981, pps. 75 - 83.  Also reprinted _The Ada Programming Language: A
Tutorial_, ed. by Sabina H. Saib and Robert E. Fritz, New York, IEEE, 
1983, 487 - 495.  No doubt also reprinted in the book, ACM Turing Award 
Lectures: The First Twenty Years: 1966 - 1985, ACM Press/Addison Wesley 1987.

> Is the Pentagon insisting on the use of Ada for all military software?

Not exactly all.  Defense Directive 3405.2, March 30 1987, orders the use
of Ada in all new weapons systems.  The DoD also buys a lot of software that
is not used for weapons control.  A similar directive issued in 1983 ordered
the use of Ada in all "mission-critical" systems after January 1, 1984, and
was almost totally ineffective.  Contractors found that the compilers then
available were unsuitable, and petitioned DoD for waivers, which
they received.  DoD's position is that the compiler technology is now much
more mature, and waivers will be quite difficult to get.

- Jonathan Jacky, University of Washington

Bank money machines

Wed, 6 Apr 88 12:20 EDT
Several months ago, I was making a $20 cash withdrawal from my bank's
automated teller machine. While waiting for my money to come out, the CRT
went blank; several seconds later, a message saying "Please Wait" appeared.
I theorized that the machine was being reloaded with money - just a guess.

After 15-20 seconds, the screen cleared and put up the normal "Welcome to
First National Bank Teller/24" message. No money. No card. No receipt.

Being the kind of person who likes to figure out how/why things work, needing
the money so I could eat dinner, and having the good fortune of being with my
wife, I borrowed her card to see if the machine would do the same thing again.

The strange sequence of events did not recur, and everything proceeded
normally. When the money/receipt door opened, however, I received TWO $20
bills; one that I expected, and the other from the previous (failed)

I found out later that a momentary power failure had blacked out a large part
of the city, including my bank branch, just after my $20 was ejected into the
cash drawer and just before the machine returned my card and opened the door.

Had I been un-curious, well-fed, and alone, or had the power failure been
longer in duration than my patience, I would have shrugged my shoulders and
walked away after the failed transaction, and the next guy would have gotten
my $20 (and a bit of trouble, had he/she not been honest about it). I suppose
that everything would have gotten straightened out eventually...

I was going to suggest to the bank that they change the sequencing of
events to handle this possibility a little better when they replaced the
locking money doors with they're-always-unlocked-lift-em-yourself type.

I still wonder, though, if there are some other hitches where such a power
failure could mean trouble for a system handling cash.

A humorous, true, but perhaps not as RISKy story:

A local bank uses full-sized "play-money" to train employees to load
the teller machines with cash. At one branch, the practice money was
inadvertently left in the machine. Customers were quick to point out
this oversight to the branch personnel.

The first person to receive the bogus cash, though, did not immediately
notify the bank. By chance, this person was the next-door neighbor of
the bank's CEO. After laughing it off with the CEO, the neighbor went
back to the branch the next day and made his monthly mortgage payment,
in "cash", to the bank.

Rick McTeague, Electrical Engineering Department, Speed Scientific School
University of Louisville, Louisville, KY  40292

Re: On UnTimely RISKS (RISKs of political consideration)

Eugene Miya <>
Wed, 06 Apr 88 11:10:46 PDT
From: (Paul Cudney)
  >Before the beginning of computing was time, and with time was change.  You
  >might think we would all be familiar enough with calendar time to cope with
  >it easily, even to the point of designing systems to accommodate both the
  >predictable and the politically inevitable.

Is it the fault of computers when the political definition of what "Time"
is changes?  The collection of political lobbying groups included those
industries involved in outdoor barbeques (large part) as well as a society
to help those with night blindness.  The legal definition of Daylight Savings
Time has changed more in the past 15 years than all prior years.

How many people were aware of the change of the laws regarding daylight
savings?  I'm not condeming the change, I think however, we rely heavily
upon media watchers.  Some of these loobying groups, BTW, are still trying
to change the definition of Daylight Saving Time in the fall to include two
more weeks.  So I hope you guys get your software changed before then.

Perhaps, we should compromise and average the 1/2 hour.....;-)

Also, the article on the Cray Shinto blessing was a Cray Press release and
will probably be published in Cray Channels.  This isn't anything special
(in Japan).  See "The Faces of Japan" hosted by Dick Cavett.

--eugene miya,   NASA Ames

How Computers Get Your (Clarified) Goat!

Wed, 06 Apr 88 09:19:27 EST
The New York Times article reported by PGN on April 2 unfortunately has a
minor error of fact. The study referred to, which is incidentally in the
current issue of the Communications of the ACM, used the MUSIC/SP editor.
The author of the article apparently assumed that this was some sort of PC.
However, MUSIC/SP is an operating system that runs on IBM mainframes. (It is
developed by McGill and marketed by IBM.)

Philosophy and discrimination

Thu, 7 Apr 88 12:43 EST
David Thomasson's complaints of philosophical shoddiness in some recent
RISKS pieces on discrimination seem off the mark to me, perhaps owing to
the concerns of *my* field (literary criticism).  In all the instances I
recall, and particularly Les Earnest's, nobody was talking about the
question of what the ideal Motor Vehicle Bureau should ask you on their
application.  Les Earnest's was a *story* that told of becoming uneasy
about certain classifications in the light of substantial evidence of
their misuse.  Thomasson would have us ignore how information is used in
society, and once you do that then of course a discrimination's bad
effects will often disappear from view; you can pretend that a Southern
state, in the early 60s, would ask about your race merely because it's
useful for identification. Just because they can cite good reasons
doesn't mean their real reasons aren't bad.

I don't say that it's useless to discuss these questions without relating them
to real life.  But surely one theme of the RISKS list is that something which
looks fine in the lab can become quite different out in the field.

John Lavagnino, Department of English and American Literature, Brandeis Univ.

Comment on "Diving Risks"

Phil Pfeiffer <>
Tue, 5 Apr 88 15:59:16 CDT
> Date: Wed, 30 Mar 88 10:12 CST
> From: Joel Kirsh <KIRSH@NUACC.ACNS.NWU.Edu>
> The user interface on the new diving computers is certainly critical, ...

Since the people at the shop where I buy my gear are not experts on
decompression theory, they were understandably reluctant to make specific
comments on this article, and did not want their names used.  But, it is their
understanding that many top-name manufacturers *are* using the new, improved,
safer data as the basis for their computerized decompression meters.  Since
this is comp.risks, and not rec.scuba, I don't think the subject to be worth
an "in-depth" treatment, but I would suggest that anyone concerned about
buying a particular manufacturer's meter simply give the manufacturer a call
and ask what tables are being used.  One thing worth saying is that a number
of different systems have been devised over the past fifteen years for
reducing the expected incidence of DCS to more acceptable levels than had been
observed with the old USN tables.

-- Phil Pfeiffer, (608) 262-6625

Re: The risks of rumours

Tue, 5 Apr 88 12:59:47 EDT
> A colleague told me the other day that he'd heard that the Australian
> Federal Police were going through the various Universities, armed with
> a search warrant, looking for pirated software on PC hard disks...

A similar rumor has been making the rounds of the Ontario universities
lately.  It too appears to have been without foundation in fact, but it
did make a lot of people nervous for a little while.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

    University of Manitoba   Winnipeg 

    ("The R.C.M.P. have raided several eastern universities in search of
    pirated software ") The rumors have proven to be just that, rumors, with
    no basis in fact.  There are rumors that people were scrambling to remove
    software and equipment in advance of the impending "raids".

        [Sounds a little like April Fool's leftovers.  PGN]

Re: High Tech Trucking

George michaelson <munnari!!george@uunet.UU.NET>
4 Apr 88 23:01:15 GMT
in article <12386323646.17.NEUMANN@KL.SRI.COM>, mcvax!geocub!anthes@uunet.UU.NET (Franklin Anthes) says:
>  Over here in France a black-box system has existed for quite a while now.
> It isn't a computer, and its output goes to a paper disk, so it probably
> can be tampered with.

The Tachometer is used all over Europe, I assume because of an EC (euopean
community) law which each member state then ratified.

In the UK where laws have been passed restricting the number of hours 
of continuous driving AND the total in any 24 hr period, Inspectors 
(and police) can ask to see the disk, and the device (according to truck 
drivers I've hitched with) is frequently cited in accident/insurance claims.

This implies it's speed/time/distance logging is accurate enough to satisfy
the legal process, If a tacho says your exceeded the speed limit and it's 
working OK you can be had up for it.

Also fitted to public transport vehicles. Not just Long distance Trucks 
but also small haulage vans must be so fitted.

PS the output is displayed on the Drivers dashboard so (s)he can decide
how to spread the working hours over the day, or pull over if a time limit
is exceeded. I always thought a 'black box' was a passive data capture unit
sealed away out of sight. 

-someone in the UK can comment on how it's changed accident statistics since
being introduced. At the time there were the usual -public-freedoms-are
-being-assaulted claims mostly be haulage bosses who had to spend cash
retro-fitting the things into wagons. 

surely the simpler the o/p device (eg direct to paper) the happier one
is with the result? OK there are limiting factors of complexity at play
here, but in the context of COMPUTER failure I'd rather have a chart
logger there any day!

    George Michaelson

55 Barry St, Carlton, Vic 3053, Phone:  (03) 347 8644           

Re: High Tech Trucking (RISKS-6.51)

Tue, 5 Apr 88 09:04:17 PDT
A friend of mine used to be a trucker.  The solution used to avoid recording
of excessive travel and speeds was to pull the fuse powering the device.  I
doubt that a tamperproof device has yet been made.
                                                          John Haller

Block mode terminals

Wed, 6 Apr 88 11:18:25 EDT
Many HP terminals have block mode, in assorted variant forms.  I was mildly
bitten by one such terminal last week.  On this one (a 2621), one can
enable block mode, in which case the terminal doesn't send any data
to the machine until you hit RETURN.  When you do, it moves the cursor
to the beginning of the line, then moves it along the line as it sends
each character, finally sending (and executing) a RETURN at the end of
the line.  Furthermore, the terminal is smart enough that it knows where
you started typing on the line; hence a prompt won't be transmitted back
to the machine.  The intended purpose of this whole feature is to allow
local editing (i.e., insert/delete character), even on machines that don't
have any software support for it.  I don't recall if the 2621 allows the
host to initiate transmission, but some other HP terminals (such as the
2645) definitely do.

What was the glitch?  Well, unknown to me, the terminal was in block mode.
Because it's smart enough to cope with the host echoing characters (this
was a UNIX(r) system), I never noticed it.  Then I had to enter a password;
to my great surprise, the password was being displayed as I typed it...

Steve Bellovin          ulyssesf!smb

Please report problems with the web pages to the maintainer