8-Jul-87 00:00:01-PDT,14439;000000000000
Return-Path: <NEUMANN@f4.csl.sri.com>
Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Tue 7 Jul 87 23:53:44-PDT
Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16)
id AA01159 for RISKS-LIST@f4.csl.sri.com; Tue, 7 Jul 87 23:45:06 PDT
Message-Id: <8707080645.AA01159@csl.csl.sri.com>
Date: Tue 7 Jul 87 23:52:15-PDT
From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: RISKS DIGEST 5.8
Sender: NEUMANN@csl.sri.com
To: RISKS-LIST@csl.sri.com
RISKS-LIST: RISKS-FORUM Digest Tuesday, 7 July 1987 Volume 5 : Issue 8
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Erasing Ford (and other) car computers (Shaun Stine)
7 Inmates Escape; Computer Blamed! (PGN)
Hardware failures (Don Chiasson)
Liability of Expert System Developers (Benjamin I Olasov via Martin Minow)
PC's and Ad-Hoc Distributed DB's (Amos Shapir)
Risks of proposed FCC ruling (Keith F. Lynch)
RISKS in "Balance of Power" (Heikki Pesonen)
Re: Aviation Safety Reporting System (Doug Pardee)
A computer RISK in need of a name... (Jerry Leichter)
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.
FTP back issues Vol i Issue j from F4.CSL.SRI.COM:<RISKS>RISKS-i.j.
Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).
----------------------------------------------------------------------
Date: Mon, 6 Jul 87 13:41:15 edt
From: stine@ICST-SE (Shaun Stine)
To: risks@csl.sri.com
Subject: Erasing Ford (and other) car computers
I don't know how much this subject has been hashed/re-hashed in RISKS,
but a paragraph from an article in _Mustang Monthly_ caught my eye. The
gist of the article is on boosting the horsepower of the new Mustangs.
> From: "Free Horsepower for HOs!" (Mustang Monthly, July 1987)
>
> To get a more immediate horsepower boost from the elimination
> of the intake silence, disconnect the negative post on the
> battery for at least 45 seconds to erase the computer's memory.
> That way, when you crank the engine again, the computer will
> immediately begin monitoring the fuel mixture to compensate for
> the extra air flowing into the fuel injection. Be sure to
> disconnect the negative post; if you disconnect the positive
> post, the reconnection could cause a power surge that could
> possibly damage the computer.
The Mustang freaks here where I work (including myself) were interested in
these tips, but as computer people, we were more intrigued by the last bit
about damaging the computer and erasing the memory. A couple of questions:
1) If disconnecting the negative post will erase the computer's memory,
what happens when your battery dies? Or _you_ yourself take the
battery off for some reason? Does that also erase it, or does taking
the positive post off within 45 seconds somehow keep you from losing
the memory?
2) From that, what exactly do you lose when the memory is erased?
3) Is this mentioned by Ford manuals or any shop manuals (i.e. Chilton's)?
I know dealers don't mention this - my family just bought a Sable, and
I would presume that the computers are basically the same, and our
salesman never mentioned it.
4) What does this do with emissions control? Some counties in Maryland
have regular testing - would you still pass with the fuel being mixed
differently?
Whatever information anyone could provide would be greatly
appreciated. Thanks. Shaun
[A Racer's Edge becomes Erasor's Edge? Please send responses to Shaun, and
he'll condense the results. PGN]
------------------------------
Date: Tue 7 Jul 87 23:13:45-PDT
From: Peter G. Neumann <Neumann@csl.sri.com>
Subject: 7 Inmates Escape; Computer Blamed!
To: RISKS@csl.sri.com
On the 4th of July in Santa Fe, New Mexico, a prisoner kidnapped one guard,
shot another, commandeered the control center, and released six other
prisoners. All 7 went through an emergency roof door, pole-vaulted over a
barbed-wire prison fence, and disappeared. The guard tower was being
staffed only during daylight hours ``because of financial restrictions'' (SF
Chronicle, 6 Jul 1987). A PBS item noted that the prison computer control
system was down at the time, and otherwise would have prevented the escape!
------------------------------
Date: Mon 6 Jul 87 15:55:58-ADT
From: Don Chiasson <CHIASSON@DREA-XX.ARPA>
Subject: Hardware failures
To: risks@csl.sri.com
I read recently of some problems that Intel had with the 32-bit
multiply instruction on their 80386 processors. I am surprised that this
sort of problem does not occur more often: an obscure hardware bug which
sometimes gives incorrect answers. All the emphasis is on software bugs.
The assumption is that hardware will work or fail catastrophically, or that
error correcting circuits will detect problems. Is this always so?
How often do microprocessors fail in minor ways? People have written
about proving correctness of code: it is not possible to prove the
correctness of hardware. For example, a complete test of a 32 bit
multiplier would require 2**64, or 1.8E19 operations. (A year has only
3E13 microseconds.) Even without complete tests, writing diagnostic
programs was extremely difficult when various margin and worst case
conditions had to be considered. For example, memory diagnostic programs
moved themselves around in memory; they would write bit patterns of 1's,
0's, alternating 10's and 01's, actual addresses into locations, and so on.
Hardware problems can also be bizarre. My favorite was during an
experiment at sea. We were recording data, and occasionally the magnetic
tape unit would hang. Putting cards on extender boards to check signals
showed us that sometimes the tape was erroneously showing up busy, and
sometimes the computer couldn't even find the tape. Some hours later, we
found a small (1-2 mm) piece of loose wire in the back plane. As the ship
rolled, the wire would sometimes short out the busy line, and sometimes
short out a line which changed the physical address of the drive. We had
another problem (this on land) where the card side of a backplane had been
painted; tiny paint chips fell off and short/open circuited various cards.
We only found it when someone took out all the cards and noticed the paint.
Can't happen again? I read recently that a radar in a US fighter plane was
having intermittent problems. The problem was tin whiskers which grew
inside an IC, were shaken loose by vibrations and sometimes caused internal
shorts. Everything repeats, only different.
------------------------------
Date: 5 Jul 87 22:00:58 GMT
From: bloom-beacon!bolasov@husc6.harvard.edu (Benjamin I Olasov)
Subject: Liability of Expert System Developers
Forwarded-From: AIList@STRIPE.SRI.COM
Forwarded-By: minow%thundr.DEC@src.DEC.COM
I'm told that a hearing is now underway which would set a legal precedent
for determining the extent of liability to be borne by software developers
for the performance of expert systems authored by them. Does anyone have
details on this?
[AIList Digest Monday, 6 Jul 1987 Volume 5 : Issue 171]
[AIList Moderator Kenneth Laws AIList-REQUEST@STRIPE.SRI.COM]
------------------------------
To: nsc!comp-risks@Sun.COM
From: nsc!nsta!nsta.UUCP!amos@Sun.COM (Amos Shapir)
Subject: PC's and Ad-Hoc Distributed DB's
Date: 5 Jul 87 13:12:42 GMT
The last time I moved, I have noticed that certains organizations were
becoming slower in accepting change of address notices. I have been
receiving mail to my old address even after some mail (all computer printed)
had already been sent to my new address. Some organizations had to be
notified several times in writing, by phone and in person.
The latter revealed a possible explanation to this phenomenon: Many
departments acquired PC's lately and kept their own personal 'phone books';
in effect they have created a distributed database, without the discipline
and procedures needed to manage it. Changes to the organization's central
DB did not propagate well, if at all, to these small personal DB's.
It seems that nowadays when dealing with a big organization, one has to
notify them of any change in writing, so that the central DB would be
updated; then by phone or in person, directly to the department one is
dealing with, so that the change would *really* be done. So far this has not
been a risk, only a nuisance. Horror stories, anyone?
Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261
amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N
------------------------------
Date: Mon, 6 Jul 87 01:08:19 EDT
From: "Keith F. Lynch" <KFL@AI.AI.MIT.EDU>
Subject: Risks of proposed FCC ruling
To: pallas@PESCADERO.STANFORD.EDU
Cc: KFL@AI.AI.MIT.EDU, RISKS@csl.sri.com
Perhaps it isn't correct to call it a tax - though it has never been
made clear just who is to get the money. But it is hardly "nonsense"
to criticize it. The same bandwidth that supports one voice link
supports fifty 1200-baud data links. In practice, far more, because of
packet switching - i.e., 1200-baud data is not usually sent continuously.
Charge $5 an hour for a 1200 baud link? Only if at least $250 an hour
is charged for voice lines!
If this bill passes, it will no longer be profitable to sublet small
slices of T1 lines. There will be no reason not use use a full 56kb
voice band line even for 300 baud data.
The only ones who will benefit from this radical decrease of efficiency
are those who will profit from installing unneeded new bandwidth, to be
used in this inefficient manner. I say, if they can't compete in the
free market, tough. Don't let them trash our freedom to communicate.
If this passes, it will keep me off the net, since my networking cost
would go from $25 a month to over $2000 a month. I don't believe
that anyone is subsidizing this. As far as the local phone company is
concerned, it's just another local call, and it is absurd to suggest
it costs them any more than any other local call. As long as competing
local phone companies are not allowed, it is outrageous to allow the
one local phone company to take one's data hostage, demanding thousands
of dollars for what costs them pennies, for no better reason than that
they can get away with it.
I would also question how the FCC can make laws. That is the perogative
of Congress, and I see nothing in the Constitution allowing them to
delegate their power to unelected bureaucrats.
...Keith
------------------------------
Date: Tue, 07 Jul 87 16:05:15 FIN
From: Heikki Pesonen <LK-HPE%FINOU.BITNET@wiscvm.wisc.edu>
Subject: RISKS in "Balance of Power"
To: Risk Digest <RISKS@csl.sri.com>
There is a computer game about "Geopolitics in the nuclear age" called
BALANCE OF POWER. It is sold at least for Commodore Amiga. I bought one and
now master the beginners level -- being able to beat Soviet Union. (We Finns
have tried that twice before...) I do not have time and interest to do that
on the expert level, as I find many other things more interesting to do.
What does interest me is how people in the USA percieve the world view of
this game. Do you think it is reasonable? There may be some risk in
designing games simulating international affairs, if they are seemingly
realistic. Some childish people may take them as the truth.
[Please address any resposes to Heikki Pesonen directly. Cc: RISKS
if you wish. PGN]
------------------------------
Date: Tue, 7 Jul 87 10:49:59 PDT
From: edge!doug@Sun.COM
To: RISKS@csl.sri.com
Subject: Re: Aviation Safety Reporting System (RISKS-5.7)
[Although this is only marginally relevant, it raises related
questions about awareness, database completeness, and ethics. PGN]
> For many years, NASA has operated the Aviation Safety Reporting System
> (ASRS) for the FAA. It has been quite successful, producing important
> information about flight safety.
>...
> The ASRS works because it offers an inducement for reporting (immunity),
I think that the past tense should be used here. I'm just going from memory,
but I recall that in the late '70s the immunity provisions were dropped and
ASRS quickly faded into oblivion. If it is still in operation, few pilots
(including me) are aware of it.
Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug
------------------------------
Date: 29 JUN 1987 10:13:29 EST
From: <LEICHTER-JERRY@YALE.ARPA>
To: risks@csl.sri.com
Subject: A computer RISK in need of a name...
The following appeared in the Wednesday (24-Jun) New York Times, in the
Metropolitan Diary, a weekly column of "human interest" stories sent in
by readers:
A small sign was taped to a building on West 120th Street near
Amsterdam Avenue, and Ellen Shaw of Scotch Plains, N.J., noticed
it as she passed by. It was a discreet advertiesement for a
nearby stand run by three young entrepreneurs - two boys and a
girl - who were selling iced tea, cola and cookies.
Ms. Shaw ordered tea and offered the youngsters a suggestion:
"You may want to make a bigger sign," she said. "That one is
really not to noticeable."
"I know," said one of the boys, gesturing toward one of his
partners, "but that's as big as his computer makes them."
He paused, thought for a moment, and slapped his forehead. "Hey,
I've got it!" he exclaimed. "Maybe we could DRAW a bigger sign!"
The tea, incidentally, was herbal.
[As we have noted before, computers are addictive. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------