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

Monday 25 September 1989

Contents

o Computerized fingerprint system has human failure
Dave Suess
o Computerized translation strikes again
Joe Morris
o Loose wires
Desmond Andigo via John Leonard
o Software *IS* an abstraction
Bob Estell
o Yes, the power grid IS getting less reliable
Bruce Hamilton
o Computers, Planning, and Common Sense
Richard O'Keefe
o Simulated aircraft emergencies
John Mackin
o Re: Software Accreditation
Richard Threadgill
o Info on RISKS (comp.risks)

Computerized fingerprint system has human failure

Dave Suess (CSL) <zeus@aerospace.aero.org>
Mon, 25 Sep 89 07:37:34 -0700
(From the Easy Reader, a weekly newspaper in the South Bay section of L.A.)

A Redondo Beach resident, Martin Lee Dement, spent almost two years in a Los
Angeles County jail because of a botched use of the state's computerized
fingerprint-matching system, ALPS (Automated Latent Print System).  Arrested
for robbing a Radio Shack, Dement was jailed, his girlfriend sold her condo to
raise money for defense lawyers, and the experience may have contributed to his
recidivism (he had been an habitual offender, and speculation is that the 21
months he spent incarcerated wiped out the progress he had been making since
his last release).

There was much thrashing by two consecutive public defenders and finally
attorney Charles Maple (who defended Onion Field killer Gregory Powell) to get
the D.A. or police departments involved to match prints lifted at the scene of
the robbery with those of another suspect, Dennis Passon, also arrested about
the same time, for a string of similar robberies (including a Radio Shack
store).  None of the law enforcement officials would make a direct comparison
between the lifted prints and those of Passon, even though they had him in
custody.  Instead, the lifted prints were sent through ALPS --- and no match
was produced.

Finally, two weeks into Dement's trial, the prints were produced and the judge
ordered a comparison to be made with those of Passon.  A match was immediately
obvious, and charges against Dement were dropped, after he had spent 21 months
in jail.  The D.A., Julie Sulman, blamed ALPS, which had just come online.
Investigators had just assumed that since Passon had an extensive criminal
record that his prints would be online, also.  Sulman said, "I think we made an
erroneous assumption that Passon wasn't the guy because he would have been in
ALPS ... and we were wrong."

Attorney Maple said recently that "ALPS is bull**** and it doesn't take care of
anything."

                   [Censorship **** is mine.  This is a family newsgroup.  PGN]


Computerized translation strikes again

jcmorris@mitre.arpa <Joe Morris>
Sat, 23 Sep 89 18:59:24 EDT
[From page R6 of the _Wall_Street_Journal_, Friday, 22 September 1989 comes yet
another story of the perils of computerized translation of natural languages.
The text below appeared in a sidebar to a story about the problems encountered
in trying to resolve differences between European countries preparing for the
1992 amalgamation into the EC...]

                            TOWERING BABBLE
      Automatic translation system proves that to err isn't just human

Interpretation and translation gobble up a huge hunk of EC's central budget, so
the Eurocrats have been trying to save money by using an automatic translation
system.  Systran is its name.  Bloopers are its game.

To the unconcealed delight of those whose jobs it first appeared to threaten,
Systran, acquired from the U.S. Navy about 10 years ago, still has a bit to
learn about French-English translation.  A few howlers:

* Commission President Jacques Delors asked in French whether he could address
  a certain committee.  Systran had him asking whether he could "expose
  himself to the committee."

* Crown Prince Jean of Luxembourg, invited to offer a royal page of prose
  to the computer, used the words _nous_avions_, which in context only
  meant "we had."  Systran made it "us airplanes."

* In one screed about farming, the writer used the phrase _les agriculteurs_
  _vis_a_vis_de_la_politique_agricole_commune_, which means "farmers, in
  the light of common agricultural policy..."  Systran, suffering either
  a blown microprocessor or an uncanny flash of insight, rendered it as
  "farmers live to screw the common agricultural policy."

[The article goes on for another nine column inches discussing non-computer
related problems of translation, which are significant.  In the headquarters
of the Council of Ministers there are about 2000 bureaucrats, half of whom
are translators.]


loose wires

John Leonard <john@robots.oxford.ac.uk>
Mon, 25 Sep 89 19:58:26 BST
A friend of mine regularly reads RISKS which I print out for him (He is not on
a network.)  He has asked me to pass on the following message which he typed in
on his pc and downloaded onto our system.

DISCLAIMER: I would like to point out that no members of this group have any
connection with the author or his story, except as a friend.

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

Having read with interest the articles in RISKS 9.26 and 9.27 about
loose wires, I thought I would readers might like to share my own
story of a similar incidence.

Some years ago, I was exploring in Africa hoping to trace a long-lost relative;
when due to a peculiar set of events I found myself in a great deal of trouble.
I was part of a team of explorers: all of us searching for our own and the
other team-members relatives.

We each had a portable radio and could be contacted by another team-member who
was stationed at "base camp".  Anyone who discovered anything interesting was
supposed to radio the base camp, the news being relayed to the rest of the team
when they contacted base camp.

The radio I had was supposed to be what was then a very modern design
incorporating a primitive computer which was supposed to switch in the full
power when a signal was received, conserving energy while no information
transfer was occurring.  Unfortunately, after a couple of weeks, when the
novelty of using the radio to call up for regular status reports had worn off,
one of the wires on the radio worked itself loose and as a result, while I was
capable of radioing base camp, they could not contact me as the power was not
sufficient to raise me without the computer working properly.

I did not call base camp for several days/weeks (I forget how long it was).
Imagine my surprise when I did get to call, however, and discovered the
following:

While I had continued my search, the other members of the team had returned to
camp, some successful, but in the main unsuccessful.  I was the only one left
searching and the team leader decided to call me back. Unfortunately, my radio
did not respond and so, fearing the worst, the remainder of the team set out to
find me.  By the time I next called the camp, the whole team was searching for
me, searching the many miles of land in which I could possibly be.

During their search, one of the team members (a chap called Maurice [I don't
remember the surname]) was bitten in his sleep by a sloth (he alone in the
team thought he was safer sleeping in a tree) and had to spend several weeks in
hospital on our return.

Although we laughed about the whole affair afterwards, it did make us realize
how dependent on the technology we were.  Since then I have been understandably
wary of computers (though I do now own a small wordprocessor) ... and have
taken a keen interest in discussion groups which talk about the potential
problems of computers.

Desmond Andigo (Retired Businessman)


Software *IS* an abstraction

"FIDLER::ESTELL" <estell%fidler.decnet@nwc.navy.mil>
25 Sep 89 13:09:00 PDT
How can we study "real software" for verification, among other purposes?
Can we read a listing in some programming language?  Can we read a memory
dump - if that is not a lost art?  Can we monitor execution under control
of an interpreting debugger?

I submit that these and other forms of "studying software" amount to the
study of an abstraction of what really counts; viz. the system.
The software, without a processor to run it, is but an abstraction
of what the programmer wants the system to do; the hardware, without the
software to guide it, is but a potentially versatile idle tool.

The system runs in real time; i.e., as fast as the processor and its
input/output allow.  When one slows that process down to the pace that
a human can observe in detail, subtle timing problems behave differently.

That is not to say that interesting subsets of a system cannot be isolated
into time invariant forms, and then analyzed rather thoroughly.  And that is
very valuable; it has given us better compilers and math libraries, among
other things.  But systems that deal with things that directly affect human
life, like hospital monitors, and flight controllers, run in real time.
Yes, it is far better to build them insofar as possible with parts that are
verified; but the whole remains an abstraction, until we develop other tools
which may depend on our first developing other paradigms.


Yes, the power grid IS getting less reliable

Bruce Hamilton <Hamilton.osbuSouth@Xerox.COM>
24 Sep 89 22:23:46 PDT (Sunday)
Since the reliability of the power system relates directly to the reliability
of many computer systems, the following info is probably of interest.

I spoke with a friend who used to be in charge of building large power projects
for Southern California Edison (SCE).  He said that, due to increasing
competition and decreasing ROI, over the past ten years or so SCE has planned
its power grid to "N-1" standards, whereas previously they planned to "N-2".
"N-1" means they can lose only one major transmission line without a major
system blackout.  He added that even "N-1" is marginal in some cases.

Of course, they DID learn a lot from the big (1964?) blackout in the Northeast,
where the system wasn't smart enough to partion itself in the face of
unexpected overloads, and so the whole system went black and huge generator
bearings melted down and were out of commission for months because the power
plants had no UPS's to pump lubricating oil.

Still, my experience is that most blackouts are small, localized ones due to
things like a car knocking down a transformer.  We seem to suffer three or four
per year here in El Segundo, CA.

In summary: keep buying those UPS's for your data center.

--Bruce     213/333-8075


Subject: Computers, Planning, and Common Sense (Re: RISKS-9.28)

Richard O'Keefe <ok@cs.mu.oz.au>
25 Sep 89 05:20:58 GMT
A Goods and Services Tax has been in operation in New Zealand for several
years now.  The scale was recently lifted from 10% to 12.5%.  Somehow this
is supposed to be compatible with the Labour(!?) commitment to free markets
and reduced government intervention.

As near as I can figure out, if Farmer A trades a pig to Farmer B for Farmer
B's cabbages, they both owe the government 10% (now 12.5%) of the monetary
value of the deal.

The bottom-line tax-payer just loses money, although personal income tax levels
were reduced, so it more or less evened out.  Everyone above that layer pays in
paperwork.  The theory is that each item should have GST paid on it once, so
that GST on inputs can be claimed back from GST on outputs.

> I somehow doubt if the visionary stupidity necessary to develop such a
> proposal to the point of law could have existed unaided by computers.

I don't know what's involved inside the Government, but charladies don't
need spreadsheets to carry out _their_ paperwork.

My objection to GST is that it hits the poor relatively harder than the rich,
but this is apparently compatible with NZ Labour's ideals.


Simulated aircraft emergencies

John Mackin <john@cs.su.oz.AU>
Sun, 24 Sep 89 22:26:44 +1000
In RISKS-9.25, Alan Rosenthal says:

> The trade-offs during practice and emergencies are different, and should be.
> It's sad that this means that you can't really simulate emergencies fully.
> Nevertheless, it's *true* that this means that you can't really simulate
> emergencies fully.

This is quite true.  The whole point that makes this idea unworkable
is that you are putting a multi-million dollar aircraft (and the lives
of its passengers, if passengers are being carried -- and I assume they
would be, as the original proposal mentioned ``routine flight'') at risk,
simply for training purposes.  This is not acceptable.

On the other hand, when they _are_ available, simulated emergencies can be a
very effective tool for pilot training.  I will certainly never forget the
first time I was subjected to one: climbing out from the airport on perhaps my
sixth or seventh flight as a beginning pilot, I reached the altitude at which I
had been taught to conduct after-takeoff checks.  These were quite simple:
speaking aloud, they went: ``Flaps up (pointing at flap indicator), fuel pump
off (turning it off), fuel pressure holding (pointing at fuel pressure gauge),
engine instruments green (pointing at each in turn).''  About ten seconds
later, my instructor said: ``Did you forget something?''  I knew I hadn't, but
I also knew the right thing to do: start the checks again from the beginning.
``Flaps up, fuel pump off (reaching down and pushing the switch off, where it
already was), fuel pressure...''  The fuel pressure gauge was reading zero.
``NO FUEL PRESSURE'', I shouted, practically breaking my hand turning the
auxiliary (electric) fuel pump back on.  I was all ready to push the nose down
when the engine failed, and for a fraction of a second I took my eyes off the
fuel pressure gauge, which wasn't coming up, to look at my instructor.  He was
gazing outside, cool as a cucumber.  I couldn't understand it.  After another
fifteen seconds or so I began to catch on.  The gauge still read zero, but
there was no way the engine was still running with no fuel pressure.  ``OK,
Eric, what did you do?''  He pointed to the circuit-breaker panel, where one of
them was sticking out.  I checked that it was the right one and reset it.  Then
he said to me: ``When you check an instrument, don't just glance at it.  Take a
good look, five seconds at least.  It's not just the instantaneous reading you
want to see: there may be a visible rate of change, and if so, you want to know
about it.''

It certainly drove the point home, and I always follow that practice.
But you can't do that to the pilot of a B747 en route.
                                                                John.


Re: Software Accreditation

Richard Threadgill <richardt@mica.berkeley.edu>
Fri, 15 Sep 89 20:25:14 PDT
I would point to the vast abuses in the medical, legal, and teaching
professions as reasons why some form of accreditation *should not* be created.
The legal process has been codified to such a degree that the only way to
challenge the legal profession is to convince a lawyer to blacklist another
lawyer; the medical and teaching professions have both had vendettas with
professionals who were not politically correct, while allowing *many* abuses to
go unchecked.

We come down to a very simple problem if we wish to teach ethics at all:

  Whose ethics do we teach?

Meanwhile, of course, we are ignoring one very simple fact: Data Theft and
industrial espionage and security are all higly lucrative fields... and they
are becoming more so.  With many of the wealthiest companies in this country
resorting to highly illegal tactics on a regular basis, can we realistically
think that we will stem the tide by saying "nice programmers don't do that?"
Especially when these are *still* some of our most talented people!

RichardT

Please report problems with the web pages to the maintainer

Top