RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (04/22/88)
RISKS-LIST: RISKS-FORUM Digest Thursday 21 April 1988 Volume 6 : Issue 66
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Risk of parolee database that is out of date (Robert White)
Lap-Tops, etc. in final exams -- a common-mode fault (Andrew Duane)
Airline Risks (David R. Hampton)
Another ATM story (Dave Fiske)
More on HP benchmark story: how it might have been avoided (Tom Lane)
Mongrelism 1: Fuzzy concepts lead to fuzzy decisions (Les Earnest)
Mongrelism 2: Genetic Classification and the Urge to Merge (Les Earnest)
Risks of RISKS -- textual tampering (Doug Claar)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
For Vol i issue j, ftp kl.sri.com, get stripe:<risks>risks-i.j ... .
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).
----------------------------------------------------------------------
Date: 19 Apr 88 16:31:43 MDT (Tue)
From: ncar!scicom!qetzal!rcw@rutgers.edu
Subject: Risk of parolee database that is out of date
The failure of the Colorado Department of Corrections to keep an on-line
listing of parolees up to date on the Colorado Bureau of Information computer
system is a very real threat to the safety of the public. Law enforcement
agencies access this list when arrests are made or when giving traffic
citations.
The threat is real, and I have first hand experience with it. My brother was
murdered in January, 1986 in the early evening at a grocery store where he was
working. The previous day, the perpetrator was stopped for a routine traffic
violation. The CBI computer did not reveal his parolee status at that time,
nor did it reveal that he was wanted on charges of shoplifting, assault, and
armed robbery in other counties of the state.
The officer suspected something was awry, but was powerless to do anything for
want of probable cause. The officer even went so far as to call the Department
of Corrections. My brother was dead two days before the clerk finally returned
his call.
It turns out that the state is approximately six months behind in their data
entry tasks, and have been so for at least the past five years. It strikes me
that such a database is next to useless, and is an example of a project that is
better funded properly or funded not at all.
Robert White ihnp4!upba!qetzal!rcw
------------------------------
Date: Tue, 19 Apr 88 14:18:33 edt
From: decvax!cg-atla!duane@ucbvax.Berkeley.EDU (Andrew Duane X5993)
Subject: Lap-Tops, etc. in final exams -- a common-mode fault
Back in High School (1975 to be exact), calculators were not too common, and
PROGRAMMABLE ones almost non-existant. Nonetheless, there was one student in my
Advanced Chemistry class that owned an HP-35 programmable. The teacher finally
decided to let us share it during the exam. We quickly adopted the following
strategy: the first student would work out the solution to the first problem,
storing all relevant intermediate results in the memories. He or she would pass
it to the next student, who would copy the results, and tackle the next
problem. Additionally, several "important" formulas had been preloaded onto
certain entry points. After two rounds about the room, we had finished all the
problems. Our downfall: a common one to RISKS readers. Someone had made a
rather stupid mistake on a problem, and we all had copied it!
Andrew L. Duane (JOT-7) w:(617)-658-5600 X5993 h:(603)-434-7934
Compugraphic Corp., 200 Ballardvale St., Wilmington, Mass. 01887
------------------------------
Date: Wed, 20 Apr 88 07:42 EDT
From: "David R. Hampton" <Hampton@DOCKMASTER.ARPA>
Subject: Airline Risks
The following article is taken from the Huntington, WV Herald Dispatch
from Friday April 15th, 1988. It is, as always, reprinted without permission.
BLAST RIPS JET IN MIDAIR, BUT IT LANDS SAFELY
By Kelly P. Kissel, Associated Press
CHARLESTON- An engine on a Piedmont airlines jet exploded Thursday, sending
debris tearing through the walls. The pilot wrestled the craft under control
and made an emergency landing in Charleston. A passenger said there was a
hole "big enough that I could crawl through it." The explosion caused the
Fokker F-28 jet, which was flying at 31,000 feet, to lose pressure. Some
oxygen masks didn't work, two passengers said. Two stewardesses suffered
minor injuries when the plane plunged after the explosion, officials said.
Flight 486, which carried 56 passengers and a crew of four, was flying from
Charlotte, N.C., to Columbus, Ohio, when it's right jet turbine disintegrated
about 9:45 a.m., Piedmont officials said. [...]
Turbine blades and engine parts ripped all the way through the plane,
leaving holes on both sides. A hole on the right side, next to the
engine that disintegrated, was 2 feet wide and 6 feet high. On the
opposite side, the hole was 2 feet by 1 foot. [...]
The Piedmont spokesman said he didn't know when the engines had been checked
last but said there was no reason to suspect a problem. "Our engines are
maintained by computer. If there's a problem incipient in them it would show
up," McGuire [the spokesman] said. "That's why we were suprised." He said
the rest of the plane, including the oxygen masks, is checked in the same
manner and that complaints about some inoperable masks would be investigated.
------------------------------
Date: Tue, 19 Apr 88 16:08:45 est
From: davef@brspyr1.brs.com (Dave Fiske)
Subject: Another ATM story
Here's an interesting ATM problem I once encountered. I don't think
I've seen anyone else mention this one.
Once, when trying to make a withdrawal, the machine proceeded normally,
until it got to the part where the lid to the money-dispensing bin is
supposed to open. It didn't and wouldn't. Because my transaction had
seemed to take place, I called the bank the next morning to make sure
the withdrawal hadn't beed debited from my account. The person I spoke
to checked, and said everything was okay with my account, and explained
that what caused the problem was that, prior to my attempted
transaction, someone must have forgotten to take their money from the
bin. Apparently the system is programmed to lock up the bin, obviously
to keep anyone else from taking the cash, but it seemingly performs all
transactions properly.
This is somewhat interesting, since apparently the system designers had
anticipated the possibility that someone might forget to take their
money (a situation which strikes me as so absurd that I probably would
have overlooked it), but chose a rather confusing response for it.
Confusing in that all legitimate users following the flawed transaction are
uncertain what happened and whether or not their transactions were
completed or not, and therefore undoubtedly generating a number of
calls to the bank. It's not enough to anticipate a situation--the
appropriateness of the response, given human nature and expectations,
is important, too.
Dave Fiske (davef@brspyr1), BRS Information Technologies, Latham, NY
------------------------------
Date: Wed, 20 Apr 88 09:05:45 EDT
From: Tom.Lane@ZOG.CS.CMU.EDU
Subject: More on HP benchmark story: how it might have been avoided
In RISKS 6.58, I told a story about how failure tolerance kept some HP
salespeople from noticing that the floating point coprocessor in a demo
machine was dead; this led to some very embarrassing benchmark results for a
potential customer. Here's some additional info that might be of interest.
Jeffrey R Kell (<JEFF@UTCVM.bitnet>) wrote me:
>I'm not sure of what system the benchmark was on, but on the newer RISC-based
>machines the operating system checks to see if a coprocessor is "present"
>or not; I suppose a "broken" one might appear "absent" as well.
Yes, that's also true on the older HP Series 300 machines that I'm familiar
with. Those machines are "self-configuring", which means that at powerup
the boot ROM runs around and finds how much memory is plugged in, what
interface cards and coprocessors are present, etc; then it tests them all.
The boot ROM displays a list of the selftest results, and things that have
been detected but fail the selftest are prominently marked. If something is
sufficiently broken that the boot ROM doesn't even see it, the only
notification you get is that it doesn't show up in the selftest list.
The list isn't there long since the ROM then proceeds to load an operating
system. If you aren't paying attention when you turn the machine on (which
most people aren't...) you lose. Presumably this is what happened to the HP
salespeople above.
Some of the even earlier Series 200 machines had a provision for dealing
with that problem too. The 200s had a small PROM which was custom-burned
for each machine, containing the computer serial number. There was also
provision for the PROM to contain a list of attached equipment; the boot ROM
could then check to make sure that it had found everything that was supposed
to be there. Unfortunately HP decided that the custom PROMs added too much
to manufacturing cost. (I believe, though, that the necessary code is still
in the Series 300 boot ROM; so a determined person could program his own
PROM, put it on a breadboard interface card, and plug it in.)
The PROM was also treated as a piece of optional equipment, so if it died
the machine would still boot, but you would lose this protection...
I don't know whether any such provisions exist in the newer Series 800
machines, which were the culprits in my original tale.
tom lane
UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl
BITNET: tgl%zog.cs.cmu.edu@cmuccvma
------------------------------
Date: 17 Apr 88 1907 PDT
From: Les Earnest <LES@SAIL.Stanford.EDU>
Subject: Mongrelism 1: Fuzzy concepts lead to fuzzy decisions
Some people found the mongrel stories amusing, some found them educational,
and at least one person found them disturbing, apparently because they
made fun of deeply held beliefs. So be it.
I regret to report that I have three more things to say on this topic [here
and following]. I really do hope that we can put this to bed soon. In
fact, if the discussion continues unabated I will shortly propose the
formation of newsgroup comp.race to discuss the computational aspects of
race determination. I offer here a preview by showing the current
theoretical basis for the field, which can be stated in a single line:
.
I particularly enjoyed reading the insightful remarks of John Mainwaring
in comp.risks 6:60 and the educational humor of Will Martin in 6:61.
In comp.risks 6:61, David Thomasson says:
> "Apparently believes...probably believes" -- more Straw Men. In fact, I
> believe that virtually everyone can be put into some racial category that is
^^^^^^^^^
> very useful for purposes of identification, even though such categories are
> not biologically precise. As for the rest of the above, Earnest's argument
> has gone to the dogs.
This is cute, but very evasive. Thomasson neglects to identify the exceptions
to "virtually?"
In the same article, Thomasson later remarks:
> In my experience, "race" has been roughly equivalent to "color of
> skin" in police work. So, while it's true that "race" is biologically
> imprecise (even incorrect), those who use race for identification purposes
> aren't concerned about biology . . .
Here he finally comes to grips with reality. We are left to wonder why
the police don't use skin color for identification, given that they don't
understand biology.
"Black" and "White" are Relative
Nearly all of the people in the U.S. who call themselves Black are
genetic mixtures of African and European peoples. Because our culture
is predominently European, anyone who has detectably African features is
called "Black," even if they are genetically, say, 7/8 European. If we were
a predominently African country, these same people would likely be called
"White" because they have detectably European features. In other words,
current racial classifications are made relative to the "norm," which
makes them intrinsically subjective and rather unreliable.
However, it will shortly be possible to make unambiguous racial classifications
as discussed in the next posting.
Les Earnest
------------------------------
Date: 18 Apr 88 0217 PDT
From: Les Earnest <LES@SAIL.Stanford.EDU>
Subject: Mongrelism 2: Genetic Classification and the Urge to Merge
Given that the human genetic code is now in the process of being unravelled,
it should soon be possible to classify people into racial groups in a
meaningful way. One way to do this, once we can reliably disassemble the
code for any given person, is to define various racial standards in terms of
this code, such as a standard Negro, a standard Caucasian, a standard
Chinese, etc. Of course, some people will want to carry this a step further
and define a standard Texan or even a standard South Philadelphian.
Once we choose a set of standards, then everyone can be classified as being
members of the racial group whose standard is closest to their own genetic
code. The Hamming Distance between pairs of codes would be a reasonably
good measure of genetic distance. That is, given that genetic codes are
base 4, we could simply count the number of differences in the base 4 code
string.
Thus, after we get over the argument over which are the standard races, it
should be possible to assign everyone unequivocally to a racial group,
except for the rare individuals who happen to be _exactly_ halfway between
the two closest standards.
While this wonder of future science will support nearly unequivocal racial
classifications, it clearly will not be useful for visual identification.
In fact, I can't think of anything that it _would_ be good for, other than
providing a formalized basis for bigotry. For purposes of individual
identification, the person's full genetic code will be far more useful.
The Urge to Merge
Whether or not we solve the problem of racial discrimination and conflict
through education and political action, human biology will probably solve it
for us in the long run. Recent studies indicate that if there are no more
major influxes of foreign populations into the U.S., distinguishable racial
groups will essentially disappear in this country within 300 years because
of "the urge to merge." In other words, the U.S. is destined to become a
nation of mongrels.
This likely will be disappointing to white supremicists and black activists,
who will _both_ soon be members of shrinking minorities. In fact, they may
be already. I predict that new rallying cries will be heard as the mongrels
become the majority -- maybe things like "Beige is Beautiful."
Les Earnest
P.S. With respect to the "urge to merge," I can report that my family is
doing its share. One of my sons, Mark, lives in Alaska and is married to
a Yupick Eskimo lady named Cathy Lincoln. (She also has a Yupick name
that sounds something like attempting to clear your sinus while spitting
out an ingested bee.)
Mark is generally well received in Eskimo communities, though he
occasionally encounters some prejudice. They call him a "gussack" which
has about the same meaning there as "gringo" does further South.
"Gussack" is a Yupick word that was derived about two centuries ago from
the Russian word "cossack." You can imagine how that came about.
Mark and Cathy have three beautiful little mongrels, who can look forward
to participating in the (hopefully) peaceful overthrow of the WASP
group that has run this country for the last 400 years.
------------------------------
Date: Tue, 19 Apr 88 13:52:49 pdt
From: Doug Claar <dclaar%hpda@hplabs.HP.COM>
Subject: risks of RISKS -- textual tampering [de-ment-ia praecox]
In our copy of RISKS DIGEST 6.60, occurrences of "ments" have been replaced
with "<newline><newline>w". Several examples have been captured below. Makes
interesting reading!
[I have edited together from 4 messages from Doug. PGN]
-------
Re: Discrimination and careless argu
ws!es Earnest)
-------
Quebecers should know that government depart
w and agencies have millions
-------
The databanks, half of which are computerized, are held by 26 depart
w and
-------
Interim chairman Therese Giroux said these depart
w may face legal action if
-------
helmet to an electronic device that monitors his eye move
w. Presuhn, 33,
-------
The editing 'improvement' changes midway through the article on Pilotless
combat planes to replacing "ment" with "<newline>ent" once, and then slips
back in towards the end of the digest!
I wonder, does your copy have the little #! rnews 682 on the end? This might
be a clue as to who de-ment-ed our copy... [NO, NOT MINE! P.]
Doug Claar, HP Information Software Division
UUCP: { ihnp4 | mcvax!decvax }!hplabs!hpda!dclaar -or- ucbvax!hpda!dclaar
ARPA: dclaar%hpda@hplabs.HP.COM
[Anyone want to take the blame for this "ment"al lapse?
No one else has reported it yet. Could Doug's terminal
have been Trojan horsed? Could have been serious.
Your deportment might have gotten you deported. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------