1-Apr-86 23:27:13-PST,11487;000000000000 Mail-From: NEUMANN created at 1-Apr-86 23:25:36 Date: Tue 1 Apr 86 23:25:35-PST From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-2.36 Sender: NEUMANN@SRI-CSL.ARPA To: RISKS-LIST@SRI-CSL.ARPA RISKS-LIST: RISKS-FORUM Digest, Tuesday, 1 Apr 1986 Volume 2 : Issue 36 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Errant Clocks (Barry Shein) Computer Illiteracy (Matthew P. Wiener) San Jose Library (Dick Karpinski, Holleran) Psychological and sociological consequences (Dave Benson) More inter-system crashes (Henry Spencer) COMPASS 86: A Progress Report (Al Friend) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.) (Back issues Vol i Issue j stored in SRI-CSL:RISKS-i.j. Vol 1: MAXj=45) ---------------------------------------------------------------------- Date: Sun, 30 Mar 86 21:25:09 EST From: Barry Shein To: risks@sri-csl.ARPA Subject: Errant Clocks A reasonable double check before setting the time is to have the program check the last time the file system on disk was stamped with (I assume almost all O/S's stamp the time on the disk.) Certainly on a re-start time should not have moved backwards, for example, and some motions forward should be viewed with suspicion (more than say, a few hours.) This at least can be used to set a lower and upper bounds before the system screams on the console. UNIX uses this, I am sure other systems either do or could easily. Of course, this just shifts us to a different authority, and we know that the crash that started this cycle just might have damaged the file system, well, I guess that is left as an exercise for the designer, but at least you get to trust yourself. -Barry Shein, Boston University ------------------------------ Date: Tue, 1 Apr 86 05:59:33 pst From: weemba@brahms.berkeley.edu (Matthew P. Wiener) To: risks@sri-csl.arpa Subject: Computer Illiteracy I'd like to relate a phenomena that happened when I computerized my grading system some years back. It used to be I did everything involving grades by hand, and one summer I finally wrote the software to do it all on by machine. From my point of view this was wonderful. I thought it was useful from the students' point of view: I now passed out individualized summaries of what my records had, giving them a chance to correct any mistakes I made. But one subtle hitch occurred. Traditionally, I let the students come in at certain appointed hours after the grades have been computed but before they have been submitted to correct any last minute errors. I also take the time to explain their grades and how they were computed. It doesn't always make them happy; I cannot be budged when it comes to my judgement calls. This last chance office hour can be quite unpleasant at times--so many students take their grades seriously to the most ridiculous degrees, and make all sorts of irrational/emotional appeals to get the better grade. When I switched over, the following happened. I was teaching calculus for non-technical students for the third year in a row, so I was expecting the same student reactions at grade time--especially from the pre-meds. Instead, as soon as a student began his/her complaint, and I said, "OK, let's check the records here," I'd show them the computer printout and he/she would then acquiesce immediately. "Oh, so that is why I only got a B+." They were, of course, the exact same numbers that I could have written down by hand on the specially lined paper provided by the department. At the time I was elated at this easy solution to the pesky student problem that I had just found. But looking back, I find this reaction disturbing, with possibilities that the new computer illiteracy is actually dangerous to its victims. Since then, the only students I've had who aren't put off by the computer printouts are the ones with actual computer experience and/or actual human intelligence, which usually occurs in the more advanced math classes. [We took this one, but let's go slow on starting a sequence of anecdotes on people trusting computers absurdly. There are enough cases to fill up the RISKS Forum forever. The message is clear, however. There is a lot of ignorance in the general populace. But do we really know better? Perhaps we should pervert the negative Turing Test hypothesis to "You can always tell a computer, but you can't tell it much." PGN] ------------------------------ Date: Mon, 31 Mar 86 03:50:38 PST From: ucsfcca.UCSF!dick@ucsf-cgl.ARPA (Dick Karpinski) To: risks@sri-csl.ARPA Subject: San Jose Library Considering the amount of loss, perhaps some expert tinkering (a la NSA) could actually recover the info. I know we got data off _physically_ crashed hard disks through Data Recovery in LA a couple of years back. Considering the forum here, perhaps I should mention the crashes we had. It was Fourth of July when they told me the PDP-11/70 would not boot. When I asked, they said one of our three 300MB drives blew a fuse so they had switched the pack to the center drive normally used for backups. Not only did the live data get trashed, but all three generations of our backup packs had been crashed between the time the backup was done and the time the pack was replaced with the next in cycle. Three weeks worth or so, switching packs in mid day and backing up at 4am. It took thousands of dollars and two weeks to get our data back. We gained new respect for inter-media backups and for fixed media disks. Dick ------------------------------ Date: Tue, 1 Apr 86 09:32 EST From: Holleran@DOCKMASTER.ARPA Subject: San Jose Library To: RISKS@SRI-CSL.ARPA If the public realized that the audit trail for returned books, records, tapes, et cetera was missing then more of the returned books, records, tapes, et cetera would not be returned. Most people return items on time or not unreasonably late only because there is an audit trail. Without the audit trail, there is no incentive for timeliness. A possible solution might be to lie and say to the newspaper that the audit trail had been recovered. As a follow-up, the library could then offer a penalty free time for the return of all materials. ------------------------------ Date: Mon, 31 Mar 86 21:28:13 pst From: Dave Benson To: risks%sri-csl.arpa@csnet-relay.arpa Subject: Psychological and sociological consequences (An inquiry from) HARALD BAERENREITER, Fernuniversitaet, Arbeitsbereich Allgemeine Soziologie, Postfach 940, D-5800 Hagen, F.R.G. Regarding the inquiry from Baerenreiter: The light reading Stephen Levy Hackers: Heroes of the Computer Revolution Doubleday & Co., 1984 (paperback: Dell Publ Co.) should suggest some of the psychological and sociological risks associated with certain forms of computer use. Please do note that I specifically disclaim any suggestion that computer use CAUSES these psychological or sociological effects. It may well be that certain psychological states induce the forms of computer use mentioned in Levy's book. Whatever the case, the book is certainly enjoyable reading. ------------------------------ Date: Tue, 1 Apr 86 22:16:18 EST From: ihnp4!utzoo!henry@seismo.CSS.GOV To: risks@sri-csl.arpa Subject: More inter-system crashes Rich Hammond writes, in part: > ...The problem: Turning off the electric power > caused the emergency generator to come on, but the generator was cooled by > water which came from the [shut off] main... Apparently there were quite a number of vaguely analogous situations in the Eastern Seaboard blackout of 1965. Samples: One hospital had an excellent emergency generator that cut in promptly, but it was in the basement. The hospital was in a low-lying area, and the basement was kept dry by constant pumping. You guessed it: the pumps were not on the emergency power bus, and the emergency power died as soon as the rising seepage reached the generator. Another organization (hospital?) discovered the hard way that its diesel emergency generator had an AC-powered electric starter. Most modern power plants need housekeeping power to function, and in particular to start up. With the whole grid down, a chicken-and-egg situation developed very quickly. The New York area got startup power from a little power plant on Long Island, whose alert operator had violated standing orders and simply opened all the circuits -- including the power-grid tie-line -- when his meters went wild as the grid collapsed. Boston got startup power from MIT; the MIT EE Dept. generators had been shut down for the day, but apparently the MIT people managed to put together enough car batteries (!) to bootstrap themselves. Practically the only people whose emergency preparations really did work flawlessly were the professional paranoids: the military and the phone company. Even the air traffic control centers were dead; it was just as well that it was a clear night with considerable moonlight. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Tue, 1 Apr 86 11:21:56 est From: friend@nrl-csr (Al Friend) To: risks@sri-csl Subject: COMPASS 86: A Progress Report (From: Albert W. Friend, SPAWAR, Washington, DC) The preparations for COMPASS 86 in Washington, 7-11 July are going quite well. Many people have expressed considerable interest in the keynote address by Dave Parnas: When Can We Trust Software Systems? We have received a number of abstracts and papers. We should have an excellent attendance, based on the statements of those who say that they plan to come. In reviewing the papers that have come in, we would like to see more papers in the areas of: Measuring, Assessing, Specifying, and Eliminating risks due to defects in software, computer hardware design, process security, etc. We would be particularly interested in more papers from the academic community, especially ones with a strong basis in the theoretical infrastructure of software engineering, mathematics, etc. Also, papers relating to the psychology of programmers, and the possible limitations placed on practical software, would be extremely interesting. We have not even one paper in this area so far. If you have any bright ideas, COMPASS is the place to try them out. Any abstract received by Monday, 21 April will be reviewed by the program committee. They should either be sent by U.S. Mail to: COMPASS, P.O.Box 3815, Gaithersburg, MD 20815 or sent to me over the net at friend at nrl-csr Albert W. Friend, Program Chairman, COMPASS 86 ------------------------------ End of RISKS-FORUM Digest ************************ -------