The RISKS Digest
Volume 1 Issue 30

Monday, 16th December 1985

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Request for Cases, Settled or Decided
George S. Cole
Risks of job displacement from computerization
Fred Hapgood
Risks re computer-compared prescriptions
Richard Lamson
Legal bootlegs [a case against worms]
K.Richard Magill
Passwords
ircam
Verifying source code vs. executable code
Martin J. Moore
Seminar - SDI Debate (SU)
Joan Feigenbaum

Request for Cases, Settled or Decided

<cole.pa@Xerox.ARPA>
14 Dec 85 09:04 PST
    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.


Risks of job displacement from computerization

"Fred Hapgood" <SIDNEY.G.HAPGOOD%MIT-OZ@MIT-MC.ARPA>
Mon 16 Dec 85 07:24:18-EST
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.


Risks re computer-compared prescriptions

Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Fri, 13 Dec 85 15:26 PST
    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!


legal bootlegs (a case against worms)

rich <@CSNET-RELAY.ARPA,@case.CSNET:rich@rexago1.uucp>
Fri, 13 Dec 85 11:04:08 est
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


Passwords

mf <ircam!mf@seismo.CSS.GOV >
Mon, 16 Dec 85 11:07:26 -0100
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?


verifying source code vs. executable code

"MARTIN J. MOORE" <mooremj@eglin-vax>
0 0 00:00:00 CDT [SIC!]
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.


Seminar - SDI Debate (SU)

Joan Feigenbaum <JF@SU-SUSHI.ARPA>
Fri 13 Dec 85 17:56:01-PST
                ``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.

Please report problems with the web pages to the maintainer

x
Top