Subject: RISKS DIGEST 16.17
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Friday 17 June 1994 Volume 16 : Issue 17
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** SORRY FOR ABORTIVE ATTEMPT AT MIME-ING RISKS in RISKS-16.15.
***** I MAY TRY AGAIN SOME DAY IF I GET THE RIGHT FORMAT!
***** See last item for information on RISKS (comp.risks) *****
Contents:
Poulsen guilty of L.A. charges (Mich Kabay)
Counterfeit graduation tickets (Mich Kabay)
"Virtual Billboard" on TV (R. Peter Jackson)
Misdirected Mail (Jeffrey Austen)
Revenue Canada database allows birthday change (John Howard)
NIST Response to Blaze Attack on Clipper (Ed Roback)
ROLM phones and "Do Not Disturb": how to lose calls (Rob Levandowski)
A320 hull losses: Lies, damned lies and statistics (Pete Mellor)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: 16 Jun 94 18:01:35 EDT
From: "Mich Kabay [NCSA Sys_Op]" <
[email protected]>
Subject: Poulsen guilty of L.A. charges
>From the United Press International newswire (94.06.14 @ 18:45 EDST) via
Executive News Service (GO ENS) on CompuServe:
"Hacker Pleads Guilty to Fraud", By ELKA WORNER
LOS ANGELES, June 14 (UPI) -- A computer hacker accused of breaking into
computer systems to rig promotional contests at radio stations, eavesdrop on
private citizens and thwart police investigations, pleaded guilty Tuesday to
fraud. Kevin Poulsen, 28, of Menlo Park, faces 40 years in prison and a
$1,750,000 fine when he is sentenced Oct. 17.
He pleaded guilty in federal court to computer fraud, interception of wire
communications, mail fraud, money laundering and obstruction of justice.
The author summarizes the case against Poulsen [I added details she didn't
include]:
o [manipulated the phone systems to cheat in radio-station call-in
contests that awarded prizes to a specific caller in sequence]; he stole "two
Porsches from radio station KIIS-FM, $20,000 in cash from KPWR-FM and at least
two trips to Hawaii and $2,000 in cash from the same station."
o used lies and counterfeit IDs to claim and then sell his prizes.
o uncovered FBI-run businesses, spotted FBI wiretaps and listened in on
conversations of ordinary citizens.
o called a confederate "minutes after his arrest to ... hide the
computers used in his illicit activities."
o lived on the run for 18 months after being indicted in San Francisco
by a grand jury until his arrest in April 1991 .
o in July 1994, he will be tried "on 18 counts of telecommunications and
computer related fraud, including charges that he stole Pacific Bell access
codes to invade an Army computer network and to obtain information used in FBI
investigation of former Philippine President Ferdinand Marcos."
o worked for the Soviet consul in S.F. by obtaining unpublished telephone
numbers."
Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn
------------------------------
Date: 16 Jun 94 18:01:29 EDT
From: "Mich Kabay [NCSA Sys_Op]" <
[email protected]>
Subject: Counterfeit graduation tickets
>From the Reuter newswire (94.06.14 @ 14:25 EDST) via Executive News Service
(GO ENS) on CompuServe:
DARTMOUTH ALUMNUS CAUGHT SELLING PHONY GRADUATION TICKETS
HANOVER, N.H., June 14 (Reuter) - A former Dartmouth College student was
arrested for selling counterfeit graduation tickets for the event at his Ivy
League alma mater, police said Tuesday. Corby Edward Page, 23, a computer
programmer from Houston, Texas and a 1992 Dartmouth graduate, admitted to
making the fake tickets on his computer and selling them before the June 12
graduation for $15 each, said Hanover Police Sergeant Christopher O'Connor."
According to the story, a student who bought a bogus ticket "called police
after noticing the fake tickets were different from the real ones." The idiot
grad was caught "in the lobby of the posh Hanover Inn, opposite the Dartmouth
campus, as he sold tickets, police said."
He was charged with fraud.
------------------------------
Date: Thu, 16 Jun 1994 23:07:10 -0700 (PDT)
From: "R. Peter Jackson" <
[email protected]>
Subject: "Virtual Billboard" on TV
On Wednesday, June 15, 1994, the Los Angeles Times reported on page D7 in
their relatively new weekly section called "The Cutting Edge
Computing/Technology/Innovation" the following:
"Virtual Billboard" Is Sign of the Times
Baseball teams would love the revenue from behind-the-batter billboards, and
advertisers like the idea of being on screen without fear of remote-control
zapping. But purists denounce the idea as antithetical to the tradition of the
game, and some players say the signs make it harder to see the ball.
Now inventors have devised a system that will create electronic billboards
visible only to people watching on TV. Princeton Electronic Billboards Inc. in
Princeton, N.J., has been testing "virtual billboards" with the Baltimore
Orioles and its telecasters. Working with the David Sarnoff Research Center,
the firm developed a computerized system that inserts images electronically
into TV shows.
Before a game, the TV cameras scan the arena and "memorize" features of the
park, such as creases in the padded wall behind home plate and other
boundaries that define a virtual billboard. When the camera passes those
features during the telecast, the system inserts the sign, or the part of it
visible in the camera's frame of reference.
Ballplayers on the field appear to walk in front of the sign. Ideally, the TV
audience will be unable to tell whether the billboard hangs in the ballpark or
only in cyberspace. Local sponsors could buy a billboard in a national
telecast, and a national advertiser could deliver different messages in each
market.
Princeton Electronic hopes to make the system available commercially before
the baseball season ends this fall."
It seems obvious that the RISKS increase as the truth of the picture in the TV
medium can be selectively and partially modified. It is difficult enough now
for many people to tell whether what is seen on TV is real or fake [note the
many similarities between national network TV news, major metropolitan network
news and the recreated news in Hard Copy and its several competitors.]
R. Peter Jackson, Mariposa Computer Services, 982 Jimeno Road, P. O. Box 149,
Santa Barbara, California 93102-0149 USA 1-805.963.4305 <
[email protected]>
------------------------------
Date: Thu, 16 Jun 1994 11:24:16 -0600
From:
[email protected] (Jeffrey Austen)
Subject: Misdirected Mail
I received the following in the mail the other day. Quite amusing. I wonder
if the CIA would send out a similar message if one of their secrets got out?
>One of IBM's electronic mail distribution nodes experienced a
>problem routing mail from Wednesday June 8, 1994, through
>approximately 7:00pm Thursday June 9, 1994. This may have
>resulted in your having received proprietary information that
>was not intended for you. If you have received such
>information, please return it to the Internet address:
>
[email protected]
>without retaining any copies of it. If you have already
>destroyed or discarded the information, please confirm this by
>sending a note to this address stating that the information
>you received has been destroyed.
>
>If you are not sure whether you should have received certain
>information or if you have any other questions, please call
>xxx xxx at (xxx) xxx-xxxx.
Jeffrey Austen, Tennessee Technological University, Box 5004
Cookeville Tennessee 38505 U.S.A.
[email protected] (615) 372-3485
------------------------------
Date: Thu, 16 Jun 94 23:03:48 PDT
From:
[email protected] (John Howard)
Subject: Revenue Canada database allows birthday change
Something has just come to light that might be of interest to Risks readers
concerning my end of the year taxes here in Canada. For whatever reason, my
new accountant (who resides in a different city) filed my tax with a typo on
it: my birthday was off by one day. Well, as expected, the system the Feds
have sent me a note saying my birthday had changed from the last time I had
filed. The form asked me to come down to my local office to correct the error,
or if this wasn't an error don't worry about it.
How can they say "don't worry about it"? As far as I know people aren't
allowed to change their birthday! I chatted with the teller that helped me
correct the error. He said that his most memorable error was a situation where
a senior had transposed the middle digits of his year of birth to make him
younger by decades. The error was caught when the computer found a young
person claiming pension benefits.
The teller enlightened me by saying that personal data is taken from only the
most recent filing. I suppose this would be ok for a change of address or even
of name, but of birthday! Imagine your favorite ten risks....
John Howard
------------------------------
Date: Thu, 16 Jun 1994 17:29:40 -0400 (EDT)
From:
[email protected]
Subject: NIST Response to Blaze Attack on Clipper
Note: The following material was released by NIST in response to recent
articles regarding AT&T/Matt Blaze and the key escrow chip. A second more
technical response follows.
-------------------------
June 2, 1994
Contact: Anne Enright Shepherd
(301) 975-4858
The draft paper by Matt Blaze* describes several techniques aimed at
circumventing law enforcement access to key escrowed encryption products based
on government-developed technologies.
As Blaze himself points out, these techniques deal only with the
law-enforcement feature, and in no way reduce the key escrow chips' inherent
security and data privacy.
-- "None of the methods given here permit an attacker to
discover the contents of encrypted traffic or
compromise the integrity of signed messages. Nothing
here affects the strength of the system from the point
of view of the communicating parties...." p. 7.
Furthermore, Blaze notes that the techniques he is suggesting are
of limited use in real-world voice applications.
-- "28 minutes obviously adds too much latency to the
setup time for real-time applications such as secure
telephone calls." p. 7.
-- "The techniques used to implement them do carry enough
of a performance penalty, however, to limit their
usefulness in real-time voice telephony, which is
perhaps the government's richest source of wiretap-
based intelligence." p. 8.
Anyone interested in circumventing law enforcement access would most likely
choose simpler alternatives (e.g., use other nonescrowed devices, or super
encryption by a second device). More difficult and time-consuming efforts,
like those discussed in the Blaze paper, merit continued government review --
but they are very unlikely to be employed in actual communications.
All sound cryptographic designs and products consider trade-offs among design
complexity, costs, time and risks. Voluntary key escrow technology is no
exception. Government researchers recognized and accepted that the law
enforcement access feature could be nullified, but only if the user was
willing to invest substantial time and trouble, as the Blaze report points
out. Clearly, the government's basic design objective for key escrow
technology was met: to provide users with very secure communications that will
still enable law enforcement agencies to benefit from lawfully authorized
wiretaps. It is still the only such technology available today.
Today, most Americans using telephones, fax machines, and cellular phones have
minimal privacy protection. The key escrow technology -- which is available
on a strictly voluntary basis to the private sector -- will provide the
security and privacy that Americans want and need.
* Statements from "Protocol Failure in the Escrowed Encryption
Standard," May 20 draft report by Matt Blaze, AT&T Bell
Laboratories
-----
Note: The following provides additional technical material in response to
questions regarding a recent paper by Matt Blaze on key escrow encryption.
--------------------------------------
Technical Fact Sheet on Blaze Report and Key Escrow Encryption
Several recent newspaper articles have brought attention to a report
prepared by Dr. Matthew Blaze, a researcher at AT&T's Bell Labs. These
articles characterize a particular finding in Blaze's report as a ~flaw~ in
the U.S. government's key escrow encryption technology. None of the findings
in Dr. Blaze's paper in any way undermines the security and privacy provided
by the escrow encryption devices.
The finding which has received the most publicity could allow a
non-compliant or ~rogue~ application to send messages to compliant or
~non-rogue~ users which will not be accessible by law enforcement officials
through the escrowed encryption standard field called the Law Enforcement
Access Field (LEAF).
Dr. Blaze's approach uses the openly disclosed fact that the LEAF
contains 16-bit checkword to prevent rogue users from modifying the law
enforcement access mechanism. This 16-bit checkword is part of the 128-bit
LEAF, which also includes the enciphered traffic key and the unique chip
identifier.
Dr. Blaze's method is to randomly generate different 128-bit LEAFs until
he gets one that passes the checkword. It will take on average 216, or 65,536
tries. This is not a formidable task; it could be done in less than an hour.
Dr. Blaze questions the adequacy of a 16-bit checkword and suggests using a
larger one, to ensure that the exhaustion attack would be so time consuming as
to be impractical.
The chip designers recognized the strengths and limitations of a 16-bit
checkword. Following are the reasons why they chose to use a checkword of only
16 bits:
* There were four fundamental considerations that the designers considered in
choosing the LEAF parameters.
These were:
(1) ease of access by authorized law enforcement agencies,
(2) impact on communications,
(3) a sufficiently large identifier field which would not constrain
manufacturers, and
(4) the difficulty required to invalidate the LEAF mechanism by techniques
such as those described by Dr. Blaze.
* The purpose of the LEAF is to preserve law enforcement's ability to access
communications in real-time. The encrypted traffic key, which enables them to
do this, is 80 bits long. In addition to this 80-bit field, the LEAF must
contain the unique identification number of the key escrow encryption chip
doing the encryption.
* The size of the identifier field was the subject of considerable
deliberation. In the earliest considerations it was only 25 bits long. The
chip designers recognized that 25 bits did not offer enough flexibility to
provide for multiple manufacturers of key escrow devices. Different chip
manufacturers would need manufacturer identifiers as well as their own chip
identifiers to ensure that identifiers are unique. Eventually, the designers
agreed that 32 bits would adequately meet this requirement.
* In many environments, error-free delivery of data is not guaranteed, and
there is considerable concern by communication engineers that requiring
error-free transmission of a fixed field (the LEAF) could make the encryption
device difficult to use. In early discussions with industry, they were opposed
to any checkword. In the end, they agreed it would be acceptable if the size
of the LEAF was restricted to 128 bits. This left 16 bits for a checkword to
inhibit bypassing the LEAF. While recognizing the possibility of exhausting
these 16 bits, the designers concluded that 16 bits are adequate for the first
intended application. Security enhancements are being made for other
applications, such as the TESSERA card.
Note that computations are required to search for a matching checkword, which
then has to be properly substituted into the communications protocol. The
performance and cost penalties of the search operation are significant for
telephone, radio, and other such applications, thus providing adequate
protection against this technique for bypassing the LEAF.
In summary:
* Although this technique would allow one to bypass the LEAF, the security
provided by the escrow encryption devices would not be altered. Users'
information would still be protected by the full strength of the encryption
algorithm.
* Dr. Blaze was accurate in noting that these attacks are of limited
effectiveness in real-time telephony.
* When designing the key escrow chip, NSA emphasized sound security and
privacy, along with user friendliness. The attacks described by Dr. Blaze were
fully understood at the time of initial chip design. The use of 16 bits for
the checkword was an appropriate choice in view of the constraints of a
128-bit LEAF. It provides excellent security for real-time telephone
applications with high assurance that law enforcement's interests are
protected.
* Dr. Blaze's research was done using prototype TESSERA cards. As part of the
family of planned releases/upgrades, NSA already has incorporated additional
security safeguards into the production TESSERA cards to protect against the
kinds of attacks described by Dr. Blaze.
------------------------------
Date: Thu, 16 Jun 94 12:26:55 GMT
From:
[email protected] (Rob Levandowski)
Subject: ROLM phones and "Do Not Disturb": how to lose calls
Here at the University of Rochester, students are given ROLMphone 120DCMs
in their rooms. These phones (or, more precisely, the digital switch that
they are connected to) have a function called "do not disturb". When the
appropriate code is entered into the keypad, the line is put into DND mode,
and it -will not ring- for any reason. However, if someone tries to call,
they hear ringing.
There are two problems with the implementation of this feature. First, the
code to activate and de-activate the feature is anything but intuitive.
Having lived off-campus for a while, I forget the exact code, but it is along
the lines of #6x. The code for speed-dialing numbers is #3x. On more than
one occasion I meant to hit a speed-dial and instead activated do-not-disturb.
This wouldn't be a big problem... except that there is no indication
whatsoever that you are in DND mode. No lights, no tones, no message to
callers. I missed calls for days the first time I did this... and a lot of
people got concerned because I "was never home".
This system should at the least have some sort of different dialtone or
indicator light to show that you won't be getting any calls. (God knows the
ROLM 120 has enough blinky-lights...) Likewise, since the switch is equipped
with PhoneMail, it would be nice if it could give an announcement... "The
party you have dialed is not accepting calls at this time."
The privacy may be nice when you're using your dorm room for, shall we say,
after-hours social research ;) -- but if you're forgetful like me, the
implementation is pretty troublesome.
Rob Levandowski, Computer Interest Floor associate / University of Rochester
[email protected]
------------------------------
Date: Thu, 16 Jun 94 19:45:06 BST
From: Pete Mellor <
[email protected]>
Subject: A320 hull losses: Lies, damned lies and statistics
This thread of the discussion was originally started by Wesley Kaplow
<
[email protected]> in RISKS DIGEST 16.15 under the title: "Does it matter
why A3??'s have a poor record?"
To recap, Wesley said (without citing a source):
> Already, Airbus Industry has lost more planes per delivered plane
> than other major aircraft manufacturer in the past 3 decades (Lockheed,
> Boeing, MD).
I contradicted this in RISKS 16.16, citing a table of statistics from an
article entitled ``Der Traum von Total Sicherheit'' ["The Dream of Total
Safety"], in the German magazine Focus, 38, 1993, pp18-21, and Wesley has
since agreed that his statement requires support (see his follow-up mailings).
The table was as follows:-
>Aircraft No. in Hulls % Losses
>Type Service Lost
>
>DC-9/MD-80 2065 68 3.29
>Boeing 727 1831 62 3.39
>Boeing 737 2515 57 2.27
>Boeing 747 988 22 2.23
>DC-10 446 21 4.71
>Airbus A300/310 636 7 1.10
>Airbus A320 411 4 0.97
Focus magazine cited "Luftfahrtindustrie" (NOTE: not "Lundfahrtindustrie",
as I originally transcribed it) as the source.
Since then, I have been jumped on from a great height by several RISKS
contributors who have accused me of abusing statistics. Since this is not
something I do deliberately, I would like to make the following points
(taking into account the various objections raised by those who have
written to me):-
1. I am well aware that the statistics above are incomplete. They do not
allow for the total operating time of each type. They do not distinguish
between losses due to on-board system failure and losses due to other
causes which could not possibly be blamed on the manufacturer (e.g.,
the Lockerbie bombing, the Vincennes shoot-down). They do not take
account of wear-out and natural retirement, so that the number shown
may be the "number sold" and not the "number in service". I quoted them
because they were all I had at the time (while being acutely aware of
their imperfections).
2. Wesley's original statement *is*, however, refuted by these statistics
*provided they are correct* (see point 3). A secondary question arises:
"Is this a meaningful measure of the safety of a type of aircraft?"
I will return to this in point 4.
3. Peter Ladkin pointed out to me that the source name that I had originally
misread as "Lundfahrtindustrie" and assumed to be some official body
which records air accident statistics, is in fact "Luftfahrtindustrie"
(well, it was in small print! :-) and means simply "Air Travel Industry".
In other words, the source cited by Focus magazine is totally vague, and
(as Peter said) about as authoritative as "I read it on the net"! :-)
The statistics I naively quoted therefore need substantiation.
4. What would convince Joe Public that a given aircraft type was safe to
fly? There are several possible measures of the safety of an aircraft
design (note: I do *not* pretend that this list is exhaustive):-
a) Deaths per passenger mile on the given type. This is used by the
aircraft manufacturing industry. Conclusion: air travel is the safest
way of going anywhere.
b) Deaths per passenger *hour* on the given type. This makes flying
about as safe as driving, but the risk would seem to be tolerable,
since a probability of 10^-4 per year of dying in a road accident
doesn't seem to worry most people (figures based on official UK
statistics).
c) Crashes (i.e., hull write-off) per revenue flight hour. This is used
by the certification agencies (FAA, JAA, etc.) when awarding an
airworthiness type certificate. The target is a maximum probability
of loss of aircraft of 10^-6 per flight hour due to *all* causes.
Historically, statistics show that *system-related* causes account for
1 in 10. The conservative assumption that there are 100 critical
systems on board then leads to the famous 10^-9 requirement for
probability of failure of an individual flight-critical system.
d) Crashes per cycle (take-off plus landing).
e) Crashes per example delivered (which is where we came in! :-)
f) Passenger deaths per cycle.
g) Serious incidents per flight hour or per cycle. (Q: "How many accidents
has the A320 had?" A: "Five - You forgot about Lille, where an A320
landed on top of a Mooney, taking off both its wings and the empennage,
and collapsing the A320's front gear. Since nobody was hurt, it doesn't
count, or does it?")
The whole picture is confused by the fact that the public perception
of risk is biased *against* rare events that kill lots of people, and
less against common events that kill a few. (In assessing any event that
loses the aircraft, you must assume the worst case: that you kill everyone
on board. If you crash a car, it's just you and the guy you hit!)
I don't pretend to give an answer here, simply raise a few pertinent
questions, whose answers (IMHO) are far from obvious.
5. A fairer comparison would be between the A320 and competing aircraft
*of the same generation*. I would like to thank Robert Dorsett for
the following:-
757 = 0 in eleven years.
767 = 1 in twelve years. (Lauda)
A320 = 4 in five years. (Air France, Indian Airlines, Air Inter, Lufthansa)
6. Given that all the statistics above are deficient (basically, they lack
an exposure time base), they do still tell us *something*. (In considering
a fleet above a certain size, we could assume roughly the same operating
hours per day for each example, and things like maintenance time, etc.,
would average out.) We could *tentatively* conclude that the A320 is a
long way from being a flying coffin, but also a long way from being the
safest aircraft ever, or even as safe as it should be, given its modernity.
The public perception of the A320 seems to be that it is the most
dangerous thing that ever left the ground. IMHO this is wrong, and we
should be careful not to spread false alarm.
There are, of course, better statistics (e.g., from Flight International)
and I shall attempt to locate a few. The best come from the air insurance
industry, but I am not sure that I can get my grubby paws on those for
reasons of confidentiality.
In the meantime, if anyone knows of a good source ... :-)
Also, how can I phrase an argument to convince my mother that I stand a
greater chance of being run over crossing St. Johns Road while walking from
Farringdon tube station to the University than I do of dying in an air crash?
Then I won't have to make long distance 'phone calls from the airport in
B*m***k Egypt to tell her we landed safely every time I go to a conference! :-)
Peter Mellor, Centre for Software Reliability, City University, Northampton Sq
London EC1V 0HB +44 (71) 477-8422
[email protected]
------------------------------
Date: 31 May 1994 (LAST-MODIFIED)
From:
[email protected]
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 <
[email protected]>
(Dennis Rears <
[email protected]>). UK subscribers please contact
<
[email protected]>. 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
<
[email protected]> (which is not automated).
CONTRIBUTIONS: to
[email protected], 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.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
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;
[email protected] 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
[email protected] .
------------------------------
End of RISKS-FORUM Digest 16.17
************************
