Subject: RISKS DIGEST 16.66
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Tuesday 20 December 1994  Volume 16 : Issue 66

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** HAPPY HOLIDAYS!!! *****

***** NOTE, THE SRI RISKS ARCHIVE SOURCE has moved to unix.sri.com.  *****
***** See last item for further information, disclaimers, etc.       *****

 Contents:
Microsoft has no plans to acquire Catholic Church (from EDUPAGE)
Mistaken Identity (Tom Knoedler)
Emergency Broadcast System Goes Automatic? (Darrell F. Oresky)
Brands Burn the Bull's Behind (Peter Wayner)
Followup to "No I'm not Newt" (Ted Koppel)
Re: Oral Hackers (Steve Holzworth)
Re: Technology Under the Weather (Ross Oliver)
Intel announces new Pentium replacement policy (Rich Kulawiec)
Pentium bug as data management problem (Rob Aitken)
Testing the Pentium bug (Daniel Essin)
Mary Payne and "Good to the last bit!" (Paul A. Karger)
Pentium FDIV problem - so what's new ? (A. Padgett Peterson)
Spreadsheet Errors Study (Ray Panko)
The Status of Disclaimers (Dick Nickalls)
CFP: New Security Paradigms Workshop (Catherine A. Meadows)
CFP: Safety and Reliability of Software Based Systems (Stella Page)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Mon, 19 Dec 94 11:43:01 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Microsoft has no plans to acquire Catholic Church (from EDUPAGE)

The latest Internet hoax has Microsoft acquiring the Roman Catholic Church,
including exclusive electronic rights to the Bible. The story, written
under an Associated Press byline, says the agreement provides for Pope John
Paul II becoming the senior vice president of the company's new Religious
Software Division, and two Microsoft senior vice presidents being invested
in the College of Cardinals. The fake story included a promise from Bill
Gates to "make the sacraments available online for the first time."
Officials at Microsoft and AP said they didn't know where the story
originated. (Tampa Tribune 12/17/94 B&F10)

 [FROM EDUPAGE, 18 Dec 1994, which concludes thusly:]
 [EDUPAGE is what you've just finished reading. To subscribe to Edupage: send
 a message to: [email protected] and in the BODY of the message type:
 subscribe edupage Count Dracula (assuming that your name is Count Dracula;
 if it isn't, substitute your own name) ... To cancel subscription to
 Edupage: send a message to: [email protected] and in the BODY of the
 message type: unsubscribe edupage.]

   [Several folks submitted the original hoax to RISKS.  It was not run
   here for a variety of reasons.  The omission was not a sacra-mental
   lapse on my part.  Fakes Vobiscum.  PGN]

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

Date: Wed, 14 Dec 94 13:50:00 PST
From: "Knoedler, Tom" <[email protected]>
Subject: Mistaken Identity

In the 19 December 1994 edition of *Newsweek*, read the `My Turn' column
entitled ``A Case of Mistaken Identity: On the Information Highway, you are
guilty until proven innocent'' by Michael W. Klein.  Mr Klein, an attorney
in New Jersey, was was falsely identified as a reckless driver because a
police clerk made a mistake on an address search.  Law enforcement personnel
were prepared to lock him up even though the physical descriptions did not
match, even though the demographics did not match, just because the warrant
had come out of the computer.

Thomas Knoedler  [email protected]

   [... A familiar kind of case for long-time RISKS readers.  PGN]

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

Date: Fri, 16 Dec 94 14:48:28 EST
From: [email protected] (Darrell F. Oresky)
Subject: Emergency Broadcast System Goes Automatic?

I heard a short note on the local all news radio station recently about a
planned upgrade to the Emergency Broadcast System (EBS). This upgraded
service would allow the EBS to reach radio and TVs that were not actually
turned on when the broadcast was sent. The intent is to inform even those
misfortunates who were not actively listending or watching at the time of an
emergency. I assume such an upgrade would require changes to radios and TVs
to allow them to be turned out remotely via some sequence of commands
carried over the airwaves?  One potential risk of this configuration is that
one could remotely activate speakers or video devices that may be part of
the television or radio, and use this mechanism to listen in without anyone
knowing.

Darrell Oresky  [email protected]

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

Date: Tue, 20 Dec 1994 09:36:51 -0500
From: [email protected] (Peter Wayner)
Subject: Brands Burn the Bull's Behind

The Sports Monday of the NYT (12/19/94) ran a headline calling one
basketball team the "Pentium" of basketball teams. It wasn't because
they were playing 2-3 times  faster than last year's team.

This illustrates the RISKS of imprecise technical language. There was no
real meaning to the word "Pentium" before. The Intel, AMD and other clones
were all supposed to be interchangeable. The brand name was just a marketing
ploy that was even more hollow than the work of the folks at P&G, Coke or
Pepsi. After all, there _is_ a difference between colas. So, if there is no
meaning to the word, it shouldn't be surprising that the first hint of a
meaning, no matter how irrational, rushes in to fill the vacuum.

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

Date: Fri, 16 Dec 1994 18:50:38 -0700 (MST)
From: [email protected] (Ted Koppel)
Subject: Followup to "No I'm not Newt"

To add to Steve Barr's comments about AOL and how anyone can have any name
on that system:

My real name is Ted Koppel.  There happens to be another fellow, a
broadcaster, who has the same name as I do.  I took my "ten free hours" on
AOL, and explored the system.  Not surprisingly, I used my name (actually
Tkoppel, which is a reasonable login variation).

One of the places to visit on AOL is an area 'owned' by ABC News.  I was in
there, reading some of their stuff, and talking in one of the forums there,
when I was told, in no unambiguous terms, to either get off the forum or
change my name.  Since my name is, after all, on my driver's license, I
figured that I had a pretty good right to use it :-) So I told the fellow
that.

It turns out that he is/was some sort of a staff person working for the ABC
Ted Koppel, and he was concerned that people would mistake ME for his Ted
Koppel (a legitimate risk, I suppose).  On the other hand, I'm not convinced
that threatening me rudely was the appropriate way to go about it.

By the way, I subsequently dropped AOL, partially for this reason, but
primarily because there was no 'killer app' that made me want to stay.

Ted Koppel * The UnCover Company * The CARL Corporation * [email protected]
Work: 404 242 8733 Fax: 404 242 8511

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

Date: Tue, 20 Dec 1994 04:40:19 GMT
From: [email protected] (Steve Holzworth)
Subject: Re: Oral Hackers (RISKS-16.65)

Mac 840AV machines (and presumably other AV machines) have a voice
recognition feature.  When we got ours, shortly after they had been
released, and before anyone started doing useful work, we used to have great
fun popping into someone's office and stating:

 "Computer, Restart, Yes."

whereupon the Mac would dutifully reboot. ("Shutdown" was another option...).

Steve Holzworth, SAS Institute, SAS/Macintosh Development Team, Cary, N.C.

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

Date: Fri, 16 Dec 1994 22:01:46 GMT
From: [email protected] (Ross Oliver)
Subject: Re: Technology Under the Weather (Symonds, RISKS-16.65)

This article is biased and oversimplified view of a complex set of
requirements.  I wonder whether the weather specialist quoted in the article
has an axe to grind against automated weather reporting systems.

The fact that the weather station report did not match current conditions is
not unusual, regardless of who or what is making the report.  Most airport
weather reports are made once per hour, so if the weather is changing
rapidly (for example, a storm front is moving in), actual conditions may be
quite different from what is reported in the last hourly observation.  This
is not the fault of the automated observation system.  Pilots must take into
account when the observation was made, and how likely it is that conditions
may have changed.

The article also stated, "the machines also cannot tell when there are
clouds above 10,000 feet," implying a crippling limitation.  In reality,
clouds more than 5,000 or 6,000 feet above the ground are not particularly
relevant to airport operations (i.e. takeoffs and landings), so less effort
is expended to gather data on high clouds.

Ross Oliver

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

Date: Tue, 20 Dec 94 08:55:07 EST
From: [email protected] (Rich Kulawiec)
Subject: Intel announces new Pentium replacement policy

Public radio's "Marketplace" show is carrying a story this morning
announcing that Intel will now replace, on request, any and all Pentium
processors.  This is a revision of their earlier policy, which required that
Pentium owners justify the replacement to Intel staffers.  I suspect that
they could no longer afford the bad publicity or the manpower cost
associated with the phone banks used to screen replacement requests.

  [I suppose it is the corrected chip that will be called RePentium.  PGN]

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

Date: Fri, 16 Dec 1994 12:44:26 -0800
From: Rob Aitken <[email protected]>
Subject: Pentium bug as data management problem

With all the discussion of verification, formal or otherwise, it seems to
me that another explanation is being overlooked. Given the immense amount
of data associated with a given chip design, it could be that the hardware
implementation of the Pentium divide unit and the software representation
which was verified (by whatever techniques Intel uses) were not the same.

Before a chip is fabricated, it exists as a huge software database, often
including several mutually incompatible representations, with a large number
of people using and changing it. Version control is a serious problem. If
a design change was made after verification, or if verification was
inadvertently performed on an earlier design, it is easy to see how a
bug could slip in, even with formal verification.

If something like this did in fact happen, then the Pentium bug is an
example of a much more mundane data management RISK than it has been made
out to be, both in this forum and elsewhere.

Rob Aitken

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

Date: Sat, 17 Dec 94 1:10:26 PST
From: Daniel Essin <[email protected]>
Subject: Testing the Pentium bug

I need a new, faster computer so I went to some computer stores to look at
the Pentium 90's. Knowing of the fpu bug, I took my trusty formula snared off
the net to test them.

>put in 5505001/294911. The correct answer is 18.66665197297. The Pentium
>produced 18.666092939000.

I carried out this test on two Pentium machines in the store using windows
calculator. they both produced the wrong answer. A 486/66 of the same brand
produced the correct answer.

When I asked the sales people about the bug,
they said that the also had a test routine so we tried it. The instructions
were to perform the use qbasic and run the following program:
PRINT (4195835 * 256)/(3145727 / 256)

Their instructions say that the correct answer is  87413.2569545927.

Both Pentiums produced the correct answer - however - they also produced the
correct answer to 5505001/294911. I suspect that since qbasic has to run on
oldx86 machines that lack fpu's, all floating point is probably done with a
software emulator. Using this test, the store will never identify a single
chip as defective creating a false sense of security with the customers and
avoiding the difficulty of getting chips that are actually defective
replaced.

caveat emptor

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

Date: Fri, 16 Dec 94 10:06:30 -0500
From: "Paul A. Karger" <[email protected]>
Subject: Mary Payne and "Good to the last bit!"

Tony Lauck commented on Mary Payne's work on assuring that DEC's computational
routines always gave good results.  I also worked with Mary at DEC, and was
VERY impressed with her commitments to mathematical accuracy.  Her motto at
the time was that the computations should be "Good to the last bit!"

I have to agree that between Mary's work on algorithmic analysis and DEC's
VERY extensive testing of instruction sets on each new processor model, it
would have been very unlikely for a bug of the severity of the Pentium FDIV
problem to have gotten out on a VAX or an Alpha processor.

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

Date: Fri, 16 Dec 94 09:23:39 -0500
From: [email protected] (A. Padgett Peterson)
Subject: Pentium FDIV problem - so what's new ?

Might point out that there is nothing new in the FDIV problem, 80x86
chips are notorious for "different" microcode - for a semi-complete
list see the "86BUGS.LST" file in Ralf Brown's interrupt list.

For just one example, the operation of the instruction AAA ("ASCII Adjust
for Addition" hex code 37) is noticeably different when executed on an
8088 as opposed to an 80386 - with initial value of AX=FFFF on an 8088
the result will be 0005h while on a 386, 0105h will result.

As a consequence any financial programs using BCD addition and requiring
the AAA instruction may have different values on different systems.

Padgett

PS.  Of course, I do not know of any program using either BCD or AAA and
  AX=FFFFh should never result from BCD addition, but what does that
  matter (AAM 37 now... 8*) ?

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

Date: Fri, 16 Dec 1994 10:02:15 -1000
From: "Ray Panko" <[email protected]>
Subject: Spreadsheet Errors Study

I have recently completed a study on the types of errors that people make
when they uses spreadsheet programs.  I am currently writing up the results.
If you know of previous research that looked at spreadsheet errors other
than the Michigan work of Olson and others or the Brown and Gould study at
IBM, I would be grateful for citations or other information.

Basically, we found that student spreadsheeters have about the same
error rates as professional programmers.  About five and a half percent
of their cells have errors before debugging.  The problem is that they
did not spontaneously debug, a lack seen in the Brown and Gould lab
study and also in two ethnographic studies of real world
spreadsheeters.

Given these error rates and apparent lack of deep debugging, the question is
not what fraction of spreadsheets have errors but rather how many errors the
typical large spreadsheet has.

Aloha, Ra3y (the 3 is silent)

Prof. Raymond R. Panko, Decision Sciences Dept, College of Business Admin. U
of Hawaii, 2404 Maile Way, Honolulu, HI 96822  [email protected] (808) 956-5049

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

Date: 17 Dec 1994 10:28:18 GMT
From: [email protected]
Subject: The Status of Disclaimers

This is a HELP message.  Can anyone out there direct me to any info/archive
which will tell me the current state of disclaimers.  I am writing some
programs for medical use, and have come across the problem of how to phrase
the disclaimer so that it stands up in court. The problem seems to be, at
least in the UK, that one cannot say "..we disclaim all liability.."  since
apparently one has to put a sensible and realistic liability limit in the
disclaimer.  Perhaps some folk can help me here.

Dick Nickalls,, Dept Anaesthesia, City Hospital, Nottingham, UK
[email protected]   [email protected]

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

Date: Thu, 15 Dec 94 19:33:40 EST
From: [email protected] (Catherine A. Meadows)
Subject: CFP: New Security Paradigms Workshop

                            CALL FOR PAPERS
                       NEW SECURITY PARADIGMS '95

       A Workshop Sponsored by ACM SIGSAC, DoD, and the Aerospace Institute

                               Residence Inn
                   University of California at San Diego
                               La Jolla, CA
                            August 22-25, 1995

Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the
way to new possibilities.  This workshop explores radical new models for
computer security, trusted system integration, and intercomputer networking
security.  The goal is to develop transcendent solutions that provide the
flexibility and interoperability users require in trusted systems.

We offer a creative and constructive workshop environment for about 25
participants at a small campus inn in scenic La Jolla adjacent to San Diego.
Dress is casual. The tone is exploratory rather than critical.  The refereed
papers will be printed in a workshop proceedings.

To participate, submit preferably via email a research paper or a 5-10 page
position paper to Program Chairs John Dobson and Catherine Meadows at the
email addresses listed below by April 1, 1995.  Alternatively, submit five
copies of a hard-copy paper to either program chair by March 24, 1995.  The
Program Committee will referee the papers and notify authors of acceptance
status by June 9, 1995.

Cost of the workshop, lodging, and meals will be about $550.  Scholarships
are available.

                         WORSHOP ORGANIZERS

Workshop Chair:

Hilary Hosmer, Data Security, Inc., 58 Wilson Road, Bedford, MA
+1 (617)-275-8231 (voice and fax)  [email protected]

Program Co-Chairs

John Dobson, Computing Science Department, University of Newcastle
Newcastle NE1 7RU, UK  +44 91-222-8228  [email protected]

Catherine Meadows, Naval Research Laboratory, Code 5543, Washington, DC 20375
+1 (202)-767-3490 (voice)  +1 (202)-404-7942 (fax)
[email protected]

Program Committee:

Thomas Haigh, Secure Computing Corporation
Deborah Hamilton, Hewlett Packard
Leonard LaPadula, MITRE
Ruth Nelson, Information System Security
Pierangela Samarati, Universita di Milano
Marvin Schaefer, Arca Systems
Bruce Schneier, Counterpane Systems
Olin Sibert, Oxford Systems
Adrian Spalka, University of Bonn
Daniel Sterne, Trusted Information Systems

Local Arrangements: Dr. Thomas Lincoln (Rand)   +1 (310)-393-0411

Publications: Deborah Hamilton (Hewlett Packard)

Scholarships: Prof. Ravi Sandhu (George Mason Univesrity) +1 (703)-993-1659

Treasurer: Janet Haley (Haley Computer Services) +1 (609)-266-1471

Registration Chair:  James Williams (MITRE)     +1 (619)-223-2301 ext 31

ACM SIGSAC Liaison: Dixie Baker (Aerospace)     +1 (310)-336-7998

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

Date: Tue, 20 Dec 94 12:53:26 GMT
From: Stella Page <[email protected]>
Subject: CFP: Safety and Reliability of Software Based Systems

European Network of Clubs for Reliability and Safety of Software
Centre for Software Reliability

       SAFETY AND RELIABILITY OF SOFTWARE BASED SYSTEMS
             Reims, France, 12-15 September 1995

                ANNOUNCEMENT & CALL FOR PAPERS
                   12th Annual CSR Workshop
                1st Annual ENCRESS Conference
     Supported by the EC ESSI Programme and Lloyd's Register

In the past decade, there have been enormous advances in the use of
computers - and hence software - in areas where safety and reliability are
of significance both to individual users and to society at large. Examples
can be found in all sectors of industry: railway signalling is increasingly
computerised; fly- by-wire aircraft are the current technological trend in
civil aviation; motor car engines and braking systems are computer-
controlled; programmable logic controllers (PLCs) used in the process
industries have increasingly complex software embedded within them; and
commercial companies of all sizes become ever more dependent on the reliable
operation of their computer systems.

These systems do not always deliver the levels of safety and reliability
which users and society are entitled to expect.  There are many reported
examples of software-related failures which have caused, or had the
potential to cause, death, injury, environmental damage, or significant
economic loss. These include deaths in hospitals of patients undergoing
radiotherapy treatment, software-defect induced release of sufficient water
from a reservoir to flood a valley, lost space-craft, and company failures.

Very often, these incidents could have been prevented, or their consequences
reduced, by better awareness of safety and reliability issues as they apply
to computer-based systems.  Ideally, developers of systems should have
evidence that their approach to system development is likely to lead to the
required levels of safety and reliability. Often, evidence of this sort will
form part of a safety case, or other justification for system reliability
and/or safety, that has to be presented for approval or acceptance by an
appropriate authority.

Many projects in the ESSI programme aim to produce evidence to support the
use of particular technologies, in the development of safe and reliable
systems. These projects are particularly encouraged to submit papers to this
conference, which has been selected as one of the events at which ESSI
Application Experiments can present their results for peer review and
evaluation.

This is an open call for papers: we also seek other papers which argue for
the suitability of particular technologies, methods or management approaches
for use in developing reliable and safe systems, especially those which
present the results of industrial experience.

Topics that could be addressed include:

  A historical perspective on safety cases, and on how the current
  regulations requiring the production of safety cases have arisen.

  How do software engineering methods and tools contribute to
  product safety, reliability, etc.?

  What evidence is there to support the use of particular
  technologies to achieve reliable systems?

  How do organisations deal with the safety and reliability of
  PES? Do different industrial sectors deal with PES safety and
  reliability in a similar manner?

  Should we focus on management procedures more and technology
  issues less? (Some accident reports suggest this is so.)

  Are tightly coupled time critical systems inherently less
  safe or reliable than other systems?

  How do software metrics, software reliability models, etc.,
  relate to dependability attributes?

  How do we deal with the integrity of evidence used in safety arguments?

  What is the impact of organisational rules and work practices
  on safety and reliability?

Dates for Authors
=================
Authors are invited to submit extended abstracts (two A4 pages),
or near full papers, to Carol Allen at the address given below.
Papers should be written in English which will be the language
of the Workshop/Conference. The following dates have been set:

  Submission of abstracts/papers          31st January 1995
  Notification of acceptance              28th February 1995
  Announcement of provisional programme   31st March 1995
  Workshop version of paper available     31st May 1995

The proceedings will be published following the Workshop. As
there is a requirement for the proceedings to be edited changes
may be requested of authors after the papers have been
presented.

Organising and Programme Committee
==================================
Roger Shaw      Chair              Lloyd's Register
Carol Allen     Administration     City University
Ole Anderson                       DELTA (Denmark)
Tom Anderson                       Newcastle University
Robin Bloomfield                   Adelard
Sandro Bologna                     ENEA CRE-Casaccia (Italy)
Annie Combelles                    Objectif Technologie (France)
Chris Dale                         ENCRESS Project Manager
Norman Fenton                      City University
Bev Littlewood                     City University
Bob Malcolm                        Malcolm Associates
Francesca Saglietti                ISTec (Germany)
Peter Scharbach                    Lloyd's Register

Contacts:
=========
Chairman: Roger Shaw             Administration: Ms Carol Allen
Lloyd's Register                 Centre for Software Reliability
Lloyd's Register House           City University
29 Wellesley Road                Northampton Square
Croydon                          London
CRO 2AJ                          EC1V 0HB

Tel: +44 (0)181 681 4818         Tel: +44 (0)171 477 8421
Fax: +44 (0)181 681 4839         Fax: +44 (0)171 477 8585
email: [email protected] email: [email protected]

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

Date: 15 December 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 yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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

CURRENT ARCHIVES: "ftp unix.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; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username,
password; [email protected] and WAIS are alternative repositories.
See 15/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.66
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.