Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Echoing a decision made last month by federal judges in Philadelphia, a three-person panel of federal judges in Manhattan rule the Communications Decency Act (part of the Telecommunications Act of 1996) to be unconstitutional. The Act makes it a felony to transmit "indecent" or "patently offensive" material over computer networks where children might have access to it. The law suit involved an Internet-based newsletter opposed to legislation banning indecent but constitutionally protected speech on the Internet. The newsletter's author says it was "laced with four-letter and multisyllabic obscenities familiar to anyone and, frankly, the day I published that article, I had some very real fears of going to prison. But I felt so deeply that our rights were violated by the law, I had an obligation to fight it." The Justice Department is appealing the Philadelphia decision to the U.S. Supreme Court. (*The New York Times*, 30 Jul 1996, A7; Edupage, 30 Jul 1996)
RISKS has since its inception 11 years ago (1 Aug 1985) noted the importance
of up-front efforts in avoiding risks. Having sound requirements and a
sound design tends to save great agonies further down the line. A new book
provides a fascinating collection of chapters that present various different
approaches to software design:
Bringing Design to Software
Terry Winograd (editor)
Addison-Wesley (Reading, Massachusetts)
and ACM Press Books (New York)
1996
ISBN 0-201-85491-0
Although the topics are intentionally quite diverse, there seems to be
something useful for everybody. Chapter contributors include Mitch Kapor,
David Liddle, Gillian Crampton Smith and Philip Tabor, John Rheinfrank and
Shelley Evenson, Paul Saffo, Peter Denning and Pamela Dargan, John Seely
Brown and Paul Duguid, David Kelley and Bradley Hartfield, Donald Schon and
John Bennett, Michael Schrage, Shahaf Gal, Donald Norman, Laura De Young,
and Sara Kuhn.
Where Wizards Stay Up Late: The Origins of the Internet Katie Hafner and Matthew Lyon Simon and Schuster, New York, NY 1996 ISBN 0-684-81201-0 At first glance, this new book might not seem sufficiently risks related for me to comment on it here. However, one of the biggest risks involving many people in computer-related fields seems to be a lack of a sense of history -- except for a few old-timers such as me (but we forget!) and a few younger folks who have assiduously tried to study the past (except that it is usually not well documented). The RISKS archives strongly suggest that the same kinds of problems keep recurring, and that knowledge of the past can help significantly to avoid those risks in the future. This book will make fascinating reading for those of you who don't know the early history of the ARPAnet. It points out how only a very few people and almost no corporations foresaw the incredible potential of the emerging networking technology. The book details how the network evolved nevertheless — primarily because of the tremendous energies and visions of a few farsighted people. Let me add an editorial note. With its emphasis on advances in connectivity (for example, packet switching, high availability, alternative routing, and scalability), there was quite consciously very little emphasis on network security in the early ARPAnet days — and not enough emphasis on host-system security. You might think that is coming back to haunt us now, with all the security flakiness relating to the Internet. However, confidentiality can be enforced by the use of end-to-end cryptography, and authentication is a natural burden of the hosts anyway, so the burden falls more strongly on the operating systems. Nevertheless, prevention of denials of service is still in part a networking problem — although we certainly don't need attacks in order to have performance degradations! Recently, while in Massachusetts, I had repeated serious problems with network reliability telnetting back to California. On one occasion, I discovered that two of the major transcontinental nodes on which I had to depend were *each* dropping about 40% of their packets, over a prolonged period of time. Perhaps the real problem is that the wizards are no longer staying up late enough, or that the new quasiwizards are not familiar enough with history and the sense of accomplishment that prevailed in the ARPAnet days. Mayhaps this book will help.
Computing and Communications in the Extreme: Research for Crisis Management and Other Applications Computer Science and Telecommunications Board, National Research Council, National Academy Press, 1996 The full text is available <http://www.nap.edu/readingroom/books/extreme>. This book is the results of ongoing investigations of the Workshop Series on High-Performance Computing and Communication. The steering committee was chaired by Ken Kennedy of Rice University, and included Frances Allen, Vint Cert, Geoffrey Fox, Bill Scherlis, Burton Smith, and Karen Sollins.
To fight terrorism, the Clinton administration is proposing a number of measures which civil libertarians say pose a serious threat to the freedoms of innocent users of phones and computers. A spokesman for the American Civil Liberties Union says: 'The president is using the bombing in Atlanta as a pretense to getting more wiretap authority. The answer to terrorism isn't to limit the freedoms of Americans. If we do that, the terrorists have already won.'' (*San Jose Mercury News*, 30 Jul 96; Edupage 30 July 1996)
Before the bomb exploded at Centennial Olympic Park in Atlanta, there was a call to the 911 emergency number warning of it. But there was a 10 minute lag between when the call was received and when a police officer was dispatched. Why? According to the Associated Press, the dispatchers needed a street address for the park because the computer system they're using requires one in order to transmit the information. [Also noted by Sean Smith <sean@c3serve.c3.lanl.gov>. PGN]
Complaining about the computer system that failed in the opening days of the Olympics to provide timely and accurate information about competitive events, journalists asked Billy Payne, the president of the Atlanta Olympics Organizing Committee, "Why wasn't the technology system tested?" Payne replied that "there is no way to duplicate the totality of the Olympic condition before the start of the games." [Source: Edupage, 25 July 1996, quoting *Atlanta Journal-Constitution* Olympic City p34] [I was told yesterday during a panel session at the WICS summer course on Internet Security at Stanford that the system is no longer Olymping along, and that everything seems to be working well now. I haven't tried it myself. PGN]
IBM stated that typically they need 30-60 (or 60-90, I forget which) days to set up the type of networking systems used in Atlanta that journalists are complaining about. In many cases they had 2-3 days because of delays in the committee deciding on venues. I don't know who took the most foolish risk, the games committee for giving so little time for such a complicated system, or IBM for accepting such restrictive conditions. Tom Rowe UW-Madison
Yet another example of our impending millenium change causing trouble. This time ordinary people, rather than companies, are directly affected. >From the *Electronic Telegraph* of 30 Jul 1996: > PLANS to split the pensions of divorcing couples have been delayed > until the next century because of problems with the Department of Social > Security computer, the Government admitted yesterday. ... > Although the Government sees the need for a change in the law to give > partners equal rights to pensions, he said the new legislation would not > be implemented until after 2000 because a big shake-up of the database > of National Insurance numbers was now underway." The RISK is: How many more government databases worldwide will be affected by Y2K? And if more are, do they realise it and are they actively working on fixing the problem? They may not always be able to legislate around this issue. Mike Hanafin Motorola Cork, Ireland hanafinm@cork.cig.mot.com
I heard an advertisement on the radio the other day which highlights one of the difficulties we face in designing reliable, safe systems. The announcer touted a new feature on BMW automobiles which detects whether a passenger is present. This information is used to suppress deployment of the passenger-side airbag in accidents when appropriate. The reason for the feature, and the point made by the ad, is that replacing an airbag costs about $2500 (actually, they quoted the price for a competitor, not their own car). So why inflate the bag if there's nobody to be saved? RISKS readers are probably shuddering at this concept. A well-designed failsafe system would err on the side of unnecessary deployment, not saving a few dollars. One would hope that the passenger sensor is designed to fail into the "passenger present" mode, but it is difficult to imagine a technology which could be guaranteed to do so in all cases. The fundamental problem is that the detection subsystem is designed to suppress a safety-related behavior in the main system, rather than to redundantly encourage it, all to save money. This makes the entire system dependent on the correct operation of the subsystem. I cannot help suspecting that a few years from now, when the passenger sensors and wiring begin to wear out, BMW will suffer some lawsuits because passenger airbags should have deployed, but didn't. Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com http://fmg-www.cs.ucla.edu/geoff/
I just went through an amusing process of trying to pay my son's college tuition by credit card. The university provided the authorization form by which to do it, and it has worked in previous semesters. However, I got a phone call from the university cashier, saying the charge was declined by the bank. I called the bank, and was told that the charge was declined because it was over $5000. As a security precaution, they expect the cashier to phone in for a verbal authorization. They marked my account with my verbal OK, and said the cashier could phone them directly for a verbal authorization. I called the cashier back. She said she can't do anything unless her computer calls her bank, her bank calls my bank, and my bank okays the transaction. I asked her if I could give her my bank's phone number so she could call and find out what's going on. She said sure. She called back later and left a message saying the charge had been declined again. I called my bank to see if she had called them, and they said no, it would have been noted on my account records. They explained that the cashier probably had no procedure for handling a verbal authorization; that many places can no longer do it "the old-fashioned way". But they would call her themselves and try to make it happen. They called the cashier, who had left for the day, but left a message with another cashier giving the authorization code. The next day the cashier called me again to tell me that the charge was still being declined. I asked if she had called my bank. She said she had given my bank's number to her bank, and they had promised to call. They had called her back to say that the charge had been declined. I said, okay, let's split it into two transactions. Please put the first one through for $4999. Okay, she said, that went through. I said, okay, now put through a second transaction for the balance. Okay, she said, that went through, too. So much for security. Robert.Schwanke@scr.siemens.com rws@scr.siemens.com (609) 734-6546 Fax -6565 Siemens Corporate Research, Inc., 755 College Rd. East, Princeton, NJ 08540
Every year we add to the "intelligence" of our electrical appliances, notably computers but also more mundane items such as microwave ovens, air conditioners, microwave (yup!) clothes dryers, etc. Requirements such as power-factor correction accelerate this trend. As a result, the electrical distribution load net is slowly shifting from a constant-impedance line (electric light) to a constant-power line (computer power supplies). The RISK? Constant-power loads exhibit negative resistance: as the voltage drops, the current *increases*. As a result, the old-fashioned 'brownout' is a thing of the past. The electrical distribution network is becoming more and more unstable. Currently it's only unstable at the low-voltage end of the supply curve, but eventually the instability will reach normal operating levels. I got a taste of this in an industrial-automation system a while ago. If you think the Year 2000 problem is going to be fun, just *imagine* trying to manage the power-distribution network in a few years. D. C. Sessions dc.sessions@tempe.vlsi.com
I wonder where Mark lives to develop the model he is using. Living in the
west where we can see several problems with his model from the front door.
1. To use an economic model to describe a physical entity is at best unwise
and mostly worthless. The only legitimate comparison is that Government
agencies are involved in both and neither is well respected( which has
nothing to do with reliability).
2. He speaks of Redundant Networks of different grades of service. Two
issues:
A. In a world where it takes multiple organisations to build one grid,
Where do we find the organizations to build these additional grids?
B. In the WEST, where do we find the redundant paths for these grids
without destroying the environment that many of us came west for?
3. In your competitive model, who fixes the following situation which is
necessary and too, too common. A young lady goes to visit a friend living in
a hillside home. After the visit, she loses control of her van and crashes
the power pole that supplies power to my house (among many others). Power to
our neighborhood is out for 17 hours. The pole must be replaced, crews work
all night, and service is finally restored. Who's going to do the job in
your model? This is real life, last Friday to be exact.
The abbreviation "CPU" should read "DPU". 8 hours downtime per year is about 99.9% reliable, not 99% as I had said. My thanks to Dr. Marty Ryba of MIT for catching this. Paul Green, Stratus Computer ["DPU" corrected in SRI archive copy. PGN]
Mike Crawford submitted in RISKS-18.28 an apparently doubly-forwarded item about a cleaner in a South African hospital unplugging a life-support system every Friday to plug in her floor polisher. I found the news item on the Web site of the Cape Times. It was changed considerably by the time of its appearance in RISKS: somewhere along the line, implausible bits about the "screams and death rattle" of the victims and about a hospital spokesperson "sending a strong letter to the cleaner" was added. The original said only that a hospital spokesperson denied knowledge of the incident, and that only one of the deaths (all of which happened two years ago) was under investigation by the Free State Health and Welfare Department. The item was also at an odd location in the Independent Online Webspace: http://www.inc.co.za/online/news/editorial/film_reviews/topmovies.html. I'm dubious. Prabhakar Ragde, Department of Computer Science, Univ. Waterloo, Waterloo, Ontario CANADA N2L 3G1 (519)888-4567,x4660 http://plg.uwaterloo.ca/~plragde
Michael D. Crawford writes: > I don't know if this is true, but it sounds plausible. It has the ring of urban legend to me. If a hospital was losing people every Friday, don't you think they would fairly quickly set up a watch on that bed? Also, if the deaths had really happened and the mistake admitted as readily as quoted, one suspects that there would be lots of news stories about the subsequent lawsuits. Geoff Kuenning g.kuenning@ieee.org http://fmg-www.cs.ucla.edu/geoff/
> I don't know if this is true, but it sounds plausible. > [Similar cases have been reported previously in the RISKS archives.] Oh, it happens, although not necessarily with such consequences. I happened to be in the office recently unplugged the UNIX box next to mine in order to plug the vacuum in. "Oh, did I unplug something?" she asked, in apparent surprise. Gurgle. Are there really places that put power cables into sockets, just to keep the sockets free of dust, or what? steve
Excerpt from http://sspg1.bnsc.rl.ac.uk/Share/ISTP/ariane5rep.htm [...] The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher. This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine. These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data. The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception. The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds period) for the same reason as SRI 2. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. [...]
The inquiry board investigating the loss of the first Ariane 5 launcher has presented its conclusions. I have not seen the actual report of the board, but I have access to an official summary. Even the summary is a rather lengthy document, so I have extracted the parts which directly concern the sequence of events, and the causes of the failure. The extracts are verbatim, except for my possible typos. - During the launch preparations and the count-down no events occurred which were related to the failure. The meteorological conditions were acceptable, and no other external factors have been found to be of relevance. - At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer within the back-up inertial reference system, which was working on stand-by for guidance and attitude control, became inoperative. This was caused by an internal variable related to the horizontal velocity of the launcher exceeding a limit which existed in the software of this computer. - Approx. 0.05 seconds later the active inertial reference system, identical to the back-up system in hardware and software, failed for the same reason. Since the back-up inertial system was already inoperative, correct guidance and attitude information could no longer be obtained and loss of the mission was inevitable. - As a result of its failure, the active inertial reference system transmitted essentially diagnostic information to the launcher's main computer, where it was interpreted as flight data and used for flight control calculations. - On the basis of those calculations, the main computer commanded the booster nozzles, and somewhat later the main engine nozzles also, to make a large correction for an attitude deviation that had not occurred. - A rapid change of attitude occurred which caused the launcher to disintegrate at 39 seconds after H0 due to aerodynamic forces. - Destruction was automatically initiated upon disintegration, as designed, at an altitude of 4 km and a distance of 1 km from the launch pad. - The inertial system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. The realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off. - During design of the software of the inertial reference system used for Ariane 4 and Ariane 5, a decision was taken that it was not necessary to protect the inertial system computer from being made inoperative by an excessive value of the variable related to the horizontal velocity, a protection which was provided for several other variables of the alignment software. When taking this design decision, it was not analyzed or fully understood which values this particular variable might assume when the alignment software was allowed to operate after lift-off. - In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software. - Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up of horizontal velocity which is five times more rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the 40-second timeframe, the excessive value which caused the inertial system to cease operation. - The specification of the inertial reference system and the tests performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently the realignment function was not tested under simulated Ariane 5 flight conditions, and the design error was not discovered. - Post-flight simulations have been carried out on a computer with software of the inertial reference system and with a simulated environment, including the actual trajectory data from the Ariane 501 flight. These simulations have faithfully reproduced the chain of events leading to the failure of the inertial reference systems.
Please report problems with the web pages to the maintainer