RISKS@SRI-CSL.ARPA (RISKS FORUM, Peter G. Neumann, Coordinator) (12/17/85)
RISKS-LIST: RISKS-FORUM Digest Thursday, 13 Dec 1985 Volume 1 : Issue 29
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
Peter G. Neumann, moderator
Contents:
Summary of Groundrules:
The RISKS Forum is a moderated digest. To be distributed, submissions should
be relevant to the topic, technically sound, objective, in good taste, and
coherent. Others will be rejected. Diversity of viewpoints is welcome.
Please try to avoid repetition of earlier discussions.
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA)
(FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)
----------------------------------------------------------------------
Date: 14 Dec 85 09:04 PST
From: cole.pa@Xerox.ARPA
Subject: Request for Cases, Settled or Decided
To:RISKS@SRI-CSL.ARPA
There has been little legal analysis concerning the "computer
revolution"; partly because there have been few cases that have been
decided by the appellate courts.
I have started researching this area and would appreciate very much any
pointers to cases -- threatened, settled, decided by trial and not
appealed, or appealed -- that involve questions of:
(1) liability for unsuspected "bugs";
(2) liability for program design flaws;
(3) liability for disgruntled programmers taking "revenge" upon their
corporation at the expense of the customers; or,
(4) liability for harm (personal or economic) caused by a human making
computer-aided decisions. This could be anything from a medical decision
using MYCIN, PUFF, ONCOCIN et. al. to an automobile designer using
CAD/CAM.
I am not looking for situations where the vendor/programmer promised
what he knew he could not deliver, outright fraud, or contractual
disputes about the value delivered; I am trying to find situations where
fault lay in the human-computer interaction.
There are a number of possible legal theories that may apply to the
present range of problems; I also am examining theories that may apply
as more "independant" and extensive AI applications, that involve less
computer-friendly users, become part of everyday life. Some of these
theories should extend to cover analagous situations; some will probably
not; the questions I am interested in are WHY and HOW any theory should
apply.
Again, I would be very grateful for any information from any of you.
When this study is completed I will report that to this forum.
George S. Cole, Esq.
N.B.: This task is part of the research project I am working on while
attending Stanford's C.S. Master's program, at Xerox PARC. I am a
licensed attorney (temporarily suspending practice to gain the Master's
Degree) and am extremely interested in attempts to combine the practices
in these two fields.
------------------------------
Date: Mon 16 Dec 85 07:24:18-EST
From: "Fred Hapgood" <SIDNEY.G.HAPGOOD%MIT-OZ@MIT-MC.ARPA>
Subject: Risks of job displacement from computerization
To: risks%MIT-OZ@MIT-MC.ARPA
Is anybody keeping track on an on-going basis, of the job
categories being destroyed by the computer? A recent example is that
of "presentation photographer" -- who, at the minimum, shot pix
of graphs and graphics for presentations, and at the limit,
designed and assembled those graphics. Not a big category, nor
one with a set of skills whose loss leaves civilization that much
poorer, but probably representative.
Anyway, I would very much like to reach the technology-and-
society scholar (surely there must be one somewhere) who is
paying attention to this issue.
------------------------------
Date: Fri, 13 Dec 85 15:26 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Subject: Risks re computer-compared prescriptions
To: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>,
RISKS@SRI-CSL.ARPA
Reply-To: RSL@SCRC-STONY-BROOK.ARPA
Date: Tue, 10 Dec 85 09:50 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Recently, an increasing number of pharmacies have been putting greater
amounts of drug information "on line".
[...]
Several concerns come to mind:
- Where is the database of drug conflicts derived from? Manufacturers'
data files? FDA reports? Articles in recent medical journals? Just
how complete is it?
That's a very good question. It turns out that the database on drug
interactions is very sparse, even for the simple case of two different
drugs. There are a lot of common combinations which have never been
adequately tested.
- Does the database cover only drug-to-drug interactions, or is it more
complete? Might it, for example, contain counter-indication information
for specific drugs (e.g., don't take this if you're pregnant)? How
about reports of unusual symptoms or side effects?
Again, this database is also very sparse. Many drugs these days carry
the warning that they haven't been tested in pregnant women, and
therefore the physician should think twice (or more) before prescribing
them to pregnant women (or those of "childbearing age", in many cases).
One of the reasons drugs have not been adequately tested during
pregnancy is that manufacturers are frightened of testing them in
pregnant women, and, in fact, many drugs are not tested in "childbearing
age" women at all, just in case they might be or become pregnant during
the study!
------------------------------
Date: Fri, 13 Dec 85 11:04:08 est
From: rich <@CSNET-RELAY.ARPA,@case.CSNET:rich@rexago1.uucp>
To: RISKS@SRI-CSL
Subject: legal bootlegs (a case against worms)
As I understand the paper work that comes with most micro software
packages (big machine software is a different arena) what I buy is
not a program but a right to use a given program. The mode of
transmission is generally not specified. It could be my original
distribution diskette, telephone, or a friend's legitimate copy.
If I scramble my original and then copy his, what have I done
illegal? If I see a worm, you can bet my lawyer will hear about it.
K. Richard Magill
------------------------------
Date: Mon, 16 Dec 85 11:07:26 -0100
From: ircam!mf@seismo.CSS.GOV (mf)
To: +risks@seismo.CSS.GOV, RISKS@sri-csl.ARPA
Subject: Passwords
If you leave a $500-bike locked and unattended for a week (as one of the
readers put it) it is likely not to be there when you return, but not because
a thief would have had the patience to try all combinations: he probably would
wait for a quiet moment and break the lock or cut the chain.
And so it is with passwords: trying all possible combinations is theoretically
feasible, but not very practical. A very simple method (and here the analogy
with bikes stops) -- described for Unix but easily transportable -- is to run
a [c]shell command file that fakes the login procedure, i.e., prints the login
msg on a terminal, asking for the account and password (in no echo mode), and
then printing "login incorrect" and exiting (after having recorded the
password).
An unsuspecting user will think he mistyped his password and will try again.
How does one protect against such booby traps?
------------------------------
Date: 0 0 00:00:00 CDT [SIC!]
From: "MARTIN J. MOORE" <mooremj@eglin-vax>
Subject: verifying source code vs. executable code
To: "risks" <risks@sri-csl>
Re: Keith Lynch's question about knowing that the source code matches the
executable, here is something simple that we did to support configuration
control and to guard against EPROM decay when I worked at Cape Canaveral:
Whenever one of our programs was compiled and an executable file was
generated, we ran a program to checksum the executable file (just a simple
addition, but you could get much fancier with CRC if you wanted). This
checksum was programmed into a fixed location in the EPROM. All of the
programs contained code that, when the program was initialized, would
run the same procedure on the program itself, compare the computed result
to the stored result, and halt with an error message if there was a
difference. Whenever a new program was installed, the stored checksum
was recorded with the configuration control data, and the customer
occasionally pulled surprise audits to make sure that the correct set of
EPROMS was in use; they would come in, look at the stored checksum in
the EPROM, and compare it to the recorded information. Since we had
seven different instrumentation sites, each with slightly different
configurations, and usually two or three versions of the program floating
around, keeping track of the EPROM sets was a headache -- until we
adopted this scheme, which worked beautifully.
If anyone wants specific details of the code (the processors were LSI-11s)
I will be happy to send them to you.
------------------------------
Date: Fri 13 Dec 85 17:56:01-PST
From: Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Subject: Seminar - SDI Debate (SU)
ReSent-From: Werner Uhrig <CMP.WERNER@R20.UTEXAS.EDU>
``SDI: How Feasible, How Useful, How Robust?''
This will be a technical debate, covering both hardware and software aspects
of SDI.
Sponsor: Stanford Computer Science Department
Date: December 19, 1985
Time: 8:00 p.m.
Place: Terman Auditorium
Organizer: Barbara Simons, IBM-SJ
Moderator: Dr. Marvin L. Goldberger, President of Cal Tech.
Former member of President's Science Advisory Committee
and Consultant on Arms Control and International Security.
Panelists:
Advocates:
Professor Richard Lipton, Professor of Computer Science at Princeton
University, Current member of SDIO's Panel on Computing and Support of Battle
Management.
Major Simon Peter Warden, the Special Assistant to the Director of the SDIO
and Technical Advisor to the Nuclear and Space Arms Talk with the USSR
in Geneva.
Opponents:
Dr. Richard L. Garwin, IBM Fellow and Adjunct Professor of Physics at
Columbia University, Physicist and Defense Consultant.
Professor David Parnas, Lansdown Professor of Computer Science at the
University of Victoria, Former member of the SDI Organization's
Panel on Computing and Support of Battle Management.
------------------------------
End of RISKS-FORUM Digest
************************
-------