[@ucbvax.Berkeley.EDU,@unisoft:jeff@jusoft.UUCP] Drivers Often Override ATS on Chuo-Sobu Line Asahi Evening News, Thursday December 8, 1988 Tokyo, Japan — Police investigating the Dec. 5 rear-end collision at Higashi-Nakano Station on the East Japan Railway's Chuo Line, which killed two [the driver and a passenger] and injured 102, have found that the train drivers override the ATS (automatic train stop) system over 10 times during the run between Chiba and Mitaka stations. This is because the heavy train schedules result in trains becoming close-packed on the tracks. Police also found that the drivers in many cases do not apply the hand brakes after overriding the ATS, as they are required to do, because applying the brakes would delay the trains further. This practice of overriding the ATS and not applying the hand brakes is believed to be in the background of the Dec. 5 rear-end collision. The investigations up to Wednesday showed that the brakes and ATS on the train that ran into the stopped train were in good working order. JR East penalizes train drivers for being late more than 30 seconds when calculating pay hikes and bonuses. Drivers say JR East is stricter on this point than the old Japanese National Railways (JNR). The catchword is, "Don't be late!". The train that ran into the stopped train was about four minutes behind schedule and JR people say that driver Teruki Hirano could have been trying to make up for lost time. The union claims that the tight schedules produced the accident, but JR East points out that similar schedules have been used for more than 20 years. During the peak commuting hour in the morning, there are trains every two and a half minutes, but at the time of the accident, the interval was one every three and a half minutes. This was the third accident on the down line between Okubo and Higashi-Nakano stations, and all three were rear-end collisions. They all occurred between 9 and 10 a.m. after the morning rush hour. Most passengers get off at Shinjuku Station, and drivers tend to relax because they have only a little more to go to Nakano Station or Mitaka Station [the end of their run]. No improvements were made in signal and safety facilities after the second accident in 1980. Some experts point out that there should be more signals installed at shorter intervals because of the sharp curve in front of the station and the short distance between the end of the curve and the station.
In RISKS 7.92, Randall Davis writes: > Can automation and reliance on remote sensing be overdone? Of course. > Is this an example of it, or an example of the opposite? [...] ...within > almost any reasonable definition, the system worked to supply accurate > and useful information in a form available in a "quick reference"; every > report that comes out continues to make that clear. And earlier in the same submission, "When the report came out that the system had supplied accurate information, the silence [among RISKS contributors] was deafening." As I understand the final Pentagon-issued report on the Vincennes incident, the initial classification of the aircraft's identity and altitude vector were indeed in error. The October 15 Science News summarizes the findings thus: "The computerized surveillance system on the Vincennes first misread the plane's altitude and identified it as an F-14 fighter jet, but then corrected itself. The Navy report concludes crewmen responsible for evaluating surveillance did not closely analyze the initial computer mistake. Furthermore, the skipper paid more attention to their increasingly heated reports of an emergency than to new displays generated by the computer." That being the case, one could make a case for this being an example of over-reliance on automation. The crew involved believed the initial system identification and altitude reading and did not double check them, nor did they change their evaluation when given new, conflicting information. However, when faced with an over-the-horizon threat, the crew has no choice but to rely on remote sensing and automated target identification, so over-reliance is hardly an option. I think this incident was primarily the result of an interaction between automation and crew that system developers did not predict, and in fact have no way of anticipating without extremely extensive scenario generation and analysis. The crew was "primed" to accept the initial misidentification because a fire-fight with Iranian gunboats twenty minutes prior to the aircraft encounter had raised their expectation of attack and, in effect, lowered their target detection "threshold" to the point where the original misidentification was easily accepted. As automation becomes more complex, and as decision-making becomes more automated, I think we'll see more of these types of incident. System developers need to realize that complex automation can produce subtle and unintended consequences, due to the interactions between automation and crew or between automated systems, and that these consequences can lead to major errors. I believe the major outcome of the Vincennes incident should not be to assign blame to either automation or humans, but rather to recognize that new analytic approaches should be developed to uncover potential problems before such systems are fielded. -Victor Riley, Honeywell Systems and Research Center (all usual disclamers apply)
From Communications Week International, 21 Nov 88 One night last year, Italian banking clients using the ''bancomat,'' an electronic teller, were pleased to discover that their bank branch had added an extra terminal. Delighted to be spared waiting time, the clients inserted their cards into the machine. The bancomat presented the usual menu and requested the client's personal identification numbers. The machine, however, withheld the client's cards, informing them that the cards were invalid and that they should request information during banking hours. It was only when the clients returned to the bank the following day, ready to complain, that they learned that they had been victims of a new kind of fraud. What had appeared to be a bancomat was, in fact, a personal computer, placed on the bank wall by an independent operator. The thief/entrepeneur used the cards and identification numbers to clean out their accounts. This anecdote, revealed recently during a conference of banking security experts, indicates the kind of problems faced by value-added services operators in a country that has serious organizational difficulties. [This is the old system-spoof problem. Authentication is a two-way street. The system needs some sort of authentication that the user identity is authentic. But the user also needs some sort of authentication that the system identity is authentic. PGN]
In the 11 Dec 88 'Los Angeles Times Book Review' Times Book Editor Jack Miles reviews a new novel, "Trapdoor" by Bernard J. O'Keefe (Houghton Mifflin). The headline for the review is WAR BY COMPUTER VIRUS. It quotes from the epilogue to the novel, in which the author calls it a "parable to point out the complexity of modern technology and to demonstrate how one error, one misjudgment, or one act of sabotage could lead to actions that would annihilate civilization." I have not read the book, but according to the review, an inside saboteur plants a delayed-action "virus" (the review calls it one, although the description doesn't really sound like one) in a Pentagon computer which messes with the public-key encryption codes required to fire US missiles equipped with permissive action links. "The result: America no longer knows the code necessary to launch its own weapons. The nation is defenseless." (In the epilogue, the author points out that it can't quite happen that way.) Much more transpires. The author, O'Keefe, earlier wrote the non-fiction "Nuclear Hostages," worked with Fermi and Oppenheimer on the Manhattan Project, and heads EG&G, the company which the publisher says has "conducted all nuclear weapons tests for the US government for the last 40 years and is the operating contractor for the Kennedy Space Center." The reviewer says, "there remains a lean and gripping parable hiding inside an only slightly overweight thriller. For all its novelistic faults, I can't imagine a timelier read or a better Christmas gift for anyone serious about computers or math.... If the computers that control our nuclear weapons can be disabled, what about the computer that control our nuclear power plants? What about the computers that control our vote-counting and our stock transactions?..."
In Andy Goldstein's contribution of 12 Dec 88, he says, in reaction to my previous comments: > Many of the computer systems involved are crucial to a business's > operation; some are critical to human life. The potential (and in some > cases the actuality) is there for major losses from disruption of > service and theft. The hackers are unknown outsiders in whom a serious > organization can place no trust whatsoever. One of my examples was Com-Share Incorporated. This description exactly fits Com-Share. Com-Share had only one buisness: Selling timesharing services. Com-Share had more customers than any other timesharing service in the early '70s, and the customers were distributed nationwide. Security was of the utmost importance; without it, the company would surely have failed in the marketplace. In this context, the reward offered by Com-Share to anyone discovering a loophole in the system security served an important role. Goldstein describes the hackers who threaten a commercial service as follows: > The hackers are unknown outsiders in whom a serious > organization can place no trust whatsoever. Without the reward, the company would have clearly had to react to hackers as the above quote indicates. With the reward, the company could not exactly trust hackers, but rather, the company could make it more rewarding for a hacker to tell the company what was wrong than to take a less desirable path such as selling improperly obtained information to a third party. A reward does not automatically make all hacking constructive, but it offers an incentive for constructive hacking. By the same token, legal dis-incentives for destructive hacking also can help. What I oppose are blindly applied blanket actions taken against all hackers. These provide an incentive to stay away from hacking, but if someone insists on hacking, they provide no incentive towards constructive behavior. I feel that hacking is a sufficiently attractive activity that some people will hack whether it is legal or not, and we must keep incentives in the system to direct the behavior of such people to constructive ends. Douglas W. Jones
The recent discussions of the etymology of the terms "hacker", "cracker", _et al_ & the recent spirited defence of the activity by one or two contributors (at least one of them being a self-confessed "hacker") has set me to thinking. In RISKS & elsewhere, I see a "generation gap" between what, for want of a better term, I would describe as the "old-time hackers", who were experimenters, and the current cyberpunks, the "hackers" of popular mediaspeak, the eponymous "shatterers". I think this apparent generation gap is fundamental to the discussion. The "old-style hackers" (of whom I am vain enough to claim I belong) learned their computing in the 60s and 70s, often in a university or similar multiuser environment, where, as often as not, hacking involved programming. Today's stainless steel rats are much more likely to have discovered computers in the home, courtesy of Apple, Commodore or IBM, and started their "network tourist" activities by purchasing a modem. The old school (& I include myself here) resents the way the term "hacker" has been hi-jacked and is today being used to connotate anti-social activity. This is despite the ambiguous roots of the term (described by Weizenbaum in _Computer Power & Human Reason_). Today's cyberpunks are computer burglars, who are attempting to justify their activities by claiming a common motivation with their arguably less anti-social predecessors. Like any story of generation conflict, there are elements of truth in the claims of both sides. It is going to be impossible to prevent the media from using the word "hacker" in a way that the "old school" dislike. It would almost be easier to claim that the word "gay" meant "happy, carefree". But maybe the media and the collective unconscious understand the evolution of hackerism better than we do. For just as there is at least a tiny thread of commonality with the hackers of old in the network rats of the 80s, and I would say that there was some small element of today's network rats in the hackers of old. But of course, there IS a distinction between hacking around a system whose sole reason of being is to teach people about computers, and hacking into systems which are being used for serious business purposes and where outsiders no right to be. That difference is ethical, and has well expounded here in RISKS already. Seeing as we can't get rid of "hackers" in the popular media, I would like to coin the term "punk hackers" (an abbreviation of 'cyberpunk hackers') to describe their anti-social activities. It seems to fit only too well, just like "punk rock" is rock music with swearing & spitting at the audience. And using it would let us "old hackers" keep our self-respect! Nigel Roberts, Munich, W. Germany.
In RISKS DIGEST 7.92 cjosta@taux01.UUCP (Jonathan Sweedler) writes >It seems that Robert Morris Jr. would not have done anything illegal >(even under these new bills) if his virus had worked as it was designed >to work: to propagate quietly from machine to machine. Several times I've seen it discussed here on RISKS about what the worm would have done had "it worked as it was designed to work". One of our local compiler gurus, Donn Seeley, was the person who decompiled the worm code from which Gene Spafford wrote his paper. Donn Seeley has also written a paper on the worm and I attended a talk he gave on the worm here at the University of Utah. He was asked the question "On USENET there has been discussion to the effect that the author intended the worm to propagate slowly from machine to machine, but a programming error caused the worm to replicate out of control. What evidence did you see in the code to support this?" His answer was "None." This business about the worm "doing what it was designed to do" is merely a rumor going around USENET and has no substantiation in fact, unless RTM himself starts claiming that there was a design mistake. Since RTM has so far remained silent, I'm inclined to believe Donn Seeley. There is NO EVIDENCE in the decompiled code to indicate that the worm was intended to propagate slowly. In fact, the minimum lifetime the worm could have is fifteen minutes. There is code in the worm that deals with "population control", but this is oriented more towards making sure that not too many copies of the worm are running so that the worm can get some "work" done. Otherwise, the worm would never propagate out of the first few machines because it would be so busy re-infecting them. — Rich
Reading the recent risks discussion (and listening to conversation at parties) was an education. So much magic: cr--r----- 1 root sys 3, 0 Jan 10 1987 /dev/mem chown root /dev/mem /dev/kmem ... chgrp sys /dev/mem /dev/kmem ... chmod 440 /dev/mem /dev/kmem ... (From Paul McKenney's note in Risks 7.87) Friends, this thing under my desk isn't a computer, and I'm not a computer programmer. Of course, it looks like a computer, and the woman who services it probably assumes it's a computer, and the guy in the next office who designed it is quite certain it's a computer, (and the folks who pay my salary hope I'm a computer programmer), but they're all wrong. It's a tool, that's all; and, when I'm reading my mail or writing my programs, I'm every bit as naive as the folks who say "hello" when the login program tells them to. It's a smart typewriter, and that's all it should be. I don't want to program my workstation. I don't want to become a Unix guru to get my work done, and I don't want to have to play hide-and-seek with every snake to slither out of a C programming course. I want to take the stuff out of the box, plug it in, and get some work done without having to worry whether /dev/mem is owned by root. Telling me how to repair the problem is missing the point altogether. In fact, there is so much software inside of that workstation and the comptuter network it connects to: Ultrix, X-windows, Microemacs, Ethernet, VMS, more Ethernet, disk servers, and whathaveyou, that I doubt that there is any single person who can navigate through the entire collection. I have to trust the people who have "privileges" to do their job responsibly, and the people who design the systems to limit my risk. Now, where did I put my copy of Normal Accidents? Martin Minow firstname.lastname@example.org The above does not represent the position of Digital Equipment Corporation.
Excerpts from an op-ed piece in the business section of the Boston Globe, Tuesday, Dec 13, 1988: For Robert T. Morris Jr., hacker, there's no excuse By Aaron Harber [Harber teaches at the Kennedy School of Government at Harvard University and is a director of two software companies.] ... With hackers around the country proclaiming Morris a superstar, he is on the path to becoming a folk hero. We must see that his punishment is swift and severe so that his actions are immediately seen and understood as undesirable and unacceptable. To do any less will sow the seeds for further undertakings by those who are as "bright and bored" as Morris. ... Morris' good intentions failed in two respects. First, once he realized his error, he had many opportunites to correct it... He panicked and failed to seriously attempt to correct his monster. More importantly, Morris knew he should not have made the attempt at all. It was not only that something might go wrong. He had many other ways of proving his theories and, ironically, was someone people would listen to had he raised the concern in a legitimate forum. In a supervised demonstration, he could have made his point and received the attention and accolades he may have sought. His attempt was based on the premise accepted by far too many people: Computer systems are different from other forms of property... It is considered by all to be unethical and illegal to enter someone's business and examine records without permission.... Yet hackers see invasion of a system as a challenge and are often rewarded for their "successes." ... Students are taught skills that give them the power to do both positive and negative deeds, yet they are rarely, if ever, schooled in the ethical deployment of that power. Given the constant demonstrations of a hacker's potential power, why are computer ethics courses not mandatory? ... Robert Tappan Morris Jr. is an example of how we have failed and his example is one that will be followed until we change society. Hackers will continue to see breaking into systems and implanting viruses as a game. They know they would not physically ever harm someone, yet do not comprehend the violence of their seemingly benign actions. They rarely see, in person, the results of their activities and this distance promotes their insensitivity. ... The possibilities [for harm] are endless. Unless and until new standards are set and accepted by the country, we will continue to suffer from people such as Robert Tappan Morris Jr. and their computer viruses. [Excerpted by Martin Minow email@example.com The above does not represent the position of Digital Equipment Corporation.]
Please report problems with the web pages to the maintainer