Text File

Subject: RISKS DIGEST 16.63 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Friday 9 December 1994 Volume 16 : Issue 63

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 ***** ***** NOTE, SRI RISKS ARCHIVE SOURCE IS MOVING SOON TO ANOTHER HOST. ***** Contents: "High-Tech Can Hinder Policy Work" (PGN) Laptop proscription (Bob Morris) Our police and media in action [RF interference] (Lynn Gold) Digital cash on the web -- comments? (Justin Wells) New printer font: Sloppy Handwriting 14pt (Norman H. Cohen) Multicast backbone blunder [risks of hidden transmission] (Alan Clegg) A Question for the Community regarding National Crypto Policy (Herb Lin) Problems with compiler optimisation (Pentium related) (Martin Poole) Risk of _not_ using floating point..... (David Lesher) Re: Formal methods and the Pentium FDIV (Tim Bradshaw) It's all my fault, really [re: Good Times] (Martin Minow) Good Times is a *meta*virus (Joe Chew) Good Times is a Meme (Keith Henson) Re: Schneier's book "Applied Cryptography" (Y. Radai) Re: Fun with your phone company (Geoff Kuenning, Russell Stewart) More on network file race condition (Andrew Koenig) Rights and Responsibilities of Participants in Networked Communities (Herb Lin) Searching RISKS et al. (Frederick B. Cohen) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Fri, 9 Dec 94 10:15:03 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: "High-Tech Can Hinder Policy Work"

The Supreme Court is divided over a case involving false arrest due to erroneous computer data, attributed to human error. Ruth Bader Ginsburg was quoted thusly: ``As automation increasingly invades modern life, the potential for Orwellian mischief grows.'' Antonin Scalia countered that nothing is gained by excluding evidence of true wrongdoing because some subordinate did not purge outdated information from a computer system.

The case arose after Isaac Evans was stopped in 1991 in Phoenix for a minor traffic violation; he was arrested because of a hit identifying an outstanding warrant --- although though that warrant had been previously ``quashed'' and should have been removed from the database. Furthermore, the arresting officer then detected the presence of marijuana. The Court is reviewing whether, under the circumstances, that evidence can be used in a trial for drug possession in light of the false arrest.

[Source: A Washington Post item appearing in the San Francisco Chronicle, 8 Dec 1994]

------------------------------

Date: Thu, 8 Dec 94 20:42 EST From: RMorris@DOCKMASTER.NCSC.MIL Subject: Laptop proscription

Act 4 of Shakespeare's 'Julius Caesar' opens with Mark Antony, Octavius, and Lepidus meeting to work out the proscription that is to follow Caesar's murder. To be proscribed means that you are rubbed out and your property confiscated by the people doing the proscribing. Clearly, proscription is a significant data processing problem since both the rubbing out and the division of spoils have to be worked out to the satisfaction of the proscribers.

In a recent production of Julius Caesar by the Folger Shakespeare Theater in Washington, D.C., there was only a modest amount of tittering when one of the proscribers arrived on stage to do the necessary work with a laptop.

Bob Morris

[I presume the character was ProScribe rather than ProLaTeX? Was Folger in his Cups? or Caps? (Sorry. That multipun is only for OLD Washington logicians.) PGN]

[Marc Rotenberg added, out of band, i.e., not in RISKS-16.63 as mailed: If Caesar lived until proscribed at the Folger, he was obviously good to the last drop.]

------------------------------

Date: Wed, 7 Dec 1994 22:46:34 -0800 From: figmo@netcom.com (Lynn Gold) Subject: Our police and media in action

I got the following from ba.broadcast today and felt it was worth sharing here....

The following is an INEXACT quote from KCBS, one of our all-news radio stations:

...the police have called the bomb squad to defuse the hand grenades. Until the grenades are defused, the police have prohibited the use of 2-way radios in the vicinity of the scene here, so we are reporting by cellular phone instead of radio.

Somebody needs to tell the folks at KCBS the meaning of "radio."

Somebody also needs to give the police a clue.

--Lynn

------------------------------

Date: Wed, 7 Dec 1994 23:13:14 -0500 From: rjwells@undergrad.math.uwaterloo.ca (justin wells) Subject: Digital cash on the web -- comments?

There are a lot of people over in the comp.infosystems.www.* newsgroups who are seriously talking about using the World Wide Web (WWW) as a digital cash system. I get the impression they want to do this in some number of months or a year.

Apparently they want to use the FORMS feature supported by most web browsers in conjunction with some sort of encryption algorithm. The idea is you connect to a commercial site, see see something you want to pay for, fill your credit card number in on the form, and transmit it back to the http server with some kind of encryption. They're talking about using some encryption technique present or expected in the Netscape browser.

As far as I can tell this method will not involve any sort of authentication, and it will only secure data after it has left your browser and before it gets decrypted.

Are these people for real? This has to be one of the most foolish things I've heard in a long time, but I'd like to hear some comments from RISKS readers -- I'm no expert in these matters. It might also be an idea to crosspost a bit of the discussion back to *.www.* to wake these folks up.

Justin Wells rjwells@uwaterloo.ca

------------------------------

Date: Fri, 9 Dec 94 09:43:21 EST From: "Norman H. Cohen" <ncohen@watson.ibm.com> Subject: New printer font: Sloppy Handwriting 14pt

I received an envelope in the mail yesterday that was immediately identifiable as junk mail by the word "URGENT" printed in large red letters imitative of a rubber stamp. Thus I was taken aback that the envelope appeared to be hand-addressed with a felt-tip pen.

Closer examination revealed that the apparently sloppily scrawled capital N in my first name was identical to that in "NY", the even sloppier lower-case A in my first name was identical to those in my street name and city name, and so forth. Nonetheless, to the casual observer, the effect was quite convincing.

The risk is an old one--the use of computers to perpetrate a deception.

------------------------------

Date: Thu, 8 Dec 1994 13:14:57 -0500 (EST) From: Alan Clegg <abc@black-ice.gateway.com> Subject: Multicast backbone blunder [risks of hidden transmission]

While watching the multicast of the current IETF session [Automatic Address Configuration], I was presented with a message imposed by the broadcasting group of "susanp@spinnaker please stop broadcasting".

I looked at the monitor, and sure enough, there was *another* video session being broadcast. For the next ~5 minutes, everyone on the multicast backbone was allowed to watch as susanp worked on some html markup [using hotmetal], then responded to a bit of e-mail.

The risk turns out to be that the newest version of the NV video transmission software allows you to transmit video across the mbone without a camera... any window or cursor-followed region will be happily transmitted to the world... It is not obvious in ANY way that you are actually transmitting any information...

I called the person listed in the WHOIS database for the address range that Susanp was in and the session went away, BUT... what would have happened if susanp had started doing something that was more company confidential? Since folks are recording the multicast digitally, all it would take is one screen shot with private information..

- -abc

------------------------------

Date: Fri, 09 Dec 94 10:30:00 EST From: CRYPTO@nas.edu Subject: A Question for the Community regarding National Crypto Policy

As many of you know, the National Research Council is undertaking a study of national cryptography policy (description available on request to CRYPTO@NAS.EDU). This note is the first of a number of questions that will be posted to the Internet community in our attempt to solicit input on a broad scale. Please circulate this request to anyone that you think might be able to contribute.

The question of this posting is the following:

How, if at all, do capabilities enabled by new and emerging technology in telecommunications (e.g., key-escrow encryption technologies, digital telephony) and electronic networking make it _easier_ for those who control that technology to compromise and/or protect the interests of individual end users? Please use as the standard of comparison the ease _today_ of compromising or protecting these interests. We are interested in scenarios in which these interests might be compromised or protected both individually and on a large scale. Please be sure to tell us the interests you believe are at stake.

Please send your comments on this question to CRYPTO@NAS.EDU.

------------------------------

Date: Wed, 7 Dec 1994 11:59:51 +0000 (GMT) From: mpoole@heac006.gb.ec.ps.net Subject: Problems with compiler optimisation (Pentium related)

You may amused/horrified to hear of an incident that occurred at a major city bank last week here in the UK.

On hearing of the Pentium bug, they decided to test all of their machines to see which had the problem. They compiled up a test program and checked all of their Pentium based machines and discovered that all of them had the fdiv bug. They decided to be extra cautious and run the same program on all the other machines. To their horror all of the 486 machines exhibited the same problem.

After several days of headless chicken impersonations, a more-level head decided that something must be awry and called in a good friend of mine who in short order discovered their mistake.

The test program was compiled on a Pentium box and had the sum performed with constants. The compiler had noticed the use of constants and had performed the sum there and then, putting the result in the executable to be printed on demand on whichever box it was run on.

The risks involved are obvious but the solution is less so. Even if the sum is done using variables, what is to stop the compiler from noticing that the values do not change between initialisation and the time of performing the calculation, and cause the same problem ? (Yes, I know. Use functions, pass parameters. But what if it gets in-lined, and then optimised ?)

Admittedly this only normally occurs on binaries that are shipped for alternative platforms, but how many software houses use the smaller chips (386/486) as the main compile engine before shipping ? And of course, users who have Pentiums without the bug, but use software compiled by a chip with it are also susceptible.

The effects and problems of this are going to be with us for a long time.

Martin Poole, Perot Systems Europe mpoole@heac006.gb.ec.ps.net mpoole@cix.compulink.co.uk

------------------------------

Date: Fri, 9 Dec 1994 10:38:27 -0500 (EST) From: wb8foz@netcom.com (David Lesher) Subject: Risk of _not_ using floating point.....

I spent 3 hours holding in the queue for XXX tech support before I got to speak to a person. When I did, I mentioned my wait. He apologized for the delay, then observed that his 'hold-time' counter had overflowed at 99 minutes.....

Such invalid data should do wonders for their staffing projections.

------------------------------

Date: Fri, 9 Dec 94 00:57:01 GMT From: Tim Bradshaw <tfb@edinburgh.ac.uk> Subject: Re: Formal methods and the Pentium FDIV (Stalzer, RISKS-16.62)

> Many formal approaches would not have caught this kind of error ...

I haven't followed all the arguments about random testing, but it's also the case that random testing is not appropriate for this sort of problem. If you have something like a lookup table in there, it really does make sense to make sure that you test *all* the entries in that table: trying to do this with random numbers is crazy. As to trusting it because it was generated by computer: well, I wouldn't trust *anything* that was easy to check if I was about to make millions of dollars worth of it.

--tim

------------------------------

Date: Thu, 8 Dec 1994 08:04:59 -0800 From: minow@apple.com (Martin Minow) Subject: It's all my fault, really [re: Good Times]

You may have received a few messages recently regarding a supposed computer virus spread through the mail. Unfortunately, it's nothing new -- in fact, it was announced in a RISKS submission not too long ago. With the kind help of the RISKS moderator (no doubt, digging out from under his own avalanche of reports), I am enclosing it for your consideration.

Martin Minow minow@apple.com (note new address)

RISKS-LIST: RISKS-FORUM Digest Friday 1 April 1988 Volume 6 : Issue 53

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator [...] Date: 1 Apr 88 00:00 From: minow%thundr.DEC@decwrl.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) Subject: Virus attacks RISKS

Today, I'm afraid I must confess that one of my recent postings to RISKS contained a Virus that Peter (no doubt inadvertently) distributed to the RISKS audience. The virus doesn't infect your programs or data files directly, but in a manner analogous to the "Christmas card" virus discussed here a few months ago, it causes increased network traffic.

As the virus establishes itself, you will note its affect by the increased amount of electronic mail you receive every day. For some of you, the increase is linear; but for others, I'm afraid you're on the early part of a exponential curve.

Although the virus was easy to create, I'm afraid that I don't know how to cure it. In fact, I believe I'm beginning to note its effects on my own system.

Humbly, Martin Minow

[PS: No avoid another visit from corporate security, please take careful note of the date of the original submission.] [PPS: No, I didn't hack the mail protocol to get that date: I just stayed up late that evening.]

------------------------------

Date: Wed, 07 Dec 1994 16:54:35 -0800 From: JTCHEW@lbl.gov (Ad absurdum per aspera) Subject: Good Times is a *meta*virus (RISKS-16.62)

Naah -- "Good Times" is the first *meta*virus. The target is available bandwidth itself; it acts by getting well-meaning users to send virus warnings to huge, massively overlapping mailing lists. :)

Joe "Dyn-o-mite!" Chew

------------------------------

Date: Thu, 8 Dec 94 11:26:38 PST From: hkhenson@cup.portal.com Subject: Good Times is a Meme (Keith Henson)

In RISKS 16.62 Zygo Blaxell (zblaxell@miranda.uwaterloo.ca) and Reuven Lerner <reuven@hpwadck.wal.hp.com> both make good points re the "Good Times" 'virus' where the message about a virus it *itself* a virus! (With possibly bad long term effects.) Computer viruses & human fads (like passing on the Good Times warning) both fit the model of a meme. (See _Selfish Gene_ by Richard Dawkins.) A meme is one type of *replicating information pattern*, genes are the other main class. Putting a class name such as "meme" on Good Times helps us group things/events into classes where we can expect analogous effects.

What computers and fast communications have done is to radically change the replication constants for memes, and to make unworkable the controls society has tried to put on such things.

Keith Henson (whose articles on memes are widely available on the net.)

[Re: Joe Chew's previous item: *Meme chose?* PGN]

------------------------------

Date: Thu, 8 Dec 94 14:32 +0200 From: Y. Radai <RADAI@vms.huji.ac.il> Subject: Re: Rob Slade's review of Schneier's book "Applied Cryptography"

> ... the book contains a substantial number of typos ...

This is all too correct. I should like, however, to add three points: (1) The book contains not only many typos, but also a number of serious errors in its descriptions of some of the algorithms. (I pointed out several of these last June; copies of my posting are available from me by e-mail.) (2) While Schneier himself maintains a cumulative errata sheet, the publisher (Wiley) apparently refuses to include it with copies of the book which have been distributed since the appearance of the errata sheet. (3) The good news is that Schneier is preparing a second edition, which will, of course, correct all known errors. It will also contain several new sections not present in the first edition.

Y. Radai, Hebrew Univ. of Jerusalem, Israel, RADAI@VMS.HUJI.AC.IL

------------------------------

Date: Wed, 7 Dec 94 17:47:36 -0800 From: geoff@FICUS.CS.UCLA.EDU (Geoff Kuenning) Subject: Re: Fun with your phone company (Stewart, RISKS-16.61?)

As one who worked on bill-payment ("remittance processing") systems many years ago, I find this conclusion [take the phone number off the check, not the stub] highly implausible, to put it mildly. A phone, utility, or credit-card company in a moderately large city must process literally hundreds of thousands of payments every day (divide the phone population by 30). The return portion of the bill is carefully encoded with many things, including both the account number and the amount due. That way, when the human operator types in the amount of the check, it is assumed correct if it matches the amount due, saving a costly verification step. Since the bill stub *has* to be OCR'ed, why would anyone build a complex and expensive system to scan the check for a phone number, printed in an unknown location in an arbitrary typeface (if it's present at all) instead?

It is far more likely that Russell accidentally sent in the wrong half of the stub, or no stub at all, and a human somewhere was faced with trying to credit the proper account with his payment. Since the phone number was on the check, the human assumed it represented the proper account -- an unjustifiable assumption, but an understandable one when you consider that there are thousands of these errors to deal with every day, so that it's not practical to make a phone call to verify the assumption, and the customer would probably get very upset if you mailed the check back without cashing it.

The RISK here is not a computer risk, but simply that it is always unfortunate to fall through the cracks of a system that is too big to give individualized service.

Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com

------------------------------

Date: Wed, 7 Dec 94 21:06:35 MST From: diamond@RT66.com (Russell Stewart) Subject: Re: Fun with your phone company (Kuenning, RISKS-16.63)

>As one who worked on bill-payment ("remittance processing" systems many >years ago, I find this conclusion highly implausible, to put it mildly.

So would I! But I am only repeating to you what the woman at the phone company told me; and my $150 *was* credited to my dad.

Actually, on further reflection, I've come to the conclusion that it probably *wasn't* an automatic scanner, but a human being. I suppose that sort of invalidates this as a Technological RISK.

>It is far more likely that Russell accidentally sent in the wrong half >of the stub, or no stub at all, and a human somewhere was faced with >trying to credit the proper account with his payment.

No, I sent in the correct portion of the bill, as I always do. Believe me, if you'd had the experiences I've had with the local US West office, you wouldn't be so skeptical.

Russell Stewart Albuquerque, New Mexico diamond@rt66.com

------------------------------

Date: Thu, 8 Dec 94 13:40:35 EST From: ark@research.att.com Subject: More on network file race condition (RISKS-16.62)

Several people have suggested to me, some rather haughtily, that my corrupted /etc/hosts file would not have come about had I been using an operating system that supported file locking by default--that is, if only one process could have a file open for writing at a time.

Looking over the code to see if this was true revealed Cause 4. It turns out that the file is built up in several phases:

1. Generate the entries for `localhost' and `loghost' in a temporary file.

2. Append the entries for machines I am likely to use often to the temporary file.

3. Append all the other entries to the temporary file.

Because this is done as a shell script, each phase opens the file, appends to it, and then closes it. That means that file locking would not have avoided the race condition.

One person suggested to me that I should have built /etc/hosts in a temporary file rather than immediately overwriting the good copy. In fact, I did just that. However, since I `knew' that the program would never run more than once at a time, I used a fixed name for the temporary file. Since that name was in my home directory, each process on each machine used the same file.

Finally, I will note that I know how to make the program safe against multiple accesses, even without file locking: use a separate temporary file for each invocation and then, instead of copying the file to its final place, move it there atomically. I don't know how to make such things automatic, though, and it's far from clear that one should always take such precautions, even for programs one believes will be run only on one's own behalf. --Andrew Koenig ark@research.att.com

------------------------------

Date: Fri, 09 Dec 94 10:27:00 EST From: "Herb Lin" <hlin@nas.edu> Subject: Rights and Responsibilities of Participants in Networked Communities

The Computer Science and Telecommunications Board (CSTB) is pleased to announce the availability of a new report entitled _Rights and Responsibilities of Participants in Networked Communities_. Given increasing public interest and concern over the behavior of people on electronic networks, the report seeks to illuminate, to question, and to articulate difficult issues that arise in this context, and thus to help to lay a foundation for a more informed public debate and discussion of the rights and responsibilities of those who operate in this domain.

The report is based on a workshop and a public forum involving technologists, lawyers, policy analysts, network service providers, and network operators in the exploration of several hypothetical but plausible scenarios in four areas (free speech, electronic vandalism, intellectual property interests, and privacy). The report illustrates how disagreements in these areas are rooted in value judgments; for example, the extent to which continuity with past precedents is desirable. Lawyers and policy-makers often argue that rights and responsibilities in a new domain inherently derive from existing rules, the report says. By contrast, technologists with extensive network experience often assert that with a new medium and a new form of human expression should also come new rules of social intercourse. The report notes that these four areas have always been inherently contentious, but over time certain compromises and understandings have evolved that guide what people do when communicating via traditional media such as print, telephone, radio, and television. Today the proliferation of networking technology threatens this state of understanding because it changes the environment in which previous compromises were achieved, leading to a re-examination of the same fundamental issues.

The report is available from the National Academy Press for $25.00 (prepaid) plus $4.00 shipping for the first copy and $.50 shipping for each additional copy; tel. (202) 334-3313 or 1-800-624-6242. It will also be available soon on the WorldWide Web at http://www.nas.edu; via Gopher at gopher.nas.edu; and via FTP at ftp.nas.edu.

The National Research Council is the principal operating arm of the National Academy of Sciences and the National Academy of Engineering. It is a private, non-profit institution that provides independent advice on science and technology issues under a congressional charter. CSTB addresses national scientific and policy issues in computing science, telecommunications, and computer technology and their applications.

------------------------------

Date: Fri, 9 Dec 1994 07:16:40 -0500 (EST) From: "Dr. Frederick B. Cohen" <fc@all.net> Subject: Searching RISKS et al.

I have recently setup a Mosaic server with on-line copies of the RISKS Digest and other on-line material on similar topics. This server allows the user to search full text for any given word, and produces a listing of all occurrences (in context). The user then selects the desired item(s) and views the files they occur in.

I am writing to RISKS for 2 reasons. One is to ask permission to use the Risks Forum in this way (after all, it is copyrighted as of its creation), and the other is to inform your readers of the proper URL (http://all.net:8080).

Please don't search for anything like "and". You will find that the search produces a LOT of useless results.

FC

[FRED: Many thanks for doing this! I'll add it to the Info. Yes, you have my permission. But I trust that your home page will request users to respect any copyrights (explicit or implicit) and fair-reuse practices. Also, suggest that folks should remember to scan for subsequent corrections... PGN]

------------------------------

Date: 11 December 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 <risks-request@pica.army.mil> (Dennis Rears <drears@pica.army.mil>). UK subscribers please contact <Lindsay.Marshall@newcastle.ac.uk>. 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 <risks-request@csl.sri.com> (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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 ARE MOVING SOON (BEWARE: THE NEW SYSTEM IS CASE SENSITIVE): ftp unix.sri.com cd risks

CURRENT ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR> or cwd risks:<CR>, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues of earlier volumes, "get [.i]risks-i.j<CR>" (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<CR>" logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=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 or http://all.net:8080 (the latter courtesy of Fred Cohen).

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.63 ************************