Subject: RISKS DIGEST 15.56 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 17 February 1994 Volume 15 : Issue 56 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: Smart Cards for London Buses (Mich Kabay) NII Testimony (Robert Ellis Smith) Losing ATM transactions (N.S. Youngman) Telephone charges fail to fit the bill (Marcus Marr) Re: E-mail risks (Bill Fitler, Rex Black) 737 crash near Panama (Tim Steele) Re: YAMIC [Yet Another Mistaken Identity Case] (Jim Cook) Who says the Clipper issue is complicated? (D.J. Bernstein) Re: Classified justifications; escrowed keys (Carl Ellison) CFP, First Smart-Card Research & Advanced Application Conference (JJVandewalle) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 16 Feb 94 22:41:04 EST From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Smart Cards for London Buses Electronic card system launched on London's buses --United Press newswire 02/15 1027 via Executive News Service (GO ENS) on CompuServe. LONDON (UPI) -- London Transport Minister Steven Norris Tuesday launched an 18-month trial of an electronic ticketing system on the city's buses. More than 200 buses operating in the Harrow district of northwest London have been fitted with a contactless "Smartcard" reader that validates bus tickets. Government officials said the trial will be the largest of its type in the world. The article states that the credit-sized card will be activated by proximity sensors without requiring any physical contact with the reader. The card is expected to make boarding the buses easier and faster as well as reducing fraud. Perhaps the most significant sentence in the article is the following: "... the card will help reduce fraud and give bus operators more information about who is using their services." I wonder if the system includes audit trails which record details of who rode which bus when. If so, I hope the software development team uses adequate quality assurance. RISKS readers will recall that Ross Anderson recently described a case in the U.K. in which a policeman was convicted of fraud for having the temerity to complain about what he claimed were unauthorized withdrawals from his bank account. The court ruled that the bank's electronic records, which _failed to support_ the defendant's arguments, were sufficient to convict the suspect. Any system which records information about personal movements poses risks when the information is accurate; but inaccurate information can cause even more trouble. Can a RISKS reader in the U.K. follow up on this story? Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn ------------------------------ Date: Thu, 17 Feb 94 09:28 EST From: Robert Ellis Smith <0005101719@mcimail.com> Subject: NII Testimony PRINCIPLES OF PRIVACY FOR THE NATIONAL INFORMATION INFRASTRUCTURE Robert Ellis Smith Publisher, PRIVACY JOURNAL, and Attorney at Law Before the NII Task Force Working Group on Privacy January 26, 1994 1. Any analysis of the National Information Infrastructure must recognize that privacy includes more than an expectation of confidentiality. The right to privacy also includes (1) freedom from manipulation by others and (2) the opportunity to find safe havens from the crassness and commercialism of daily life. 2. The infrastructure must be an INFORMATION-TRANSFER medium, not a SALES medium. It must be primarily an INFORMATION medium, and only secondarily an ENTERTAINMENT medium. (Will the information superhighway be only another way to exploit couch potatoes?) 3. It must have different levels of security and confidentiality so that some sector in it allows for confidential communications. These communications could be intercepted by law enforcement only under current Fourth Amendment guidelines. Aside from that, in the confidential portion of the infrastructure, there must be strict penalties for the interception of any PERSONAL data without the consent of BOTH the sending party and the person who is the subject of the data. And for aggrieved individuals and organizations there should be a right to sue for breaches of confidentiality. 4. There must be some portion of the infrastructure free from commercial messages and free from the commercial uses of the names and electronic mail addresses of the users. Even though it is commercial-free, this sector need not necessarily be operated by the government or a non-profit entity. 5. In the sectors of the infrastructure available for use by individuals, there must remain opportunities for ACCESSING (non-personal) data anonymously (as exist in a library situation now). Whether to permit anonymous MESSAGE-SENDING in these sectors remains, for me, an open question. To deny this will deprive the network of much of its spontaneity, creativity, and usefulness; however, to permit anonymous message-sending runs the risk of having these sectors dominated by obscene, inaccurate, slanderous, racially and sexually-insulting chatter - and worse. 6. Privacy interests are less compelling, to me, in two other sectors of the proposed infrastructure. In those sectors transmitting proprietary business information and sensitive business dealings, the organizations using the network will see to it themselves that security meets there needs, and they will have the resources to pay for it. By the same token, in those sectors providing point-of-sale services (presumably from the home), companies offering these services will provide adequate security or risk losing customers. 7. The infrastructure ought not become a means for large conglomerates to transfer personal information between and among subsidiaries where the data-handling is regulated (credit bureaus, cable companies, medical providers) and entities where the data-handling is not regulated (telephone providers, brokerages, credit-card processors, telemarketing). ___________ Rather than proposing specific safeguards -- which can be drafted later -- the task force can be most effective in 1994 by establishing the DOMINANT THEMES of the infrastructure: information-transfer, not commercialism; democratic access not corporate dominance; diversity (in usage as well as in levels of security) not conformity. ------------------------------ Date: Wed, 16 Feb 94 13:34:28 GMT From: N.S.Youngman@exeter.ac.uk Subject: Losing ATM transactions Recently I moved my bank account to Telephone bank PLC (names changed to protect the guilty :-), a subsidiary of Traditional bank PLC. Amongst the apparent advantages of this arrangement is the ability to use Traditional bank's ATMs. I had a substantial amount in my current account after the transfer, much of which had come from a savings account, which gave substantially more interest than the current account does. naturally when the ATM offered me a transfer between accounts as one of its functions I elected to transfer this cash to my savings account with Telephone bank. Nearly two weeks later I checked the balance and find that nothing had been transferred. Telephoning the bank the operator said "It doesn't allow you to do that". I offered the opinion that the ATM shouldn't offer functions it can't provide. The operator said that it couldn't be changed "otherwise the machine wouldn't recognise your card." She did however agree to look into whether there were any warnings in the banks literature (I read everything in their welcome pack and i did not see any). The risks are obvious, but as I hate people leaving it at that, I will enumerate those that are obvious to me. 1 Loss of interest. 2 My balance isn't what I thought it was (they wouldn't reall bounce my cheques would they 8-) 3 Can I trust the other facilities provided by the ATM (ordering statements, cheque books, etc.) nsyoungm@cen.ex.ac.uk youngman@signal.dra.hmg.gb ------------------------------ Date: Thu, 17 Feb 94 16:21:34 GMT From: Marcus Marr Subject: Telephone charges fail to fit the bill The latest issue of New Scientist includes an article on the overcharging of some BT customers. The full article gives more details on the scope of the BT investigations, the perceived extent of the problem, and the steps that have been taken to notify business customers. I've tried, though, to extract the paragraphs which may be of interest to RISKS readers. There only risk I can think of is that of trusting computers, so those who cheque their phone bill should not be at risk. In my opinion, there is no risk to domestic customers since a jump of \pounds 420 in a quarterly phone bill should be noticed by the monitoring system, and if it isn't, then surely the customer would notice! Reproduced (without permission) from New Scientist, 19th February 1994, page 18: ``British Telecom has been overcharging some of its customers because its computers cannot subtract one number from another reliably. ... BT is conducting two investigations, one to find out why the computer-generated bills were wrong by such a large amount, and the other to discover why the errors were not spotted by a separate computer system designed to trap gross billing errors. BT charges calls by units (4.2 pence plus VAT). Meters at the local exchanges that log the units used on each line are read each quarter. BT's billing computer subtracts the figure for the last reading from the current reading to give the number of units it charges for. ... In each case [of overcharging discovered], simple subtraction of the two meter readings gave a result which was wrong by 10,000 units. In one bill, four separate mistakes were discovered: 18497 - 2964 = 25533 14295 - 2096 = 22199 11030 - 1824 = 19206 3 - 1 = 10002 These four mistakes added \pounds 1680 to a bill of \pounds 3908. BT's backup system is designed to monitor the billing computer and register any unprecedented peaks of activity on a line. But the system failed to notice any errors later spotted by subscribers. ... Insiders say that modern digital exchanges use solid-state metering which feeds data directly into BT's billing computer. They believe that BT has a bug in its accounting software and that the problem is thus much more widespread than has so far been recognised.'' ------------------------------ Date: Wed, 16 Feb 94 16:51:53 pst From: bfitler@ccmail.com Subject: Re: E-mail risks: appalling grammar/notoriety (mathew, RISKS-15.55) Mathew has identified the risk of poor grammar and spelling in e-mail messages, namely that the originator of a message will be judged as much (or more) by its form as by its content. I firmly believe that etiquette has evolved in social interactions to manage the risks of those interactions - and that the e-mail media is still young enough to be defining "proper" etiquette. As to Mathew's comments on notoriety, several stories come to mind. Recent RISKS articles describe the flood of e-mail to Bill Gates mailbox, as well as to WHITEHOUSE.GOV. An older story describes the e-mail trials and tribulations of DEC's Ken Olsen, whose mailbox was deluged with mail, some from people who would never dare to talk to him in the hall but felt perfectly at ease taking him to task in an e-mail message. I would greatly appreciate any pointers from RISKS readers to more information on the developing etiquette of e-mail. -Bill Fitler bfitler@ccmail.com ------------------------------ Date: Wed, 16 Feb 94 09:24:34 CST From: rex@iquery.iqsc.com (Rex Black) Subject: Re: E-mail risks: appalling grammar/notoriety (mathew, RISKS-15.55) I agree with Mathew, FWIW. As a manager, I insist on the use of proper English by all the Software Quality Assurance folks that I supervise. Why? Because, in the minds of many, as Mathew noted, hearing or reading improper English reflects poorly on the education and intellect of the person communicating. In addition, I feel that sloppy communication is a symptom of a larger problem of carelessness and lack of attention to detail, something I find inappropriate in a professional setting. How one chooses to express one's ideas is indicative of the value one places on them. Interestingly, I have worked with a number of people for whom English was a second language, and they put more effort into doing it properly--often with better results--than many who grew up speaking and writing it. Rex ------------------------------ Date: Thu, 17 Feb 1994 18:38:14 +0000 From: tjfs@tadtec.co.uk (Tim Steele) Subject: 737 crash near Panama This is NOT a definitive account, just my hazy recollections from having watched a "Horizon" documentary shown on the BBC this week. Apparently, a 737 crashed near Panama about two years ago; all on board (about 47) were killed. The fault was identified by the investigating team as a probable loose wire from the gyros to the flight deck which caused the artificial horizons to "stick" in one position from time to time without any indication to the pilots that there was a fault. The aircraft was flying at night during a storm, and the investigators thought that a 1G roll would be undetectable to the crew; therefore, they surmised, they had no way of knowing the plane's true attitude. The resulting wild maneuvers as the pilots tried to make the stuck artificial horizons show a level attitude led directly to break-up from aerodynamic forces at about 10,000 feet. The switches which control the artificial horizon displays were found to be set to "BOTH ON VG1" which denied the pilots information from the backup gyros. The reason for this was unknown. The cockpit voice recorder was recovered, but proved to contain only a recording of an earlier flight; it used magnetic tape (as opposed to wire) and the tape had snapped some weeks previously. As the recorder was sealed, the tape doesn't get checked. The flight data recorder (also tape based) worked properly. The programme implied that the team could not in the end identify the faulty wire, and had made no recommendations on modifications or checks on other 737 aircraft to prevent a reoccurrence, although they felt improved crew training might be beneficial. Can someone post more information on this? Tim ------------------------------ Date: Wed, 16 Feb 1994 10:35:05 +0500 From: jcook@epoch.com (Jim Cook) Subject: Re: YAMIC [Yet Another Mistaken Identity Case] The indicated article stated that in month that the victim was held, his van and its contents were sold. It would seem a second lawsuit would be indicated here for improper procedure violations. I would think that while his assets could be seized, they couldn't be sold except after conviction or a motion for a court order at which time the defendant would allowed to object. C. James Cook, Epoch Systems, Inc., 8 Technology Drive, Westboro, MA 01581 508-836-4711x385 JCook@Epoch.com ------------------------------ Date: Tue, 15 Feb 1994 01:13:48 -0800 From: "D. J. Bernstein" Subject: Who says the Clipper issue is complicated? ``I would like to caution people about signing the petition,'' Dorothy Denning said. ``The issues are extremely complex and difficult.''%1 Clipper (by which I mean EES/Skipjack/Clipper/Capstone collectively) does raise some mildly tricky issues, which I'll discuss later. But those are _side_ issues. The basic argument%2 against Clipper is simple and deserves emphasis. Clipper is bad because it is unfair competition in the crypto market. Who has paid for the design and implementation of Clipper over the past decade?%3 The taxpayers. Who has paid for ramping up Clipper production at Mykotronx? The taxpayers. Who pays for the lawyers and accountants keeping Clipper on course, and the NSA-FBI team which visits Bell Labs and other locations to promote Clipper? The taxpayers. Who will pay for the key escrow ``service,'' probably an agency with dozens of people, including armed guards? The taxpayers. I resent being forced to pay for Clipper's development and adoption. Is this Clipper subsidy the only way that the government is interfering in the market? Not at all. Consider, for example, export controls. A private company, even if it doesn't see a foreign market for its encryption products, has to register as an arms dealer and take precautions to avoid selling crypto to non-citizens. These restrictions have been dramatically reduced for Clipper.%4 Are these points a matter of dispute? Is this just my view? No. The government knows full well that Clipper is unfair competition. In fact, unfair competition is the goal of Clipper policy. According to Jerry Berman, ``the reason [for various Clipper-related actions] was stated bluntly at the [4 Feb 94 White House] briefing: to frustrate competition with Clipper by other powerful encryption schemes by making them difficult to market, and to "prevent" strong encryption from leaving the country...''%5 Now, here's the problem: The government talks about Clipper's market interference as a _good_ thing. Of course, I see it as a bad thing. America's need for data protection would be fully served by a healthy encryption industry; let's eliminate crypto export controls! If you agree with me---if you want a free crypto market---then you should oppose Clipper. There's nothing complicated about this. Let me close by briefly addressing a few side issues, mostly reasons that Clipper is risky when compared to other crypto available today. 1. There is a RISK that the Skipjack algorithm is, intentionally or unintentionally, weak. Suppose that in 1986 an NSA cryptanalyst noticed a subtle but wide hole in Skipjack, which was relatively new at the time. Why would it be in NSA's interest to divulge this information? Denning points out that we don't _know_ of any holes, but that's axiomatic---Clipper would be dead otherwise. One cannot deny the _risk_, exacerbated by secrecy, of a hole. 2. There is a RISK that Clipper will be easier to break than the basic Skipjack algorithm. Given two encryption algorithms one can (carefully) compose them to produce a ``double encryption'' which is strong even if one of the algorithms is weak. Clipper also has two encryption steps, but for a different reason---one encryption is transparent to the user, the other transparent to the FBI. If either of these different%6 steps is weak then Clipper is weak. ``Half encryption,'' I'd say. 3. There is a RISK that key escrow security will be compromised, either by bribes from the outside or by corruption from the top. It is highly dangerous to keep so many keys under the control of such a small group of people. 4. There is a RISK that, if Clipper fails to dominate the market, the government will simply outlaw all non-escrowed encryption. ``This is a fundamental policy question which will be considered during the broad policy review.''%7 Alternatively the government could outlaw Clipper superencryption while requiring Clipper in government procurements, new phones, and so on. Denning points out that Clipper is voluntary right now, but the mere fact that the government brought up the possibility of a Clipper law means that there's a risk. Footnotes: %1 To sign the CPSR Clipper petition, send a message to the address clipper.petition@cpsr.org with "I oppose Clipper" in the subject header. %2 This argument was mentioned briefly by Geoff Kuenning, RISKS-15.50, among a cast of thousands. %3 See Matt Blaze's message in RISKS-15.48. ``They said ... that Skipjack began development "~about 10 years ago.~"'' %4 See ftp.eff.org:pub/EFF/Policy/Crypto/harris_export.statement: ``After initial review, key-escrow encryption products may now be exported to most end users. Additionally, key-escrow products will qualify for special licensing arrangements.'' %5 See ftp.eff.org:pub/EFF/Policy/Crypto/wh_crypto.eff. %6 See Roy M. Silvernail's message in RISKS-15.52. %7 See the initial White House Clipper press release, 930416. ---Dan ------------------------------ Date: Wed, 16 Feb 1994 14:31:19 -0500 From: Carl Ellison Subject: Re: Classified justifications; escrowed keys (Denning, RISKS-15.52) In RISKS 15.52, Prof. Denning states (in reply to someone else): >Certain information relating to foreign intelligence operations is >classified. Are you saying that decisions should not be based on >classified information or that foreign intelligence information should >not be classified? I am saying that decisions about the encryption I use, as a private American citizen, must not be based on classified information. I am saying that the decision must be based on a totally public debate in which we all engage. There should be no executive session, giving classified agencies an advantage over the citizenry. She goes one to state: >You need a court order to intercept any electronic communications, including >those on high speed nets. You need a court order to get keys. Although the >court order is not given to the escrow agents (to protect the identity of >those under investigation), certification that one was obtained must be >presented to the escrow agents. This "protection of the identity of those under investigation" could actually be protection of agents doing illegal wiretaps. If the escrow agents were to give not the master key for a chip but a session key and if each request for a session key included the name of the person being tapped and the court order authorizing it, then the escrow agents would be in a position to notice the kind of abuses for which Nixon and Hoover were famous and therefore would be able to blow the whistle on the offending agency. ------------------------------ Date: Tue, 15 Feb 1994 22:45:52 GMT From: jeanjac@iad.ift.ulaval.ca (Jean-Jacques Vandewalle) Subject: CFP, FIRST SMART CARD RESEARCH AND ADVANCED APPLICATION CONFERENCE CALL FOR PAPERS : CARDIS FIRST SMART CARD RESEARCH AND ADVANCED APPLICATION CONFERENCE October 24 - 26, 1994 LILLE FRANCE Sponsored by IFIP - The International Federation for Information Processing AIMS AND GOALS Smart cards or IC cards are becoming a significant part of the information processing world. Furthermore they are beginning to move towards real integration into the information systems. They participate in the overall data management, security and communication processes. But they bring their own special characteristics. It is very likely that future IC cards will require many scientific and technical improvements which represent a challenge for the success of the technology. So far there are many events which are mostly devoted to the commercial and application aspects of IC cards. There is now an opportunity to initiate a scientific conference bringing specialists who are involved in all aspects of design of the future IC cards and related devices and environment. IFIP - the International Federation for Information Processing has agreed to sponsor this conference. It will be the first occasion for the IC card community to start a permanent activity: In addition to the conference itself there will be discussions about creating a permanent group within IFIP with possible implication for advancing standards, publishing and international cooperation. SUBMISSIONS Six copies of detailed abstracts of original papers corresponding to one or several themes for the conference should be sent in English to the program chairman before May 2, 1994. The submissions will start with a succinct statement of the problem addressed and their significance, appropriate for a non-specialist. Technical development directed to the specialist should follow as needed (at most ten pages). They should be accompanied by a fact sheet indicating the following: - Title of the paper with the relevant conference theme(s); - Author(s) with affiliation, address, phone and fax numbers, E-mail. Proceedings will be available at the conference. IMPORTANT DATES Submission deadline May 2, 1994 Acceptance notification June 17, 1994 Camera ready paper due August 13, 1994 Conference October 24 - 26, 1994 THEMES TECHNOLOGY IC architecture and techniques Memories and processor design Read/Write unit engineering Specific co-processors for cryptography Biometry Communication technologies Interfaces with the owner, the service suppliers Reliability and fault tolerance Special devices Standards SOFTWARE The operating system Models of data management Communication protocols IC CARD DESIGN IC cards formal specification and validation Tools for internal or external software production Validation and verification Methodology for application design SECURITY Models and schemes of security Algorithms Security interfaces Hardware and software implementation Security of information systems including cards Formal verification of transaction sets IC CARDS, INDIVIDUALS AND THE SOCIETY IC cards and privacy Access to his data by the owner IC cards: political and economical aspects Is the IC card going to change regulation? Patents, copyrights FUTURE OF THE IC CARDS Innovative technologies Moving towards the pocket intelligence Convergence with portable PCs, laptops etc ... PCMCIA INNOVATIVE APPLICATIONS Design methodology of applications IC cards and the information system Examples of new applications Requirements for innovative cards ORGANIZATION General Chairman Program Chairman Prof. Vincent Cordonnier Prof. Jean-Jacques Quisquater RD2P Universit'e Catholique de Louvain CHRU CALMETTE Dept. of Electrical Eng. (DICE) Rue du Prof. J. Leclerc Place du Levant, 3 F - 59037 LILLE CEDEX B - 1348 Louvain-la-Neuve FRANCE BELGIUM Tel (33) 20 44 60 47 Tel (32) 10 47 25 41 Fax (33) 20 44 60 45 Fax (32) 10 47 86 67 e-mail: cardis@rd2p.lifl.fr Quisquater@dice.ucl.ac.be Program committee Mart'in Abadi (Dec Research, USA) Ross Anderson (Cambridge, UK) Benjamin Arazi (Ben-Gurion, Israel) Todd Arnold (IBM, USA) Jacques Berleur (FNDP, Belgium) William Caelli (Queensland, Australia) David Chaum (DigiCash, Netherlands) Vincent Cordonnier (Lille, France) Mark Cummings (SRI, USA) Amos Fiat (Tel-Aviv, Israel) Andr'e Gamache (Quebec, Canada) Marc Girault (SEPT, France) Louis Guillou (CCETT, France) Joseph Hoppe (TRT Philips, France) John Kennedy (Cylink, USA) Philippe Maes (Gemplus, France) Roger Needham (Cambridge, UK) Jean-Jacques Quisquater (Louvain-la-Neuve, Belgium) Laurent Sourgen (SGS-Thomson, France) Doug Tygar (Carnegie-Mellon, USA) Michel Ugon (Bull-CP8, France) Klaus Vedder (GAO, Germany) Robert Warnar (NIST, USA) The city of LILLE is about 150 miles away from PARIS. It can be reached : from Paris by either motorway (two hours) or train (one hour). From most European countries by train, motorway or plane. The conference will take place at the University of Sciences and Technology of Lille. Accommodation can be provided either on the campus or in the center of the Lille. We will provide maps and help for hotel reservation and travels. ------------------------------ 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: GET RISKS-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. 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.56 ************************