Subject: RISKS DIGEST 16.52 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 31 October 1994 Volume 16 : Issue 52 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** Contents: [Apologies to those not included. This closes a few topics.] Telephone game glitch (Julian Meadow) The Sinking of the USS Gitarro (Mike Crawford) Re: FEC Voting "Standards" (Rebecca Mercuri) No Real Risks of Seemingly Similar Interfaces (Roger Carasso) There are risks and then there are risks (Alan Wexelblat) Re: Security screen (Bank fences, power keys, etc.) (Frederick B. Cohen) Re: More on backspace problems (Esther Filderman, Russell Stewart) CAPS-LOCK (Paul Barton-Davis, P. Kevin Parker, Rick Cook, Phil Keys, Doug Siebert) Re: AOL (Greg Lindahl, Mike Crawford) Re: Half a degree is better than none? (Curtis Jackson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 31 Oct 1994 16:54:14 +0000 (GMT) From: Julian Meadow Subject: Telephone game glitch Computer Lied When It Said All Callers Were Winners New Zealand's *Dominion* newspaper, 29 Oct 1994, The hundreds of people told they had won $100 after a glitch in the telephone TV Trivia game last weekend will not get the money. The telephone game began awarding $100 prizes to all callers during the weekend after a computer glitch caused by a power surge on Sunday evening. Callers said as soon as they pressed the number 1 on their telephones to start playing, a recorded message told them they had won. But News Media (Auckland), which runs TV Trivia, yesterday said it would not pay the estimated 500 callers. The company said it was quite satisfied that all the callers who rang the 0900 number during the weekend were aware of the nature of the game. The company said the game involved participants using their skill and knowledge and if they were successful, they were rewarded. It was not covered by the Gaming and Lotteries Act 1977. It was clear the 500 callers had not been asked any questions: they did not compete and so could not win. However, the company said it would reimburse the callers for the cost of their calls. The Consumers Institute said the legal issue was whether callers realised they were not playing the game properly. If they knew there was a glitch they would not have much of a case. ------------------------------ Date: Sun, 30 Oct 1994 00:02:42 -0700 From: Mike Crawford Subject: The Sinking of the USS Gitarro I just read the section on defense in *Computer-Related Risks* and was reminded of the following incidents: During 1967 and 1968 I lived on Mare Island Naval Shipyard, a submarine maintenance station just off the North end of San Francisco Bay, across a channel from Vallejo, California. Until recently most submarine repair (nuclear, conventional, attack and missile) for the Pacific fleet was done here; it has since been moved to Bremerton Washington; MINSY is being closed down. Sometime during 1968, the USS Gitarro (sp?) was being repaired. The front sonar cover was taken off, and a hatch was left open so the repair crew could get out to work on it. The Gitarro was floating in the water, raised high to expose the sonar to the air. A test engineer, who had nothing to do with the sonar people, wished to perform a test of some mechanism that required the submarine to be level. He went to the bridge (in the middle of the ship, far from the front) and let some water in the ballast tanks at one end of the ship, until the submarine was level, then closed off the tank... but he neglected to consider inertia. The submarine continued to settle for a bit after he closed the valve. He did not take the obvious route of blowing some air back into the tank. Apparently he did not know how to raise the submarine, only lower it. (Perhaps this was all that was given in his test plan; I don't know). Instead, he let water in the ballast tanks at the other end. Again he overshot, and again, and again... until he wiggled the open sonar hatch under the water. Sea water came rushing in the front. Now, this would not be such a disaster under ordinary circumstances, as military ships are always compartmented so that whole sections of a ship can be flooded without sinking the ship. But this ship was in for repair, and temporary pipelines, hoses, and power cables had been run through the pressure hatches that were meant to close the compartments. Sailors tried to use fireaxes to cut through live power cables in order to close the hatches, but to no avail: the valiant Gitarro sank to the bottom of Mare Island Channel. I don't know if anyone was killed or injured - I think not. Damage was mitigated somewhat by a quick thinking tugboat operator who saw the "sail" starting to roll over into the water. He rammed his tugboat up against the sail and kept pushing against it until a floating crane was brought in the next morning. Even so, damage came to $30 million. In another incident, the radioactive coolant water was being drained from a reactor. This submarine (not the Gitarro) was in drydock. The usual procedure is to cut a hole in the hull and run the water out a pipe into a cement mixer. The radioactive water is used to make cement and trucked to Hanford, Washington (about 800 miles) for "disposal". The pipe from the reactor reached out to the hull, where it was connected via a flange to the pipe leading to the cement mixer. Only one time they forgot to bolt the flanges together; as the water was pumped out it showered upon a shipyard worker walking on the drydock below. I understand that the shipyard worker not only survived but was still working at the shipyard during the '80s - but the clothes he was wearing at the time, and the patch of drydock he was standing on at the time are buried at Hanford. Also, this fellow exceeded his lifetime allowance for radiation exposure during this "hot shower", and is not allowed inside the nuclear yard. In still another incident, the above mentioned cement mixer was stolen by the truck driver assigned to deliver the radioactive concrete to Hanford. He was caught - after he had used the mixer to pour a backyard patio at his house. But wait, there's more! The Navy contracted with a private manufacturer to build a piece of equipment that would be installed in a room aboard a submarine. The Navy gave the manufacturer plans to this room. When the equipment was delivered, a hole was cut in the hull of the submarine, and the equipment was lowered in by a crane. Because submarines are very cramped there was not much room and the designers used up every bit of available space for their machine. When it was lowered into the submarine, it was found that this device did not fit! The Navy made all sorts of accusation's about the manufacturer's incompetence, but in the end it was found that the manufacturer did meet the specifications; the Navy's mechanical drawing had an error in which "1/2 inch" was written where "1/4 inch" was intended. (Note that one of the factors that limits the life of a submarine is the number of times holes have been cut in its hull. After a while the hull is weakened so much that the submarine has to be scrapped.) And finally, a note about the circumstances in which I lived at the base, and the importance of unambiguous language in giving commands. I lived there at the height of the Vietnam War, while my father was an instructor in the antiaircraft missile school there. I spent the third and fourth years of my life living on a military base at the height of a war; I remember tanks rolling by and trucks and trains loaded with bombs. Being a small child I regarded this with the wonder and curiousity any childhood would have for his playground. My parents sternly ordered me never to cross the street - but by walking some distance down my street and crossing an open meadow, I could freely enter the Marine Corps rifle practice range. Being three feet tall, my friends and I could easily walk unobserved in the culverts along the road. I remember watching the men firing their M16's, and one time I sat in a bunker below the targets - one could lower a paper target into the bunker to replace it or tally the score - watching bullet holes appear in the targets above. The Marines did catch us, many times in fact, and always sternly warned us to stay away, but they never did tell my parents. I never felt I was doing anything wrong as I did not cross the street. I did cross the street once, though... and the next street beyond, and snuck under the fence into the shipyard area itself, walking right past heavily armed sentries - remember all the riots were happening in Berkeley just 20 miles away, so I'm sure they were on the lookout for saboteurs. They just didn't think to look for intruders that didn't reach up to their knees! I remember quite clearly looking up into the cranes used to lift heavy equipment off of railroad cars, and all manner of heavy equipment that would have ground a four-year old boy into hamburger. [...] Mike Crawford crawford@scipp.ucsc.edu crawford@maxwell.ucsc.edu ------------------------------ Date: Mon, 31 Oct 1994 16:54:28 +0500 From: mercuri@gradient.cis.upenn.edu (Rebecca Mercuri) Subject: Re: FEC Voting "Standards" (Jones, RISKS-16.52) [CC of message to Doug Jones,] I was forwarded your E-mail, which was posted in RISKS on-line. I wanted to comment on a few errors in your message. First of all, the FEC Voting "Standards" do not "mandate" anything. These are not standards, they are merely suggested guidelines. The guidelines are just that because of "states rights." This is the right of states to have certain choices in a variety of matters. There is precedent for the federal government to mandate some things regarding voting. One of these is who can vote (as in women, blacks, people over the age of 18). But currently the federal government, although it oversees federal elections, does not MANDATE any STANDARDS regarding voting machines. The FEC document you appear to have been reading is just guidelines. Some of the states have adopted these guidelines, and then they become a part of those states laws. But many states have not. Secondly, you should know that these FEC guidelines were created with extensive assistance from voting machine vendors and other service providers. It was in no way a balanced group. What I and others have tried to point out in the years since the publication of these guidelines is that there are already good STANDARDS for assuring accuracy and integrity in computer-based systems. These standards are the "orange-book" system that the federal government uses for other federally-used computation systems. (Voting machines are exempt from the 1987 Computer Security Act and are not required to conform to these standards.) Within these standards is a system and organization for certifying secure systems at various levels. We would hope that eventually states (or the federal government) would enact laws that would bring voting machines into this system, and they could be examined for conformity. The FEC guidelines fall far short of the NIST standards, and we would like to see this changed. I am not in any way suggesting that even the NIST standards would be sufficient to ensure accurate and secure electronic vote tabulation. I am just mentioning all of this here, because you are misled regarding the stringency of the FEC guidelines and of their application. Rebecca Mercuri ------------------------------ Date: Sat, 29 Oct 94 19:38:32 PDT From: carasso@inference.com (e.e.) Subject: No Real Risks of Seemingly Similar Interfaces RISKS should be a forum for real risks, not pet peeves, not minor inconveniences, not for harmless mistakes. I am amazed by the amount of whining in this forum. If you hit you Mac's power switch trying to eject your floppy, you obviously just got your Mac, there's little of value on it, and it's unlikely that anything damaging will *really* happen. There is very little real risk. You are whining about a SELF-FIXING-PROBLEM. You won't do it again. And if you do, it's called natural selection. Stupidity is its own reward. If you accidentally push a wrong ATM button and get out $40 when you didn't mean to, there is NO RISK. Just take the little envelope, deposit the $40 back in, and I'm sure you won't do it again. And if you do, it's called natural selection. Stupidity is its own reward. If these were nuclear warheads, municipal power stations, or something important, fine. Write about it. But for Heaven's Sake, leave your whining at the Gate. roger ------------------------------ Date: Sun, 30 Oct 94 14:52:04 -0500 From: "Girls & Boys" Subject: There are risks and then there are risks (ETS) (McEvilly, RISKS-16.51) Carlos McEvilly tells of his friend who was denied a semester at school because of an interface problem with the computer-administered GREs. While I sympathize with his friend's plight, it seems that blaming the test administrators (ETS) seems too easy and too simple-minded. As with other cases, we should bear in mind that there is a system and a whole process in place, with several opportunities for human intervention. For example, the problem would never have been seen had the friend not chosen to take the computerized version in order to give himself more study time. The risks of failure to plan in advance seem to apply here. The college's use of the GRE score as a binary decision-making factor is itself fraught with risks. First off, ETS itself advises against this -- the risk of using a product in a way it was not intended to be used. Second, my friends who are college professors all tell me that the best predictor of how good a student someone will be is not a standardized test, but rather the person's past performance as a student. The college already had one semester's worth of evidence for this student's abilities, but they ignored it -- the risk of not considering all the evidence as well as the risk of ignoring the opinions of qualified experts. I could go on, but let me just state my main point: We've all gotten to the stage where when we hear a so-called explanation like "Pilot error" or "computer error" we know to dig deeper. We know that there are processes involved, that there are opportunities for people to intervene, and that focussing solely on one event/incident/problem tends to obscure other possible causes. But we continue to apply this kind of shallow analysis to other situations. In this case, while I can see the error in the ETS software as being a contributory factor, I can hardly give it primary, let alone sole importance. Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard MIT Media Lab, Intelligent Agents Group wex@media.mit.edu 617-253-9833 Pager: 617-945-1842 ------------------------------ Date: Sat, 29 Oct 1994 08:29:18 -0400 (EDT) From: "Dr. Frederick B. Cohen" Subject: Re: Security screen (Bank fences, power keys, etc.) It seems to me that one of the risks of robbing a bank is getting killed by the guards, the security system, or the people you are taking money from. I am not convinced that we should try to make robbing banks safe. Re: On-Off Switch on Macs ... I don't really understand this issue at all. It seems to me the solution is not a better on-off switch, but a better operating system. My Unix box doesn't seem to need an on-off switch, but every DOS, Windows, and MAC system I have ever seen can't get along without one. Re: Pacemaker failure ... I appreciate that if my pacemaker fails, I will die, but I don't understand why that justifies not using a pacemaker. Without it, someone who needs it will die with P=1. With it, they have P=.001 or whatever. We seem to overlook the issues of cost and probability in the risks forum when it comes to accidental risks, and frankly, this is a big mistake. Re: CMU course on dependable system design ... The description sounds interesting, but it also sounds like it ignores a great deal. I think that one of the problems with universities is what we expect of them. It has taken me many years of full time effort to gain the knowledge I have in the fields I explore. In a university, you get 9 hours per week (if you work hard) for 15 weeks on any particular subject. 135 hours on dependability is admirable, but that's about the same as 2-3 weeks of experience (depends on how many hours you work per week) in the field. Still, as a leading complainer about the lack of attention to information protection in our educational system, I should support the CMU initiative. The only problem I have with the course description is that it seemed to ignore the malicious aspects of risks in favor of accidental ones. Of course, we certainly have a lot of accidents to worry about. Re: The risks of reading risks Somehow, the news reader on this system, (tin) seems to believe that it is the only program users should ever run. It takes about 15 minutes to examine every news group that has ever existed, and after offering me a wide selection of new ones I have not previously asked not to get, finally allows me to read the risks forum. Of course, this process cannot be interrupted by the normal Unix interrupt character, and there don't seem to be options to have it simply read the risks forum and leave me alone. Perhaps this should be a class project at CMU's new class on dependability. While they are at it, they should look at the Elm email system, which insists that I answer the same questions every time I read mail, even though I always give the same answers. No, there is no way to default them - or at least I haven't found one. ------------------------------ Date: Fri, 28 Oct 1994 19:57:02 -0400 (EDT) From: Esther Filderman Subject: Re: More on backspace problems In RISKS-16.51 John Vilkaitis describes trying to get Netcom to understand that his system is showing intermittent problems connecting to Netcom, and that it is -not- failures of his "terminal software". At the end, he concludes, > The RISK of not fixing intermittent problems is having to increase your > marketing budget. Same for not understanding English. Understandable, but I suggest that the more frightening RISK is the following: > They then repeatedly tell me to put STTY ^H in my .login file, which they have already done WITHOUT my permission! I will run the risk (no pun intended) of offending my fellow systems administrators by saying that we all have heard horror tales of "well-meaning" systems and/or support folks screwing up users by editing their files without their permission, or without their understanding of the changes. They're generally making more work for themselves. Esther Filderman moose+@cmu.edu System Mangler Library Automation Carnegie Mellon University ------------------------------ Date: Mon, 31 Oct 1994 14:17:49 -0500 From: diamond@RT66.com (Russell Stewart) Subject: NETCOM Backspace Problem ["terminal software"] (javilk,RISKS-16.51) > Our technical support staff has diagnosed this kind of problem > innumerable times.... it is in our opinion clear [?] that any > remaining problem is the fault of your terminal software. "It can only be attributable to human error." -HAL 9000 Russell Stewart Albuquerque, New Mexico diamond@rt66.com ------------------------------ Date: Fri, 28 Oct 1994 17:07:20 -0700 From: pauld@cs.washington.edu (Paul Barton-Davis) Subject: CAPS-LOCK considered harmful bart@cs.uoregon.edu (Barton C. Massey) writes of various problems with CAPS-LOCK. There's another, even more infuriating problem that CAPS-LOCK has a risk of creating, and already has on certain keyboards. Under the X Window System, it is possible to remap the keyboard in any way you choose. This includes getting rid of CAPS-LOCK altogether, or so you might hope. I do this routinely to deal with some of the problems Barton mentioned, by mapping it be just another control key. This works fine at work, on a DEC keyboard. When I get home, however, there's a problem. The keyboard on my NCD X terminal considers the "lock" attribute of this key to be a hardware feature, and thus regardless of what I map it to under X, it always behaves like a CAPS-LOCK in terms of latching and unlatching. Since I map the key to be a control key, you may be able to imagine my frustration when I accidentally press the key and find that my emacs-editing-supported shell goes haywire as I try to type alphabetic characters. It sometimes take me quite a while to realize why nothing I type works. One day, I'll figure out a better way to remap it. In the meantime, even if we're stuck with CAPS-LOCK, please hardware types: don't make the latching feature a function of the keyboard electronics, but leave it software controlled, where if its broken, some of us can fix it. -- paul barton-davis UW CS Laboratory ------------------------------ Date: 28 Oct 1994 17:17:44 -0700 From: kparker@chaph.usc.edu (P. Kevin Parker) Subject: Follow up to CAPS-Lock and MS Natural Keyboard (Massey, Alvarez) Interesting that these two posts should appear one after the other: > CAPS-LOCK Considered Harmful (Barton C. Massey) > Microsoft Natural Keyboard (Don Alvarez) The RISK of the CAPS-Lock is eradicated--in Windows only--by this keyboard. Using the software provided by Microsoft, a user can disable CAPS-Lock entirely. P. Kevin Parker kparker@scf.usc.edu kparker@eis.calstate.edu ------------------------------ Date: Sat, 29 Oct 1994 02:29:53 -0400 (EDT) From: rcook@BIX.com Subject: CAPS-LOCK Key Harmful? While I can sympathize with the contributor who dislikes the CAPS-LOCK key (my own keyboard has it placed cleverly just to the left of the space bar -- sure-fire sabotage), I'd like to point out that there is a growing group of people for whom it is vital. Those are the people who don't have the physical ability to press two keys at once. For that reason I think CAPS-LOCK is a Good Thing and should remain standard on keyboards. --Rick Cook rcook@bix.com [There are other cases as well, for example, in programming languages that REQUIRE UPPER CASE, as noted by Brian T. Schellenberger, bts@unx.sas.com, who also notes the problems caused by the absence of a CAPS-LOCK indicator. PGN] ------------------------------ Date: 29 Oct 94 05:55:03 EDT From: Phil Keys <100213.1013@compuserve.com> Subject: RE: CAPS-LOCK Considered Harmful On 10/25, Bart Massey posted an article on the risks associated with the use of the CAPS-LOCK key on a keyboard & challenged manufacturers to come up with a better method. Whether it's better or not can be debated, but in Japan, AT compatible machines running bilingual (Japanese/English) DOS (called DOS/V) have adopted a convention where, to toggle the CAPS-LOCK key, you have to press both the Shift key & the DOS/V key at the same time. Personally, I don't like this since it forces you to remove your hand from the keyboard to toggle CAPS-LOCK, but, it does make it less likely that you will toggle CAPS-LOCK by mistake, thus reducing this risk. Just thought I'd let you know that at least somebody, somewhere has been thinking about this issue too. Phil Keys [and appropriately named for this discussion, too! PGN] ------------------------------ Date: 30 Oct 1994 21:53:34 GMT From: dsiebert@icaen.uiowa.edu (Doug Siebert) Subject: Re: CAPS-LOCK Considered Harmful (Massey, RISKS-16.51) NeXT did this right in at least the revision of the keyboard I have on my color slab. The command key held down while hitting the shift key toggles caps lock on/off (and toggles the LED that is in both shift keys) That way the control key can be in the IMHO correct place, left of the 'A' key. Doug Siebert dsiebert@isca.uiowa.edu ------------------------------ Date: Sat, 29 Oct 1994 16:01:55 -0400 From: Greg Lindahl Subject: Re: AOL (RISKS-16.51) > I presume the newsgroup stuff ages just as rapidly [as E-mail]. PGN Actually no -- it seems to stay for months, so you'll see AOL users restarting month-old flamewars by responding to something that's expired everywhere else. [Ah, that suggests virtual time travel and multiple virtual realities. Deja vu all over again. PGN] ------------------------------ Date: Sat, 29 Oct 1994 23:08:14 -0700 From: Mike Crawford Subject: Re: America Online Offlines America An official from AOL was quoted in the San Francisco Chronicle Business section today, 29 Oct 1994, denying that AOL was losing mail. This fellow (might have been the president, I'm not sure) went on to invite the Internet Community to "flood" AOL with mail. Now, it's one thing to shoot your own self in the foot, but inviting the net to spam AOL.com in the national press is likely to have the added effect of overloading all the routers from here to there. I'd like to suggest that the folks at aol ought to think twice before saying such things. Mike Crawford crawford@scipp.ucsc.edu crawford@maxwell.ucsc.edu ------------------------------ Date: Sun, 30 Oct 1994 12:57:12 -0500 From: RichWells@aol.com Subject: Re: AOL Offlines America (RISKS-16.51) It appears to be the Macintosh AOL software that has the 22K limitation on messages which prevents seeing an entire issue of Risks at one time. Even so, the entire issue can be read; you just cannot keep more than about 22K of it around at one time. This has the unfortunate consequence that you have to stay on-line for the time it takes to read it, rather than saving it to a file and reading it later off-line. The Windows AOL software does allow one to read the entire issue at one time, and to save it to a file for later reading. [Stuff on deletion deleted. Also, clarification that comp.risks came up at the same time as other newsgroups on AOL.] AOL's newsgroup access is indeed limited (note that I had to edit the subject heading to abbreviate America Online!), but it's not quite as bad as your postscript made it sound. [TNX. PGN] ------------------------------ Date: Sat, 29 Oct 1994 02:08:01 GMT From: cjackson@adobe.com Subject: Re: Half a degree is better than none? (Brader, RISKS-16.49) }Or rather, it tries to. Somehow, wherever the character 1/2 is }supposed to occur, instead there is a degree sign! As Mark Brader, the poster of the above, can intimately attest from the work of both of us in certain international standards committees, this is a primary area of concern when one is defining standards for font use and especially font/glyph substitution. Our classic example in our ISO committee was of the American who sends in a bid on a bit of business in the UK, only to have his electronically-transmitted bid (these are the fast-moving '90s, after all) printed out with the '$' replaced by the UK pound symbol. Quite a hefty automatic bid increase, that one. Curtis Jackson cjackson@mv.us.adobe.com ------------------------------ Date: 20 October 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.52 ************************