Subject: RISKS DIGEST 15.69 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 25 March 1994 Volume 15 : Issue 69 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) ***** Contents: Another ATM failure (with a happier ending) (Mark Connolly) Bugs hold up farm cheques (Mich Kabay) Nut behind the wheel (Mich Kabay) Digital Telephone Switches and Modems (Bob Oesterlin) Grammatik bug mistaken for racial putdown (Marni Elci via Roy Beimuts) Re: Denver Baggage Handling (John Gersh, Marcus J Ranum, Bear Giles) Re: Funny Money article (Sean Eric Fagan, Curtis Jackson, Tobias Ulmer) Re: RISKs of safe ATMs (M. Hedlund) Re: Comment on earlier [Don Norman] posting (Marcus J Ranum) CFP: 2nd ACM Conference on Computer and Communications Security (Li Gong) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 24 Mar 1994 08:22:14 -0500 From: connolly@hookup.net (Mark Connolly) Subject: Another ATM failure (with a happier ending) Is there any interest in yet another ATM contribution? This one has all the familiar elements plus a reward for honesty to at least one of the participants (but not the other). Here are extracts from a newspaper story. [Mark Connolly, Connolly Design Inc., Waterloo, Ontario, Canada] Bank machine runs amok; Honest customer returns bag full of cash SouthamStar Network EDMONTON -- All Barry Inkster wanted when he slipped his bank card into the automated teller was $200 to shop for a birthday gift for his wife. Instead he got a Las Vegas-style payoff when the machine spat out nearly $5,000 in $20 bills ... "I grabbed all the money in a great big wad and walked to a doughnut shop and asked them to give me a bag."... Inkster said he's been ripped off by automated tellers in the past, only to be told by bank personnel that machines don't make mistakes. ... the machine had been causing problems all weekend ... a number of people complained ... the machine was subtracting their withdrawals, but not handing out any money. ... No one from the bank was available for comment. A repair crew worked on the machine Monday morning but obviously it didn't fix all the problems ... Inkster called the bank, took the money back and watched the tellers count about $4,800. ... "All I was concerned about was if the transaction had taken $5,000 out of my account." The bank assured him it hadn't. Inkster said he was well rewarded with a pen, key chain and free dinner for his honesty. ------------------------------ Date: 23 Mar 94 09:15:44 EST From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Bugs hold up farm cheques >From the Associated Press newswire via Executive News Service (GO ENS) on CompuServe Disaster Checks (By ROBERT GREENE, AP Farm Writer) WASHINGTON (AP, 22 Mar 1994) -- The glitches stole Christmas from many Dade County, Fla., growers expecting disaster payments from the Agriculture Department. Because of processing errors, many checks for those who suffered losses in Hurricane Andrew have been held up for three months. The author explains that about 5,000 cheques (a total of about $25 million) were to have been mailed in December. However, staffers found serious errors such as a $140,000 overpayment. As a result of procedural and computer bugs, "Of the $24.8 million in payments, $14 million has been reissued. And so far, $1.8 million worth of payments has been canceled. Another $11 million in payments remains on hold." [It's bad enough to fight bugs in the fields without having to fight bugs in the banks.] Michel E. Kabay, Director of Education, National Computer Security Association ------------------------------ Date: 23 Mar 94 09:15:48 EST From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Nut behind the wheel >From the United Press International newswire via Executive News Service (GO ENS) on CompuServe Survey: few merchants check conflicting credit-card signatures written by Peg Byron, edited by Harold H. Martin, in New York NEW YORK (UPI, 21 Mar 1994) -- Credit-card fraud may get an unintentional boost from retailers, Money magazine reported Monday in a survey that found 95 percent of clerks and cashiers they tested failed to check signatures on charged purchases. Money magazine said signatures for purchases that conflicted with the name on the credit card seldom caused clerks or cashiers to check for fraud. The article continues with details of the experiment. Staffers used the wrong cards or signed false names in 127 cases (they had letters authorizing them to perform the experiment). Only 5% of the store employees checked the signatures at all. "In one case, a male Money editor was not questioned even when he used a woman's card to charge a $114 meal in a New York restaurant and signed the credit slip `Daffy Duck.'" The cost of such fraud, entirely passed on to consumers, is about $55 per card user in the U.S. [Human factors control the effectiveness of security measures. We really do have to insist on PINs for credit cards.] Michel E. Kabay, Director of Education, National Computer Security Association ------------------------------ Date: Fri, 25 Mar 1994 11:57:09 -0600 (CST) From: Bob Oesterlin Subject: Digital Telephone Switches and Modems Early last month, our local phone company (US West) replaced our "aging" analog telephone switch with a new digital one, which was designed to bring us "into the information age". Well, no sooner was the switch installed, people started having problems connecting to our dial-in service for home terminal support. The current system consists of a front-end box (made by Traqnet) and a Cisco terminal server. The problems seemed to be widespread but intermittent: - Dropped connections - Can't connect at 14.4 KB (drops back to 1200!) - Can't connect at all After some lengthy (and still ongoing) investigation, the problem turned out to be that the time bases of 3 digital switches involved are not in sync! The 3 are: - The Rochester switch (run by US West) - The IBM Rochester Local ROLM switch (local PBX) - The NPN Switch (which connects IBM to the corp network run by Advantis, Inc) Comments from our local communications rep: "I have been told that there are 3 national master clocks. Each phone company must sync their digital switch with one of these master clocks." "U.S. West's switch is sync'd with a master, I don't know which." "NPN's switch is sync'd with a master too, this may be the same master that U.S. West is sync'ing to but, this is not important yet." "Our ROLM switch is sync'd with NPN and cannot be changed." BTW, the problem "seems" to be getting worse as time passes. It would seem to me that this could become a widespread problem as more DSS's are used. Is someone causes a master clock to become out of step, then you could (potentially) disrupt communications over wide areas. Bob Oesterlin, IBM AS/400 Division, Dept 54T, Rochester MN 55901 oester@vnet.ibm.com (IBM IPNET: oester@rchland.ibm.com) (507)-253-4528 ------------------------------ Date: 24 Mar 1994 15:27:50 -0500 (EST) From: "Roy Beimuts, Melfort Research Station, AGR CA" Subject: Grammatik bug mistaken for racial putdown The following letter to the editor appeared in the March 23rd Globe and Mail; a very eloquent response to what must have been a very upsetting article. Another illustration of how the most noble of programming intentions can backfire in the most unexpected ways due to an unforeseen bug: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Letter header: Software bug led to misunderstanding I was distressed to read Mark Charendoff's essay Dear WordPerfect: I'm A Jew (Facts and Arguments -- March 8). Mr. Charendoff expressed dismay that Grammatik, WordPerfect's grammar and style checker, responded to the noun "Jew" with the message "Avoid this offensive term." Mr. Charendoff's dismay is understandable. The message is absurd in that context. It was intended for "jew" used as a verb (e.g., "he jews them down"). Grammatik's extensive dictionary contains two entries for "Jew"; one, capitalized, for the noun, and another, labelled "offensive," for the lower-case verb. When "Jew" or "Jews" occurs as the first word of a sentence, a bug in the program is calling the lower-case entry instead of the correct upper-case one. Ergo, the message is erroneously output. The bug will be fixed. Its appearance in a program that I helped develop and am proud of is upsetting enough. That it resulted from our sincere efforts to identify and eliminate ethnic slurs troubles the whole Grammatik development team. But other aspects of the situation disturb me personally as well. Please note that the opinions below are my own, not necessarily shared by WordPerfect Corp. Mr. Charendoff remarks that many Jews he spoke with about this argued that "Jew" really is an offensive term. They tried to find some rationalization for the message. That troubles me. A word which identifies a whole heritage, a word as valid as "Protestant," "Buddhist," "Italian," or "Canadian," does not become offensive just because bigots use it, whether to demean or even to decimate. When Jews bend to that point of view, they reflect the confusion of a people that has survived oppression, only to be left with shame about its identity. The automatic assumption by Mr. Charendoff and others that the message was an intentional racial putdown, not a mistake, bothers me too. Bugs occur often in software programs, especially those as complex as Grammatik. Parsing English is not easy. Granted, a bug involving one's religion may be hard to recognize as just an error. Although I wish he had written to us rather than The Globe and Mail, I cannot really blame Mr. Charendoff for his indignation. Grammatik's goal has always been to help users find and fix problems in their writing. We think we have had good success so far, and we are constantly working to improve our performance. We are grateful that this mistake has been found so that we can correct it. But I would like the record to be clear -- this bug resulted from trying to eliminate prejudice, not propagate it. Note: I come from a family of Orthodox Jews. Most of the members of my family who survived the Second World War now live in Toronto. Marni Elci, English Linguist at WordPerfect Corp. Albuquerque, N.M. ------------------------------ Date: Wed, 23 Mar 1994 15:38:17 -0500 From: John_Gersh@aplmail.jhuapl.edu (John R. Gersh) Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68) It gets even more interesting... The 7 Mar 1994 issue of *Aviation Week* has a story on the airport's yet-again-delayed opening. The hangup is indeed the complex automated baggage-handling system. The article says that the underlying problem is simply that system testing has not been completed in time, but it also describes some specific problems that have arisen. One is that: "When United ran its tests, ticket counter agents were generating on-line printed baggage tags too rapidly, causing United's Apollo computer reservations system to communicate improper data to [the baggage system manufacturer's] baggage sorting computers. As a result, properly tagged luggage were being routed to a manual hold station instead of the aircraft, according to [the manufacturer's president]. 'It was mostly a training glitch,' he said. After the agents slowed down, the system operated nominally, he said." While it's not entirely clear what "generating tags too rapidly" means here from the limited information given, one can envision various ways in which problems might arise. For those of us who spend all too much time in airport waiting lines, though, it's naturally disconcerting to hear that the system design requires the agents to work more slowly than they would like to! It's even more disconcerting, however, to hear this described as a "training glitch," rather than a system design problem. My first reaction was to classify this as a typical case of blaming the user rather than the builder for problems in system design or implementation. Consider the following analogy, though: Airport check-in agents put luggage on a conveyor belt for dispatch to the baggage-handling area. Suppose there were a problem with agents "putting bags on the belt too rapidly" (i.e., piling bags on top of each other so that they fell off the belt or jammed the mechanism). Assuming that the belt speed was reasonably specified (based on other considerations), wouldn't it be proper to classify that as a training or procedural problem? Is that different from the overly-speedy tag printing? Of course it is, and therein lies the key point. It's visually obvious what the proper placement of the bags on the belt should be; is it also obvious when the next acceptable tag-printing moment arrives? Suppose, only for the sake of argument, that other reasonable design constraints sometimes produce a significant communications delay between the two systems; that delay might result in the reservation system being able to print a baggage tag which the baggage system was not yet able to handle. In that case the real problem lies in not showing the agents that the overall system was not ready to print a tag or accept a bag. If, in fact, the agents can "generate tags too rapidly," then there is almost certainly something other than a "training glitch" at work. One might think either that the data generation or interchange timing is not as it should be or that the design of the agents' terminals does not adequately portray or control the effect of such possible timing problems. John R. Gersh John_Gersh@aplmail.jhuapl.edu The Johns Hopkins University Applied Physics Laboratory ------------------------------ Date: 23 Mar 1994 21:51:15 GMT From: mjr@tis.com (Marcus J Ranum) Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68) One thing that's particularly fascinating is that many of the problems they are facing (conveyor problems, zebra tags getting ripped and damaged, etc) are problems that Federal Express and UPS have apparently already solved. I suppose UPS and Federal Express have the advantage that they can enforce packaging size limits and so forth, but it seems to me that one of the big RISKS we're seeing here is the ever-present danger of not doing your research. ------------------------------ Date: 23 Mar 1994 20:07:42 GMT From: bear@tigger.cs.Colorado.EDU (Bear Giles) Subject: Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68) You won't hear much griping from the politicians because *they* are the ones to blame for the delay. After the contract was signed, Denver kept asking for change after change to the luggage system. Nobody can develop a system on time and on budget if what they're developing keeps getting redefined! On top of that, Denver made certain technical promises (e.g., a "clean" power supply) which it has been unable to fulfill. This directly lead to the failure of some of the early tests; a power surge would blow out circuitry, overrun motors, etc. >It'd probably be the usual uninformed pablum about how complex systems >"always" have a few "small" problems, and no thought given to how the >problems might have been prevented in the first place. It's pretty clear that Denver has a lot of airheads at the new airport. My favorite design flaw was the massive water sculpture directly over the main power transformers... requiring a large stainless steel catch basin. Another good one (not directly related to the airport) was the initial proposal that one-way bus fare from Boulder to the airport would run about $17. In contrast, the current bus fare from Boulder to Stapleton is about $2.50. (The increase in distance would be about 30%). Toss in high taxi fares, and high car parking fees, and most people would choose to have a spouse or friend drop them off and pick them up. The impact on air quality is obvious. Just remember, the mayor of Denver who pushed this monstrosity on us is now the Secretary of Transportation. ------------------------------ Date: Wed, 23 Mar 94 11:00:13 PST From: sef@kithrup.com (Sean Eric Fagan) Subject: Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68) >MK thinking out loud: AI pattern recognition algorithms coupled with a >library of currency images could permit a smart copier to blank out all >attempts to photocopy money. It already exists. Xerox demonstrated it I think within the past year or two. When given money (both US and many non-US), it ignores it, and you end up with a blank spot on the paper. The risks are obvious (to me, at least) and many. ------------------------------ Date: Wed, 23 Mar 94 12:35:04 PST From: cjackson@mv.us.adobe.com (Curtis Jackson) Subject: Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68) The new versions of the Canon Color Laser Copiers, the CLC 350 and CLC 550 (replacing the former CLC 300 and CLC 500) have exactly this type of protection built in, supposedly at the request (?demand?) of the U.S. government. I have no insight into the method used to prevent the copying of U.S. currency; I only know that the protection is in place in these products. Curtis Jackson cjackson@mv.us.adobe.com or dod721@aol.com ------------------------------ Date: Fri, 25 Mar 1994 13:04:27 +0100 (MEZ) From: zccz1121@rpool1.rus.uni-stuttgart.de (Tobias Ulmer) Subject: Re: Funny Money (Mich Kabay, RISKS-15.68) Such photocopiers are already in existence. I remember a demonstration in the German "Knoff-hoff" TV show (an entertainment show dealing with popular-science topics; and yes, the name is indeed derived from "know how") about one or two years ago. On the occasion of the introduction of new Deutsch-Mark bills at that time, the host explained the techniques that were used to make the bills counterfeit-proof. He finally concluded the discussion by taking a bank-note out of his wallet and laying it on a photocopier that he announced to be one of the latest inventions regarding the growing problem of counterfeit by use of those rapidly spreading color copiers. He pressed the button, not forgetting to mention smilingly that he was only allowed to do so because they had obtained a special permission and with police officers sitting in the first row of the audience, watching closely. What the machine produced was a verbatim copy of the bill but with colors changed to brilliant pop art. The host then showed a microchip that was the nucleus of the device that was said to recognize some dozens of bills from various currencies. I would not expect such a chip to contain any such thing as protection codes to activate/deactivate the pattern recognition circuit, but instead a non-alterable read-only memory holding the images of the bills. So the difficulty isn't to protect the chip against being cracked but to prevent that its inhibiting output signal be disabled by means of a simple short cut. This can only be accomplished if some part of the system that is essential to the copying process is incorporated within that same microchip. The system has to be designed in such a manner that you cannot get the copier working without that chip so that it has the power to decide whether or not to copy. On the other hand, little can be done against a criminal attempt to replace the entire electronic control circuit board. A more severe problem seems to be the fact that every once in a while new bills keep coming up which the device wouldn't yet be able to recognize. This requires that it is ensured that of every such existing copying machine the built-in firmware be updated (by replacing the chip with a newer version) every time when new notes are introduced with (at least) any of the leading currencies in the world. Tobias Ulmer (zccz1121@rpool1.rus.uni-stuttgart.de) Student of Electrical Engineering ------------------------------ Date: 23 Mar 1994 13:14:52 -0800 From: hedlund@teleport.com (M. Hedlund) Subject: Re: RISKs of safe ATMs (Markowitz, RISKS-15.68) > "[...] if a thief tries to use a card which has been stolen, our ATMs > are programmed to lock the doors and call the police. [...]" >So if you use one of their cards, you had better hope that there are no >data entry errors when a card with an account number similar to yours is >reported stolen. [...] That's not all.....you'd also better hope: (1) you're not inside those doors when an actual thief tries to use a stolen card, not knowing or not caring about the "security" measures; (2) no natural nor manmade disasters occur while you're waiting for release; (3) the police know how to unlock the door; (4) your boss doesn't walk by the ATM atrium while you're stuck; (5) the bank installs a restroom (or at least, that you don't happen to need one); (6) the automated system succeeds in reaching the police and conveying your location; (7) the bank doesn't decide they're getting better use of your money while you're penned up..... M. Hedlund ------------------------------ Date: 23 Mar 1994 22:16:32 GMT From: mjr@tis.com (Marcus J Ranum) Subject: Re: Comment on earlier posting (Norman, RISKS-15.68) >In my defense, however (the never-give-up defense), I still wish to argue >that spelling errors are a result of what would amount to "poor design" >were language and spelling actually designed. How can something that wasn't "designed" be an example of poor design? Languages evolve (with exceptions like volapuk and esperanto) rather than being created from whole cloth by some rational process. Obsoleting a "living" language is a lot harder than fixing a programming language -- the installed base is potentially huge. Some legacy systems still actively communicate using Latin. English, with all its commas and apostrophes and other bits of charm, is the result of a process of *translation* between the street English of the day and an approximation of written English. If I tried to write some of the street speech from my neighborhood in ascii, it might look a lot like, "yo'm'a, cah yuh spa' me a qua'tuh?" Unlike compiled languages used by computers, spoken languages don't *NEED* to be designed and probably never will (the feelings of L'Academie Francaise aside). Human minds are flexible enough to cope with the vagaries of "badly designed" languages. Spelling mistakes are a result of inattention to detail, ignorance, or apathy. The good news is that generally, the listener/reader will relatively painlessly absorb the error, rather than dumping core or giving a cryptic error like my compiler does when I forget punctuation. ------------------------------ Date: Fri, 25 Mar 94 15:11:20 -0800 From: Li Gong Subject: CFP: 2nd ACM Conference on Computer and Communications Security Call for Papers 2nd ACM Conference on Computer and Communications Security Nov 2-4 1994 Fairfax, Virginia Sponsored by: ACM SIGSAC, Hosted by: Bell Atlantic, George Mason University High quality unpublished original research and practice papers in the area of computers and communications security are invited for consideration for the 2nd ACM Conference on Computer and Communications Security. All aspects of security are relevant, including:- THEORY AND TECHNIQUES: Access Control, Cryptanalysis, Digital Signatures, Intrusion Detection, Audit, Cryptosystems, Formal Models, Randomness, Authentication, Cryptographic Protocols, Hash Functions, Viruses and Worms, Authorization, Database Security, Integrity, Zero Knowledge. APPLICATIONS, CASE STUDIES & EXPERIENCES: Cellular and Wireless, LAN Security, Security APIs, Smart Cards, Electronic Commerce, Network Firewalls, Security Architectures, Telecommunications Security, Enterprise Security, Open Systems Security, Security Management, WAN Security. SOCIAL AND POLICY ISSUES: Cryptographic standards, Information Privacy, Legal Issues, Technology Export. PRACTICAL PAPERS DESCRIBING APPLICATIONS, CASE STUDIES OR EXPERIENCES ARE ESPECIALLY WELCOME. INSTRUCTIONS FOR AUTHORS: Format: FIVE copies of your paper (not to exceed 7500 words) in a form suitable for ANONYMOUS review (no author names, affiliations, obvious references, etc.) and a cover sheet with author name(s), address, phone and fax. Where possible all communications to authors will be via e-mail, so PLEASE PROVIDE an e-mail address. SUBMIT TO: Prof. Ravi Sandhu, ISSE Dept., MS 4A4, George Mason University, Fairfax, VA 22030, USA (Ph#: 703-993-1659 E-Mail: sandhu@isse.gmu.edu) or Prof. Jacques Stern, ENS/ DMI, 45 rue d'Ulm, 75230-05 Paris, France (Ph# 1 44 32 20 29 E-Mail: stern@dmi.ens.fr). Deadline: Papers must reach us by JUNE 1, 1994. Sorry, we cannot accept late submissions, and they will be returned unopened. Authors will be notified of the Program Committee's decision by AUGUST 5, 1994, and will have to submit final camera ready papers by AUGUST 26, 1994. GENERAL CHAIRS Dorothy Denning, Georgetown U and Raymond Pyle, Bell Atlantic PROGRAM CHAIRS Ravi Ganesan, Bell Atlantic and Ravi Sandhu, George Mason U TREASURER Richard Graveman, Bellcore PUBLICITY CHAIR Li Gong, SRI EUROPEAN CONTACT & PUBLICATIONS CHAIR Jacques Stern, ENS/DMI PROGRAM COMMITTEE Steve Bellovin, AT&T Eli Biham, Technion Joan Feigenbaum, AT&T Virgil Gligor, U of MD Li Gong, SRI Rich Graveman, Bellcore Sushil Jajodia, GMU John Kimmins, Bellcore Carl Landwehr, NRL Stewart Lee, U of Toronto David Maher, AT&T Roger Needham, Cambridge Clifford Neuman, USC ISI Paul Oorschott, BNR Bart Preneel, KUL P. Samarati, U of Milan Robert Shirey, MITRE Jacques Stern, ENS/DMI Byron Stump, Bell Atlantic Paul Syverson, NRL Bhavani Thuraisingham, MITRE Roger Tjarks, SAIC Michael Wiener, BNR Raphael Yahalom, Hebrew U ------------------------------ Date: ongoing 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 on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines 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, send requests to (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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "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. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. 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 15.69 ************************