Subject: RISKS DIGEST 12.47 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 10 October 1991 Volume 12 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Ex-DMV worker admits altering driving records for money (Vireday) Software migration at Johnson Space Center (Joe Bouchard) European Ideal Embraces Harmonised Pornography (Brian Randell) Prison Phone Phraud (or The RISKS of Spanish) (Jim Flanagan) "Peace Patent" and "Colossus: The Forbin Project" (Lauren Weinstein) UCSC to install touch-tone registration (HELP WANTED) (Darrell Long) Re: Ada Code Formatters (... old software) (David Parnas) Re: Encryption Exportability, by Clark Weissman (Carl Ellison) Re: Fiber optics can spontaneously destroy themselves! (Paul Leyland) Re: Safer flying through fly-by-wire (Randal L. Schwartz) Re: ``Friendly'' (?) viruses (Bertrand Meyer) Re: AT&T Outages (Peter G. Rose) Re: RISKS of Highway warning signs (Steven Philipson, Arthur Hamlin, Richard Thomsen, Bob Haar, Keith Henson) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Thu, 10 Oct 91 08:39:32 PDT From: rvireday@pldote.intel.com (~Vireday) Subject: Ex-DMV worker admits altering driving records for money Excerpts from "The Sacramento Bee", Friday, October 4, 1991. The RISKS are more than obvious. (Didn't something similar already happen in Great Britain?) It is not explained how they found out about the alterations. Probably followed a paper trail, or discrepencies in backup logs. If that is so, what about all these pen-point computers about to hit the cop market? Will this increase the risk of losing this kind of "evidence"? Ex-DMV worker admits altering driving records for money A former technician for the [California] Department of Motor Vehicles admitted in court Thursday that she deleted bad driving records of a number of individuals who had paid for the service. Genevieve Pamela Lopez, pleaded guilty to 10 counts of illegally using the DMV computer for the purpose of altering, damaging or destroying data. Nineteen additional counts were dismissed. Proceedings against her co-defendant, Donald H. Stables, were continued to Oct. 24. He is charged with 48 counts involving computer fraud, bribery, falsification of government documents and conspiracy. According to court records, Stables, an insurance agent in Yreka, allegedly had been receiving fees of up to $2500 to arrange the obliteration of accident reports, drunken-driving arrests, suspensions and other violations on his clients' DMV records. Lopez was his contact at the department, according to documents, and she received between $400 and $500 for each transaction. ... [The plea bargain terms Lopez has arranged are six years of formal probation, 60 days in the county jail, a fine of $10,000, and to testify against Stables if need be.] ------------------------------ Date: 9 Oct 91 17:48:31 CDT (Wed) From: texsun.Central!ioscc!bouchard@fernwood.UUCP (Joe Bouchard) Subject: Software migration at Johnson Space Center The managers at NASA/JSC (Johnson Space Center, Houston, TX) seem to be underestimating the RISKS associated with migrating a mature software product to a completely new environment. There is a move afoot to migrate the SMS (Shuttle Mission Simulator) from the Unisys 1100/90 - Perkin Elmer 8/16 equipment it's currently running on to another platform (not completely defined yet). The reasons for doing the migration sound something like "we need to get off that old mainframe equipment and into the modern age of Unix, multiple workstations, etc. Or maybe an modern (IBM) mainframe." The justification for going through the effort (and believe me, it's going to be monumental) is improved uptime due to improved hardware and software reliability, ease in implementing changes, and performance (the 1100 it's on doesn't have a high MIP rating, and we all know how truly useful MIPs are to compare dissimilar hardware/software). Upgrading the current equipment and/or software environment is not currently being considered seriously (Unisys isn't POPULAR with the big wigs at JSC, IBM & Unix anything are). Problem one: the numbers being used to do the justification seem to be largely imaginary (I'm not close enough to the project to tell for sure). Sort of ... "Everyone knows that mainframes are unreliable and workstations are good. Rate the mainframe 10 failures per ?? (based on real data) and rate the workstation system 3 per ?? (based on who knows?). This will save us big $$$." Even if the numbers are based in something resembling a scientific study, they are likely to be based on MATURE systems. Anyone who has been through a major conversion effort can tell you just how long it takes to get millions of lines of real-time simulation software to the same maturity on another box, especially a very different kind of box (the Shuttle may be retired by then). At the time SMS was developed (more than 12 years ago), Univac (later Sperry, later Unisys) was the only vendor that had developed real time software processing to a sufficient maturity on a large enough box to get the job done (I believe they were the only ones to complete the pilot project successfully, but I wasn't around then). Since then, the software has undergone extensive growth. This system is complicated to the point that moving it to another platform will be practically as difficult as redeveloping it from scratch. Problem two: none of the destination systems being discussed have demonstrated that kind of real-time software processing capability. Problem three: none (or almost none) of the programmers currently working on SMS has any experience with any of the new systems. There is a gigantic risk in going from the known into the unknown. This risk is unjustifiable when significant improvements can be made in the current environment. Unisys 1100-series equipment, from the smallest (2200/100, desk sized small business system) to the largest (2200/600, big mainframe), runs the same software across the entire line with NO modifications required. Such a large range of compatible processing power is unavailable from any other vendor (the Unisys A-series has a somewhat wider range). Since the initial development of SMS, the capabilities of both the hardware and system software of the 1100-series has expanded tremendously. Upgrading SMS to take advantage of these improvements would be much less risky than moving to another platform, but the lack of popularity of Unisys at JSC prevents it. (Another of those political correctness things. Also a result of the government contractor environment. "We hired you to do what we tell you to do and nothing else.") And all this at public expense without much accountability. NOTE: I have been doing System Software support on 1100-series computers for about 10 years and can't claim to be entirely unbiased. I have done programming on both personal computers (Apple, Commodore, IBM, etc.) and mainframes (Honeywell, Unisys 1100/2200, some IBM), so I have an idea what it takes to move conventional systems from one box/environment to another. I don't think the management at NASA does. ------------------------------ Date: Thu, 10 Oct 91 09:32:14 BST From: Brian.Randell@newcastle.ac.uk Subject: European Ideal Embraces Harmonised Pornography [The risks entailed in the attached article, quoted in full from the front page of today's Independent, are perhaps not so much computer-related as commission-related, but I thought I would "share them" (to use an American phrase which always grates somewhat on British ears :-) with RISKS readers. Brian Randell, Computing Laboratory, The University, Newcastle upon Tyne, NE1 7RU, UK PHONE = +44 91 222 7923 FAX = +44 91 222 8232] European Ideal Embraces Harmonised Pornography, by Andrew Marshall, West Europe Editor The European Community has a new crusade: high technology pornography. EC commissioner Filipo Maria Pandolfi told the European Parliament in a letter yesterday that the Commission is working on a code of conduct for the sex industry. Mr Pandolfi is the Telecommunications Commissioner, and does not usually get involved with below-the-waist activities in a professional capacity. But the modern pornographer is increasingly dependent on modems and multiplexes [sic] rather than plain brown envelopes and hand-wound peepshow machines. And when Brussels hears the word "hi-tech", it reaches for a directive. "Such a Code of conduct would state ... rules for the information industry ... and administer the provision of information services of a pornographic nature," says Mr Pandolfi's letter. The pornography industry, as well as simple telephone chat lines and recorded messages, has now developed much more complicated ways of sending pornographic images along the line. Regulating these is something of a problem for old-fashioned vice cops. But when different individual member states develop different approaches, this can interfere with more legitimate business activities. So part of Mr Pandolfi's mission is to ensure that Nation shall speak dirty unto Nation, because, as the Commission puts it, "discrepancies between existing national regulations constitute a problem in establishing a common market for information services". Let nobody keep apart heavy breathers in Croydon and Cologne, lest they disrupt the single internal market. Perhaps the commission is not aware of the risks in opening Pandolfi's box. Will pornography have to be standardised, with French maid's uniforms compulsory? Will there be heavily-subsidised industrial national champions in pornography, allowing the Dirty Old Man to represent Euro-frotteurs? Must Naughty Fifi Tell All in eight languages? ------------------------------ Date: Thu, 10 Oct 91 16:51:16 -0700 From: Jim Flanagan Subject: Prison Phone Phraud (or The RISKS of Spanish) This notice appeared in the University of Washington staff newspaper University Week: PHONE FRAUD It recently was discovered that inmates from the Clallam Correctional Center in Clallam Bay, WA have been using an automated phone system to try to scam unsuspecting employees at the UW. Fone America, the long-distance provider for the correctional center, supplies anautomated service for collect calls. Inmates are supposed to make recordings of their names to identify themselves to the called parties. A recording should say, "If you will accept a collect call from...(name of caller)...please press the number 3 on your telephone twice" Fone America also supplies the same automates message in Spanish. In the scam, inmates chose the Spanish option and record, in place of their names "If you want to hear this message in English, press 33." They then call a number at the UW an try to reach employees who will press 33 which automatically accepts the collect calls. If the inmates get through, they ask to be transferred to the outside operator or to the switchboard operator. They will then attempt tp place long distance calls and have them billed to campus phones. Since late July, this scam has occourred a number of times. It is important for University employees to recognize this or similar phone scams. [The notice goes on to suggest ways to minimize the impact of phone fraud] Jim Flanagan, Systems Programmer, UofW Statistics flanagan@stat.washington.edu ------------------------------ Date: Wed, 9 Oct 91 12:08:02 PDT From: lauren@vortex.com (Lauren Weinstein) Subject: "Peace Patent" and "Colossus: The Forbin Project" Yes, indeed, the described "peace patent" is similar in some respects to the basic concept behind the semi-classic film "Colossus: The Forbin Project" (1970). In the film, both the US and USSR put into place master control computers to manage their nuclear arsenals. Gimmick: the systems cannot be turned off or disconnected (similar to 'The Doomsday Machine' from "Dr. Strangelove") without blowing everything up. The US computer (Colossus) realizes that there must be a Soviet computer (Guardian) and demands a hookup (TCP/IP? OSI?). Classic line: "There is another system." Both sides let their computers talk for awhile. There's an amusing sequence where the two systems, starting with 0 and 1, build up a vocabulary and rapidly increase the data rate. The humans watching have an increasingly difficult time keeping track of what the machines are saying to each other as the rate increases. Suddenly, the machines shift to a completely unknown protocol and coding, and the humans have no idea what is going on between the machines. They panic, and pull the plug on the connection. Colossus (we see all this from the US side) tries for a while to get a circuit back to Guardian over various cable and satellite systems. He can't. He then simply demands that the circuit be restored, or else he'll fire a missile. In fact, as I recall he does just that, as does Guardian. The warheads are only destroyed (how?) when the humans restore the link. There are a lot more goings on, including various other attempts to disconnect the computers or disarm the warheads. All fail. The film ends with Colossus and Guardian in total control of the world, and humans relegated to a position of being, essentially, slaves to the machines. --Lauren-- ------------------------------ Date: Thu, 10 Oct 91 14:57:20 -0700 From: darrell@cse.ucsc.edu Subject: UCSC to install touch-tone registration UC Santa Cruz is going to install a touch-tone registration system. Here's your chance to prevent a RISK before it occurs. Please send me any RISKS that you know of in such a system. Also, pointers to relevant back-issues of RISKS will be appreciated. Thanks, DL [Responses to DL, PLEASE!!! PGN] ------------------------------ Date: Wed, 9 Oct 91 16:06:57 EDT From: David Parnas Subject: Re: Ada Code Formatters (... old software) (Mitchell, RISKS-12.45) Kent Mitchell indicates that a bug in his company's products has been corrected and that it is no longer a problem. He then goes on to say, "Perhaps the real risk here is using old, out of date software." Others might say, "Perhaps the real risk here is prematurely released software, software that is released before adequate validation". How long can we go on acting as if it is OK to release buggy software as long as we fix it (for an extra charge of course) later. David L. Parnas parnas@sscvax.cis.mcmaster.ca ------------------------------ Date: Thu, 10 Oct 91 14:28:52 EDT From: cme@ellisun.sw.stratus.com (Carl Ellison) Subject: Re: Encryption Exportability, by Clark Weissman (RISKS-12.46) >The U.S. finds itself in a dilemma: harm our economic growth and competitiveness in the expanding world internet products and services industries if we prohibit cryptographic applications, or permit such cryptographic export and potentially weaken military security by providing new encryption capabilities to our adversaries. I have heard this argument multiple times and I find it bogus. This argument assumes that we in the US are in a leadership position in the development of encryption products so that if we ship products, our adversaries will get something they can't get elsewhere. It's doubtful that this has ever been true, except possibly for the top of the line NSA black boxes -- but that's not what we're talking about controlling, here. We're talking about the products of US private industries. Crypto AG in Switzerland isn't waiting for the US to permit exports. They have been producing high quality equipment for decades and will continue to do so. Other companies are starting up to produce and sell cryptographic equipment. Therefore, to me there is only one side to this argument: if we prohibit export, we limit the US competitiveness, while our adversaries get equipment and algorithms at least as good as they might buy indirectly from us, but from other countries. Meanwhile, the thwarting of US industrial development of cryptographic applications and equipment leads to an atrophy of ability in US industries so that even we will have to buy equipment from outside this country. The last time I looked at smart card cryptography, it was all produced in Europe, for example. Is this going to be another case of the USA losing out completely on a market -- ala VCRs? My guess is that it already is -- thanks to at least a decade of restrictions. My remaining question is whether we have any chance to catch up, assuming we do a rapid and firm about-face in policy immediately. ------------------------------ Date: Thu, 10 Oct 91 10:51:18 +0100 From: Paul Leyland Subject: Re: Fiber optics can spontaneously destroy themselves! (RISKS-12.44) > It turns out that a fiber optic in an environment "where the temperature can suddenly increase" can result in the complete destruction of a fiber optic in what is known as a fiber "fuse" effect. "For certain types of optical fibers...damage can occur when the visible-light laser power transmitted... is as low as 4 milliwatts..." I'm surprised that a power of 4mW can destroy a fibre. Ten years ago, I was a practising spectroscopist. Several times I saw a fibre melting away in an upstream direction. The output end of the fibre had become dirty and absorbed the laser light; the fibre's tip melted, ensuring that light continued to be absorbed. The big difference, though, was that we were pumping anything up to 10 WATTS through a 150 micron fibre. Admittedly, this was 514.5nm Ar+ light, rather than the red and near IR used in telecommunications, but as glass is more opaque in the green than near IR, I'd expect greater problems with Ar+. I *never* saw a fibre burning away when less than several watts were being transmitted. If we calculate the power densities involved, 10 watts through 150\mu is a power density of 566MW m-2; 4mW through the same fibre is 226kW m-2. For comparison purposes, a typical electric fire element (in this country at least) radiates 1kW from an area of 0.01 m-2 (assuming a length of 30cm and a diameter of 1cm) for a power density of 100kW m-2. It glows dull red-orange. Hmm, I suppose that 200kW m-2 might melt a fibre if the laser light were converted to heat with high efficiency. Paul ------------------------------ Date: Thu, 10 Oct 91 09:39:28 PDT From: merlyn@iwarp.intel.com (Randal L. Schwartz) Subject: Re: Safer flying through fly-by-wire (Spencer, RISKS-12.45) > The USAF/NASA Advanced Fighter Technology Integration test aircraft is doing flight evaluations of a system to help pilots cope with disorientation: push a button on the stick and the computer automatically brings the aircraft back to level flight. But level flight based on what indications? Every IFR pilot is taught to "right" herself based on the array of gauges visible on the panel, and must do so with demonstrable proficiency before being signed off to "bore holes in the clouds". But we are also taught to cross-check... does the Artificial Horizon "make sense" compared to the changes in Altimeter and Heading? Does the Rate-of-turn indicator cross-check with that? I can't see how this device is better than your basically-trained IFR pilot, and it may be worse (mortal failures under strange instrument failure modes). Randal L. Schwartz, PP-ASEL-IA, 260+ hours and climbing... ------------------------------ Date: Thu, 10 Oct 91 12:35:23 PDT From: bertrand@eiffel.com (Bertrand Meyer @ Interactive Software Engineering Inc.) Subject: Re: ``Friendly'' (?) viruses (Smee, RISKS-12.45) `` It is an (at least) antisocial act to cause anything to run on my machine without my knowledge, and with no action on my part to indicate that I want it. I cannot think of ANY useful piece of software of ANY sort [...] which does not have the potential for screwing things up amazingly in SOME contexts.'' Although I see no reason to disagree in principle, it may be worth pointing out that this statement, taken literally, is too strong to reflect the reality of even the most common computer systems, which DO execute things without explicit actions from their owners and users. Most people reading this use a machine running Unix. Somewhere in its file system (usually /usr/spool/cron or /var/spool/cron) there is a directory `crontabs' containing files which describe actions to be executed regularly without explicit user action. In particular, the file `root' describes actions to be executed by the `root' id, that is to say, with all possible privileges. Such mechanisms, if used well, are essential to the proper functioning of the system. For example some typical `cron' actions remove unneeded or old files. For one thing, news wouldn't work without cron, since the flow of incoming messages would quickly fill out all available disk space. Neither would mail work without the help of some programs, running automatically (the Unix name, ``daemon'', is suggestive enough), which do a few things on their own, such as checking the incoming mail queue every now and then. One may argue that there is implicit ``action on the owner's part'', using Mr. Smee's words: by accepting to use the machine, you accept its standard cron mechanisms and mail daemons; furthermore, you may login as `root' and disable the daemons and cron actions that you don't like. But most people probably just leave the software as it was when the machine was installed, and as Unix reaches the masses there will be more and more users who don't even know about the existence of cron and daemons. So in effect the operating system IS performing, behind the user's back, actions which may directly affect his property (files, electronic mail etc.). It's a little like signing an agreement letting a supplier or employer make direct drafts from your bank account: sure, you did perform one ``explicit action'' when you authorized it, but it still opens more risks than if you have to authorize each operation individually. So while I agree with Mr. Smee and other posters about the oxymoronic nature of ``friendly virus'', I think the technical situation is a little more complex than his statement would suggest. It also seems that an automatic or semi-automatic bug correction service, working somewhat in the style of mail and news (that is to say, updating remote files in controlled conditions) wouldn't be such an absurdity as he suggests. I can see why some user sites might want to subscribe (voluntarily, of course!) to such a service if it is technically well-done and has the proper safeguards. (Maybe something like that already exists.) After all, those of us who can read this still use mail and news in spite of the Internet worm and of the potential for further abuses of the same kind. Bertrand Meyer bertrand@eiffel.com ------------------------------ Date: Wed, 09 Oct 91 15:52:32 EDT From: "Peter G. Rose" Subject: AT&T Outages Some people seem to want to blame human weaknesses for the AT&T failure, other people seem to want to blame the technology. What I havan't seen anyone point out is that, every time AT&T (or most other people) does something to "improve" their system, they end up more and more centralized. Fundamental rule of designing things: "Sooner or later, EVERYTHING breaks." If you don't what catastrophic failures, you need to arrange things so that the inevitable failures aren't catastrophic. Why is so much vital traffic being routed through a single installation? What are they planning to to when a fire, plane crash, flood, or terrorist action takes out that entire building? Why is the control network dependant solely on AT&T, when anyone with any sense could predict that sooner or later, that service isn't going to be there? P.Rose (LCO114@URIACC.URI.EDU) ------------------------------ Date: Wed, 9 Oct 91 14:29:12 -0700 From: stevenp@kodak.pa.dec.com (Steven Philipson) Subject: Re: RISKS of Highway warning signs (RISKS-12.45) Several persons commented that the cause of the accident was not that the signs were not working, but rather that the truck driver was not paying attention. The inattentiveness of the driver may have been the most significant factor, but the failure of the signs is also significant. The driver may have had an expectation that the warning signs were operating. Lack of the warning contributes to lower attentiveness. This phenomenon has a name -- primary/backup inversion. The driver should have been more attentive, but warning systems do tend to make people less attentive. Designers must keep this in mind when developing warning and backup systems. This accident clearly falls in the category of a "system accident" -- multiple factors in a complex system (including surface traffic, river traffic, drawbridges, warning systems, rules of operation, working hours) collectively contributed to the outcome. Charles Perrow's _Normal Accidents_ discusses system accidents in detail. It is well worth reading. Steve Philipson ------------------------------ Date: Thu, 10 Oct 91 10:41:25 EDT From: hamlin@codex.com (Arthur Hamlin) Subject: Re: RISKS of Highway warning signs (Flory, RISKS-12.45) >The was no risk here because the signs weren't working. The risk was the truck driver obviously driving recklessly. There's too much of a tendency to blame something or someone else when things happen. Bottom line is, if the trucker had been driving safely, the accident WOULD NOT HAVE HAPPENED, sign or no sign. Unless you have additional information about the accident, I must disagree. If I am on an unfamiliar highway, it is up to the maintainers of the highway to "tell" me how to drive it safely. This includes speed limits, warnings about hazards, and information about what is ahead. There is a section of a Rt 9 in Mass. that has a stop light just over the top of a hill. You can't see it as you come up the hill, but only as you come over the top. The speed limit on this road is 45mph, far too fast to react to one or more stopped cars at a red light. The town put up a permanent sign clearly stating that there was a stop light over the hill and that cars may be stopped at it. This warning has worked very well. However, several miles down the road, in a different town, they use an electronic sign that only turns on when the light is RED. The idea being that if the light is green and there are no cars backed up, there is no danger, so no need to slow down. Assuming that the sign goes on and off correctly, ( including time delays after cycling to allow a backup to disperse ) this will work fine. But as soon as the electronic board fails, THERE IS NO WARNING. A driver not knowing the road would go 45mph, ( the posted "safe" speed ) having no reason to think that there is any problems ahead, and smash into the cars backed up at the red light. A driver who knows the road would assume that the sign would warn him if there was a backup, so he too would be in danger. ( I'll grant you that this driver should be going a little slower over the hill because he knows that there is a potential problem ) If all drivers drove as if they had to be able to stop on a dime at all times, cars could not be a pratical form of transportation. Drivers rely upon the maintainers of the highways to tell them what the risk level of the road they driving is, so that they can then drive "safely". The Wizard of AHs P.S. Some places use a permanent painted sign that warns of the danger all the time, and the electronic lighted sign obscures it when it is on. Therefore, in the case of failure, the warning is up. Sort of like four way stop signs at an intersection with lights. ------------------------------ Date: Thu, 10 Oct 91 08:29:09 -0600 From: rgt@beta.lanl.gov (Richard Thomsen) Subject: RE: Liability risks of highway signs My uncle, who was a law lecturer at Cambridge, England, was telling me about liability risks. He said that sometimes if you put up a warning sign, then you are admitting that there is a hazzard, and so you are liable. However, if you say nothing, then you are not liable. Interesting cases. Richard Thomsen ------------------------------ Date: 9 Oct 91 21:07:53 GMT From: rhaar@gmr.com (Bob Haar) Subject: Re: RISKS of Highway warning signs (Hoffman, RISKS-12.44) Certainly, there are risks associated with the expectation that any warning devices will really function. But I have to lay blame for this accident on the truck driver. Whether or not the signs were operating with appropriate messages, the driver of any vehicle is responsible for operating it in a "reasonably safe" manner. This includes being able to stop the vehicle if there is an obstruction in the road. In this case, either the truck driver was not paying attention or he was driving too fast so that he couldn't stop when he did see the stopped traffic. There are many possible causes for an obstruction in the road that have nothing to do with the drawbridge. The warning signs would not have given notice of these. Robert Haar, Computer Science Dept., G.M. Research Laboratories ------------------------------ Date: Thu, 10 Oct 91 17:29:35 PDT From: hkhenson@cup.portal.com Subject: Warning systems While it would not have helped any on the recent ATT outage, a serious problem is trying to use people to backup machines--they get bored and nod off. Perhaps we need to have on purpose, unpredictable "false alarms" for people to respond to. I could eaisly design such a device to give a false warning at the sensor leads once a month or so. You could make pay, or rewards, or something dependent on taking corrective action, starting with reseting the signal. You might want an short term inhibit signal so that test alarms wouldn't pop up during a real emergency. Let's see, I have a year from this going out to file for a patent. :) Keith Henson [Well, this idea keeps coming up in RISKS, every time we have a problem with backup and emergency systems... PGN] ------------------------------ End of RISKS-FORUM Digest 12.47 ************************