Tom Wicker, the famous columnist for the New York Times, has a column in the Times today about computers, the Vincennes incident, and the SDI. Wicker has picked up on a story John Markoff has been working on for some time, on whether complex computer networks exhibit chaotic behavior similar to the mathematical phenomenon of chaos found in nature. Wicker says that "these two events [the Vincennes and a problem with a TRW computer that John de- scribed in one of his articles] were unrelated except that they offer a com- mon warning against too complete reliance upon computers and electronic systems as substitutes for or multipliers of mankind's innate abilities." ". . . Star Wars will be heavily dependent upon a vast network of sensors, computers and electronic weapons guidance systems girdling the globe and only nominally under human control. "Given the likelihood of breakdown at any of thousands of points in a system so complex that no one has been able as yet even to design the software, it takes a leap of faith to believe that the SDI would increase national security against attack. More likely, aping the computers at your local bank or an airline ticket counter, the system would be 'down' when most needed." Wicker then goes on to speculate on the dangers of an SDI computer system subject to chaotic behavior. Wicker quotes a professor of electrical engi- neering at MIT, William Schreiber, who notes that the Aegis system in the Gulf was at least responding to something that everyone on board had been trained to deal with and had probably actually seen, i.e., a commercial airliner radar signature. What will happen with SDI or ICBM crews who are presented with something no one has ever seen before? "Not only may these high technology systems fail, or degenerate inexplicably into chaos, and be more prone to do so as they grow ever more complex; even when they function properly, the responses of the fallible human beings who may have to interpret their messages can be disastrous--and humans may be progressively less fit for a job so demanding. "Thus, as we move inexorably into the world of high technology and control by computer, the undeniable benefits will not come cheaply. For mankind's enhanced capacities, the price may be that we diminish, rather than increase, what little dominance we have of our own destiny."
The New York Times reported today that a computer entry error increased the vote count for the incumbent Lieutenant Governor of Delaware, S. B. Woo, and made it appear he had won the election when he may have lost. The correct number of votes in one district was 28, but the operator keyed in 2,828 by mistake. There will be a recount of the votes statewide.
I noted in the July issue of the ACM Software Engineering Notes that there was a panel discussion at COMPASS '88 on the topic of computer systems for counting ballots. Two of the panelists have written reports that deserve mention here: Lance J. Hoffman, ``Making Every Vote Count: Security and Reliability of Computerized Vote-Counting Systems'', Department of Electrical Engineering and Computer Science, The George Washington University, Washington D.C. 20052, 2nd printing, March 1988. Roy G. Saltman, ``Accuracy, Integrity, And Security In Computerized Vote-Tallying'', Institute for Computer Sciences and Technology, National Bureau of Standards, Gaithersburg MD 20899, NBS Special Publication, June 1988 (draft). These two reports are absolutely essential reading for anyone interested in the problems arising in election software. There is also a paper by Erik Nilsson ("A Bucket of Worms") on this subject, in the proceedings of CPSR's DIACS 88.
A friend of mine who does satellite work expressed surprise that the Soviets could lose a space probe so easily. Apparently, US craft have a "panic" mode that takes over if there is some problem (presumably in this case the batteries running low). The probe then realigns itself so that its solar panels face the sun, its antenna faces the Earth and it waits for new commands. This seems like the right idea, but I don't know much about how it works. For instance, are the panic commands in ROM so that they can never be overwritten? Dave Feldmeier
On Unix, even experienced users can do a lot of damage with "rm". I had never bothered writing a safe rm script since I did not remove files by mistake. Then one day I had the bad luck of typing "!r" to repeat some command or other from the history list, and to my horror saw the screen echo "rm -r *" I had run in some other directory, having taken time to clean things up. Maybe the C shell could use a nohistclobber option? This remains the only time I have ever rm'ed or overwritten any files by mistake and it was a pure and simple gotcha! of the lowest kind. Coincidentally, just the other day I listened to a naive user's horror at running "rm *" to remove the file "*" he had just incorrectly created from within mail. Luckily for him, a file low in alphabetic order did not have write permission, so the removal of everything stopped early. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
According to the news on the wireless this morning the London Undergound system was distributed by a power failure that had damaged "the computer". This system appears to control all the lifts, escalators and signals!! Anyone know what really happened?? Lindsay
Jim Williams writes of a remote control at a hotel which had the ominous warning on it: "This remote control will only work on Beeblebrox Hotel TVs. REMOTE WILL DAMAGE your home TV sets." He then asks if this is indeed possible. I believe that it is entirely possible. The control signals for the remote could be chosen in such a way that the "on" control would send a command stream that would be interpretted by a home TV set as "on" immediately followed by "off". Such cycling of the power will quickly damage the power control circuit and send spikes to the rest of the components. Most TVs require some form of delay between an "on" and an "off" (actually, they are the same code, the TV just changes state) but this could easily be accounted for. For those doubters, I heard of a "crt saver" for the IBM a long time ago that actually destroyed the monitor. It would cut one of the locking frequencies (I believe that is how it worked) which would make the sceen appear blank, but would allow a charge to build on a capacitor. Eventually the capacitor failed and took the rest of the monitor with it. William Curtiss
> The `privacy' argument has two sides.... it is the right of an individual > *not* to have their phone number displayed, but it is also the right of the > individual *not* to answer anonymous calls. A problem to which the solution > seems easy enough.... (now prove otherwise!)  Suppose that all business phones had to "send" their phone numbers by law.  Callers TO business phones have the right to withold their numbers using a prefix.  Individual-to-individual calls would "send" their phone numbers unless a prefix was used.  Individuals COULD have their phones set up so that any non-ANI calls would be rejected (with a recording saying why).  If you dial a number with a prefix, you get a recording if the target of the call ALWAYS gets ANI (e.g. the police emergency line); the call will complete at the callers option. I suspect most folks would opt for  on their home phones. This should cut down on the number of obscene calls. AIDs hot lines can be called with the prefix -- the caller knows their number is not being traced because they did not get a recording. Callers to businesses know their number is not being traced if they used a prefix. Does that solve some of the problems? Mike Linnig, Texas Instruments
In the interest of keeping RISKS stimulating, and minimizing the mass of suboptimal submissions, this is a reassertion of and elaboration upon a few of the masthead guidelines, from mechanical to contextual. CONCISE: Short contributions are strongly preferred, assuming they satisfy the other criteria. Long ones may wait indefinitely, unless they are very hot. I would rather not have to impose a default limit, but would like to urge consideration on your part. Think of all the times you have had to struggle with reading someone else's overly long messages that wandered illogically, and try not to write that way. NONREPETITIOUS: Messages that go over the same ground as previous messages (including this one!) place a serious burden on all of us. I cannot remember every contribution, but try very hard to minimize repetition. Please try to check over previous issues before you fire off your comments. When you relate to back issues, do so explicitly. Messages that blindly incorporate an earlier message in its entirety (particularly when it is long) are very annoying. Yes, I tend to delete most of the repeated portions, but you might better do that yourselves. Interstitial annotations that comment almost paragraph by paragraph on the earlier messages are generally not very interesting anyway, so avoid those altogether. (By the way, I usually keep reconsidering not-yet-included but still-possibly-interesting messages for several days until they eventually fall off the end of my attention span. However, I do not usually send out rejection notices, and trust the network servers to help you distinguish between that case and the case in which your mail was never received -- although that may not be a reliable process for some of the networks.) COHERENT: Writing skills are difficult to master. But PLEASE take care in formulating your thoughts. It makes your contributions much more readable, and saves agonizing back-and-forths later. I hate playing English professor, but I cannot believe how bad some of the submitted writing is. (I do edit when it is flagrant.) RELEVANCE: By now you know that I have a broad interpretation of "computers and related systems". But I still get lots of contributions that are clearly not relevant. There are a few of you RISKS contributors whose messages have been reliably relevant, sound, concise, etc., and who always assume other readers are smart, honest people with good intentions. Many thanks to you. I hope that others will try harder to emulate you. As a reward for you, this relatively boring message is placed last in the issue (just in case you didn't get this far) -- in the ongoing struggle to make RISKS readable. (For some others, however, it probably should have been placed FIRST.) Thanks to all RISKS folks for your support and help over the past three years. The feedback I get seems to indicate that it is worth the effort to continue. Peter
Please report problems with the web pages to the maintainer