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.
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: 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!
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
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?
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.
``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