8-Jul-87 00:00:01-PDT,14439;000000000000 Return-Path: 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) 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-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 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 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" 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 Subject: RISKS in "Balance of Power" To: Risk Digest 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: 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 ************************ -------