At the RISK of turning this into a comp.risks.elevators forum, I have some further information on Eric Roskos' contribution: | The elevators are "Otis Elevonic 401" elevators. They appear to be | microprocessor controlled; they have voice synthesizers that announce | the floors, and scrolling text displays that give advertisements about | the stores downstairs, the date and time of day, etc. [ Troubles deleted ] Yup - those are the ones in our building too. While I haven't noticed those specific troubles, there are others. They tend to cancel all calls when more than three are selected, but there is one idiosyncrasy that I find disturbing. I have a little hand-held (amateur) transceiver, generating just 3 watts on 147 MHz from a "rubber duck" antenna - very inefficient. When I'm in the mood, I trigger it next to various bits of electronic equipment, just to test their RF susceptibility. Imagine my surprise when the lift doors immediately flew open (when closing), and a sepulchral voice announces "Do not be alarmed. We are experiencing a temporary malfunction." Obviously, immunity to relatively weak RF fields was not a design issue. I also get worried when their fancy flourescent display goes bizarre. I would hope that it is being driven by a slave computer, not the main control processor... I can always avoid the lifts, but 11 floors is a long way to climb the stairs. Dave Horsfall (VK2KFU), Alcatel STC Australia, email@example.com dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave
In RISKS 8:53, Patrick Wolfe describes the consequences of his misunderstanding an error message on his PC. The message, "use NET START RDR hostname", was intended to mean "Issue the command 'NET START RDR hostname', substituting the name of your PC for 'hostname'." But he interpreted "hostname" to mean the name of the host to which the PC was connected, i.e., the network server, and the effect was to bring down a multiuser BSD UNIX host. He concludes: > The risks should be obvious. System Managers should not be allowed > to touch PCs without re-reading the manuals first. :-} I draw a different and more enforceable conclusion: ERROR MESSAGES SHOULD BE UNAMBIGUOUS, ESPECIALLY WHEN THEY TELL THE USER TO DO SOMETHING (or can be interpreted to do so). Documentation is probably still the least-regarded aspect of software production and maintenance, but it's the user's key to the product. — Mark Mandel
From "Eavesdropping Left and Right" in _The Nation_ of April 17, 1989, by Gregory Flannery, reporter for the _Mt. Washington Press_, Cincinnati, Ohio. '... In 1979, [Cincinnati Bell's security coordinator James] West allegedly ordered a wiretap on lines serving vote-counting computers at the Hamilton County Board of Elections. As ballots were being tabulated on election night, the computer shut down for two hours. "About 8:30 ... election evening, Mr. West called me," [Cincinnati Bell installer and supervisor Leonard] Gates says. "He said we had done something to screw up the voting processor down there. He said, 'You must have done something wrong.'" Gates has testified that West told him the computer wiretap could be used to alter votes, but no evidence of such tampering has been produced to date ...' The article also discusses other allegations which are part of a $112 million dollar class-action suit accusing Cincinnati Bell of selling information gathered through illegal wiretaps on client telephone lines. -Brad Sherman (bks@ALFA.Berkeley.Edu)
Apropos the recent claim that, though a computer may be wrong, it is not trying to defraud you — I know of a system where the computer was programmed to defraud consumers. A large pie manufacturing company introduced microprocessor-controlled production lines at the end of the 1970's. The system dispensed the appropriate weight of filling into each pie. State law allowed for human inaccuracy in pie fillings - if the pie was a "4oz" pie, the bakers were permitted to range from 3.5 to 4.5oz. The bakers were thrilled with the supreme accuracy of the new system, and set it to dispense at the lower limit instead of the nominal weight, all the time. As far as I know this dishonesty continued unchecked, and it is permitted because the computer system allows an accuracy hitherto unobtainable.
On the subject of people taking the computer's word as infallible... did anyone else catch "Perry Mason: The Case of the Musical Murder" on NBC Sunday night? Late in the show, after our hero Mr. Mason has figured out that his client is innocent and the witness currently on the stand is the murderer, he begins to question the witness as to his whereabouts. The questioning goes something like: Q: Where were you on the night of the murder at 2:30am? A: In my room doing script revisions. Q: How long were you workong on the script revisions? A: All night. Q: You use a word processor to work on the script, right? A: Yes. Q: Does the word processor put the date and time on the files you modify? A: I don't know. [Mason pulls out a directory listing from the fellow's computer...] Q: Now, next to the file "Polly", what time is shown? A: 1:35am Q: So you weren't working on the script during the time of the murder, you finished working on it much earlier? A: Yes. And of course, the witness breaks down on the stand and confesses. Now, granted, one can argue that it's "only television" or "just meant as entertainment". But judging by the idiotic things I've heard argued based on "I saw it on [fictional show of your choice]", I suspect a lot of people take this stuff as gospel... Anyway, the show demonstrates the fallacy of assuming that since the information came from a computer, it is somehow ennobled, and nobody dares to question it. It apparently never occurred to these people that the time of day clock on the computer could have been wrong for some reason. For example, the Compaq we have here for an Ethernet analyzer comes up with some random date and time every time we turn it on. It does not even prompt for the correct time (since we don't really care), one has to remember explicitly to set it (and we never bother). In fact, on most MS-DOS systems I'm aware of, just pressing RETURN gets you through the time/date stuff without ever having to set it correctly. And as another example, Sun "generic" kernels come using the Pacific Standard time zone... how many people don't bother to change it, or just stuff the current time in without changing the time zone? And as still a third example... how many systems out there use the "old" rules for daylight savings time conversions? They would have the wrong time for a week or so unless someone fixed it manually... If I were the guy on the stand, I would have denied it all and forced Mason to prove that the time of day clock on the computer was correct at the time I last edited that file. --Dave Curry
Jerry Saltzer wrote that no old-time pilot would consider taking off without personally verifying the fuel load in the plane, either by looking at it, touching it, or dipping something in it. As a not-so-old-time pilot (though expecting one day to be one), I can say that most of us general aviation pilots (and all of us GA pilots with whom I'll personally fly) STILL verify the fuel load. Fuel gauges, especially in general aviation aircraft, are NOTORIOUSLY inaccurate. I will not fly a GA plane without having eye-balled or thumbed or dipped the fuel tanks, regardless of rain, high-wing plane with no ladder, or whatever. Indeed, many airliners fly without this precaution. "An extraordinary pilot uses his or her extraordinary judgement to avoid having to use his or her extraordinary skills." - Alan
Henry Spencer wrote that aviations regulations state that the "ultimate authority and responsibility rest with the pilot, nobody else." Whereas this is certainly true in general aviation, this is NOT true in air carrier operations. In air carrier operations, there is a division of labor, where many people other than the pilot in command are responsible for, and have authority as to, various aspects of a flight. Now, once airborn, it's the pilot's word that goes. Period. However, while on the ground, during loading and dispatch and such, various ground crew members have authority and responsibility. Of course, it's not THEIR necks on the line in the sky.... - Alan
>"If a pilot has to make violent changes to the aircraft's attitude >in an emergency, then the computer will prevent the pilot pushing it >past design strengths. For example, the computer would prevent the pilot >putting it into a dive that might break off the tail." In a past issue of the "Aviation Safety Digest", published (then) by the Bureau of Air Safety Investigation, part of the Australian Department of Name Changes (the Civil Aviation Authority this month) was the following incident report. [From memory] A single engine light aircraft was flying in heavy cloud and moderate turbulence when it apparently entered a thunderstorm cell. A severe downdraught caused an abrupt descent, followed by wind shear causing a stall, and further descent. The pilot broke free from the base of the cloud, still descending, and saw lots of trees. He pulled back VERY HARD on the controls, recovered control of the aircraft, but felt it was performing strangely, so he landed at the first opportunity. Subsequent examination of the aircraft showed: a) eucalyptus leaves in the undercarriage, presumably from tree skimming. b) the wings had undergone permanent deformation, with the tips being now some 30cm higher than normal. The main spar had bent in two places. This was attributed to 'G' forces in excess of the flight envelope of the aircraft. Now my point: had this been a fly-by-wire aircraft, it would presumably never have been overstressed. The fact that it (and the pilot) would be in little pieces in a rainforest is, however, depressing. The pilot reacted correctly, in that he was "between a rock and a hard place", and chose between certain death due to trees, versus probable death due to airframe failure in flight. He was VERY lucky to come out of this at all, but how would a computer judge between these extremes? (Note that even if the aircraft had had a radar altimeter it would have been hard pressed to tell the height of the treetops. If the flight computer had tried to pull out more gracefully it might still have been an unhappy ending.) The simple answer is "If it had fly-by-wire, it would have had weather radar, and this would never have happened". True, but to me, irrelevant. The manufacturers of aircraft build in a healthy safety margin, which in this case saved a life. But there are at least three choices with a FBW system: 1. Allow the computer to fly to the "real" (no safety margin) limit, on the grounds that you can trust it more than a human. 2. restrict it to the same performance limitations as you would certify if there was no FBW. 3. Forget these safety margins entirely, independent of FBW installations. I don't like any of the above options. (2) would have killed the pilot above, (1) and (3) are quite similar in end effect, and could see us with a rash of airframe failures due to manufacturing tolerances, corrosion, or miscalculation on the part of the engineers (or their software). As has been pointed out elsewhere, extreme circumstances do happen, and can sometimes be rectified by humans. Aside: Harry Harrison, in "Deathworld" written in the mid-sixties, has the hero escape captivity in a spaceship's lifeboat only to crash because the controlling computer won't pull out of a dive quickly enough.
I think it is only fair to mention that using SUBMIT_JOB is just one way of submitting a batch job, and, indeed, NOT the way that our User Services group teaches our users. It took me an hour to find the text that was quoted above, in an older version of a printed manual dated April 1988. In the current version of NOS/VE the JOB/JOBEND construct is what the casual user first sees when reading about batch jobs - this method of submitting batch jobs inherits validation information from the parent job and thus there are no plain text passwords. The primary purpose of SUBMIT_JOB is to run jobs on OTHER machines..... Steve Lidie, Lehigh University Computing Center
San Francisco Chronicle, Chronicle Wire Services, April 11, 1989: "Computer Group Wary of Security Agency A public interest group said yesterday that the National Security Agency, the nation's biggest intelligence agency, could exert excessive control over a program to strengthen the security of computer systems throughout the federal government. The group, Computer Professionals for Social Responsibility - based in Palo Alto - urged key members of Congress to focus "particularly close scrutiny" on the agency's role in helping to implement legislation aimed at safeguarding sensitive but unclassified information in federal computers. "There is a constant risk that the federal agencies, under the guise of enhancing computer security, may find their programs - to the extent that they rely upon computer systems - increasingly under the supervision of the largest and most secretive intelligence organization in the country," it said."
In RISKS 8:52, David M. Gursky wonders about the legality (constitutionality, enforceability) of California's new law against (unsolicited) junk fax, and ends with > Of course, this whole message begs the question "How is this a risk > to society?" Junk fax is just as much a menace as junk phone calls that seize the line and won't let go. While junk mail just fills up your mailbox, it doesn't deprive you of legitimate mail unless it piles up to the very top. Junk fax, as long as it's coming in, ties up your machine and makes it impossible for legitimate transmissions to reach you. — Mark Mandel
Please report problems with the web pages to the maintainer