DP Tool Club 17/CD_ASCQ_17_101194.iso/vrac/risk1632.zip/RISK1632.TXT

Text File | 1994-09-11 | 32KB | 652 lines

RISKS-LIST: RISKS-FORUM Digest  Tuesday 16 August 1994  Volume 16 : Issue 32

         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:
Pin the tail on the Dante? (PGN)
Adventures in Debugging (Michael J. Stern)
Commercial identity on the Internet (Mich Kabay)
Desktop check forgery (Phil Agre)
Burglary suspects caught by Caller ID (Jonathan I. Kamens)
National Guard payment problems (Mich Kabay)
Escrowed keys vulnerable to chosen contraband attacks (Stephen R. Savitzky)
The Danger of Six-Digit Dates (Mike Sullivan)
A Minor Risk for Centenarians (Bruce Scott)
IRC bug (Andrew David Tinkham)
Privacy Conference (Dave Banisar)
Intrusion Detection Workshop announcement (Debra Anderson)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Tue, 16 Aug 94 7:58:42 PDT
From: "Peter G. Neumann" <[e-mail]>
Subject: Pin the tail on the Dante?

On 9 Aug 1994, an attempt was made to rescue Dante II (see RISKS-16.31) from
the Mt. Spurr crater.  A helicopter tried to lift Dante II by its half-inch
Kevlar-reinforced tether, but the tether snapped from the force of the
attempted liftoff.  The tether had survived earlier tests that demonstrated it
had sufficient strength to lift the 1700-pound robot; however, the tether may
have been wrapped around one of the VW-sized boulders as a result of Dante's
earlier movements.  (Tim Hegadorn, a CMU grad student, was injured in the
process.)

And, finally, on 12 Aug 1994, David Bares (civil engineer, and leader of the
CMU robot development effort) and an Army ``pathfinder'' climbed into the Mt.
Spurr volcano.  David removed the computer and electronics module, which were
then helicoptered out of the crater.  They then hooked up a sling so that the
robot itself could be hauled out.  Six of the robot's legs had been ``badly
dented'' --- but otherwise the robot appears ready for another mission.
[From what may be the final article in this series, by Charles Petit in the
*San Francisco Chronicle* on 16 Aug 1994, p. 2.]

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

Date: 10 Aug 1994 10:37:18 -0400
From: [e-mail] (Michael J. Stern)
Subject: Adventures in Debugging

This is from *New Scientist*, 2 Jul 1994.

'Tis just 40 years since North American TV stations started broadcasting in
colour, using the NTSC system. Officially NTSC was named after the National
Television System Committee which chose it. Unofficially NTSC has often been
called Never Thrice the Same Colour.

A journalist who used to cover the NTSC told us recently of a lighter moment
at the laboratories of the record company RCA in Princeton, New Jersey, where
the system was developed. Team leader George Brown laid on a final
transmission test. A colour camera was focused on a bowl of colourful fruit in
one lab, and the received signal was displayed in another lab on a prototype
colour tube. Just before the test Brown took a banana from the bowl and
painted it blue.

For the rest of the day the engineers at the receiving end struggled
desperately to find out how their new system was faithfully reproducing the
colour of red apples, orange oranges and green grapes, but resolutely
converting yellow into blue.

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

Date: 15 Aug 94 11:05:05 EDT
From: "Mich Kabay [NCSA Sys_Op]" <[e-mail]>
Subject: Commercial identity on the Internet

[Source: Address for Success: Internet Name Game; Individuals Snap Up
Potentially Valuable Corporate E-Mail IDs, By Stewart Ugelow, *The Washington
Post*, 11 Aug 1994, PGN abstracting from MK abstracting]

Jim Cashel has registered at least 17 E-mail addresses, including esquire.com,
hertz.com, trump.com.  Registration applications are honored in the order of
their requests.  If YOUR name has already been taken, you can choose another
name, or you can buy the rights, or you can try legal proceedings.  Adam Curry
is being sued for registering mtc.com.  Also registered are names such as
coke.com, nasdaq.com, and windows.com.  However, the laws are as yet unclear
on net addresses.  [This RISKS item should not be construed as an invitation
to run out and get into the name-registering lottery.  PGN]

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

Date: Mon, 15 Aug 1994 19:04:59 -0700
From: Phil Agre <[e-mail]>
Subject: Desktop check forgery

  Saul Hansell, New breed of check forgers exploits desktop publishing,
  *The New York Times*, 15 August 1994, pages A1, C3.

This article reports that it's easy to manufacture fake checks with widely
available desktop publishing software.  You need an original check, which you
can get from the trash, from a paid insider (usually a low-level employee), or
by standing outside check-cashing shops and paying people to let you photocopy
their payroll checks.  Then you need a scanner, and software to manipulate
the image.  Then you need check paper and a check printer (both of which are
readily obtained).  Finally, you need someone to pass the check -- someone
who'll take a cut to risk getting arrested.

The forgers and the banks are engaged in a technological arms race.  Tellers
can run checks through scanners to make sure they've got the right kind of
magnetic ink on them, but then magnetic-ink printers are widely available.
Image manipulation programs allow for "authenticating" stamps and signatures
to be forged as well.  When forged checks are discovered, some banks fax
the pertinent information to every other bank branch in the same region of
the country, figuring that the forgers have made several copies of the check
and are driving around cashing them as fast as they can before the alarm is
sounded.  And so on.

This story illustrates one of the many subterranean interactions between
computer technology and social institutions -- the tendency of applied
computing to change physical objects into hybrid things that have one foot
planted in cyberspace.  We've always relied on the relative immutability of
physical objects to do various kinds of work for us.  Computers make it easier
to synthesize many kinds of objects, including mutated copies of originals.
The obvious solution -- at least, the solution that's obvious within the
conventions of computer design -- is to give every check a digital "shadow".
For example, when an employer issues a payroll check, the check number and
amount might be registered digitally and made available on a server.  When
a check is presented for payment, the teller feeds the check into a scanner
that recovers the check number and payment amount from the magnetic ink and
then, rather like credit cards now, consults that server to see if the check
has been presented yet.

This is only one of the many social mechanisms through which people, places,
and things acquire digital shadows.  Each mechanism has a seemingly inexorable
logic through which the shadows cast by human artifacts and activities grow
more expansive and more detailed.  This process might be planned out in
advance or it might proceed through a reaction to unanticipated holes in the
system.  When the trends that precipitate further growth in the shadow system
are bad, or at least stigmatized, little attention is paid to alternatives
that might minimize the amount of personal information that is being gathered
while still providing genuine benefits and helping to prevent genuine ills.

What's your shadow like?

Phil Agre, UCSD

  [The ability to cloud men's minds also helps.  But sniffing out forgeries
  is itself an art: The Digital Shadow Nose!  <Shadowy laugh>  PGN]

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

Date: Wed, 10 Aug 1994 17:47:26 -0400
From: "Jonathan I. Kamens" <[e-mail]>
Subject: Boston Globe: Burglary suspects caught by Caller ID

From the "New England News In Brief" section of the August 10, 1994 edition of
*The Boston Globe*, here's a description of a situation in which a
technological innovation had a positive but unanticipated side-effect:

     Suspects dial ahead, are caught

Naugatuck, Conn. - Telephone technology has helped nab two burglary suspects
who had allegedly called ahead to see if anyone was home.  Police said one of
the suspects called Sunday and left a message on an answering machine asking
if anyone was there.  The burglars rewound the answering machine when they
arrived at the home, but did not notice that their number was recorded on a
Caller ID device.  Police traced the call to the apartment of Gregory Alves,
23, and his roommate, Gary Ingham, 19. (AP)

Jonathan Kamens  |  OpenVision Technologies, Inc.  |   [e-mail]

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

Date: 15 Aug 94 11:05:11 EDT
From: "Mich Kabay [NCSA Sys_Op]" <[e-mail]>
Subject: National Guard payment problems

A software bug in the cutover to a new computer system at the Defense Finance
and Accounting Center at Fort Benjamin Harrison in Indianapolis resulted in
900 Army National Guard members and over 7000 vendors suffering from almost
$100 million in delayed payments for a year.  The National Guard also wound up
with excessive payments.  No fraud implied.  [Source: An Associated Press item
by John Diamond, from Washington, D.C., 15 Aug 1994]

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

Date: Tue, 9 Aug 94 14:25:13 -0700
From: [e-mail] (Stephen R. Savitzky)
Subject: Escrowed keys vulnerable to chosen contraband attacks

Given a class of data that it is unlawful to possess (e.g. child pornography
in the US, government secrets almost anywhere), escrowed encryption keys can
be forced out of escrow by simultaneously transmitting such data to a site
(e.g. via e-mail or anonymous FTP), and asserting to the appropriate
authorities that there is probable cause to believe that such data is present
at the site.

Even if evidence obtained in this way cannot be used in court, it still puts
the victim through the (perhaps considerable) expense of replacing the
compromised key (which may be embedded in hardware) and of tracking down
anything else that may have been affected, as well as opening the door to a
generalized fishing expedition that may well turn up something that *can* be
used.

A user at the site can easily be tricked into requesting the data, for example
by means of a URL that simultaneously transmits the data to the user, and
notifies the appropriate authorities.  This attack can easily be used against
a selected set of users, e.g. those on a mailing list or subscribers to a
Usenet news group.

Steve Savitzky   \ http://www.crc.ricoh.com/people/steve/steve.html
[e-mail] \ Cyberspace: an alternate universe where magic works.

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

Date: 15 Aug 94 23:05:00 EDT
From: Mike Sullivan <[e-mail]>
Subject: The Danger of Six-Digit Dates

I came upon this excellent warning about the dangers of six-digit dates
(with the year represented by two decimal digits) recently on USENET and
have reproduced it here for the readers of RISKS digest with permission:

>From: Problem Reporting Service <[e-mail]>
>Newsgroups: tdr.problems
>Subject: 0026 - Exactly.  What do we do? (Six Digit Dates)
>Date: Fri, 11 Aug 1994 23:00:58 -0500 (EST)
>Organization: Tansin A. Darcos & Company, Silver Spring MD
>Lines: 179
>Approved: [e-mail]
>Message-ID: <[e-mail]>
>NNTP-Posting-Host: access3.digex.net

Please excuse the long delay between the prior posting and this one, I
have been busy with a number of very critical issues.

I've been trying to think of a way to solve the problem.  I - and
probably many of you - have been trying to figure out what to do about it.

At the end of "The Andromeda Strain" the Senator asks Dr. Stone what they
can do if another biological emergency occurs.  "What do we do then?" he
asks.  "Exactly, " responds Dr. Stone, "What do we do?"

The problem is the issue of six-digit dates and the turn of the century,
now less than six years away.

The problem is probably not as bad as it was, because with the introduction of
IBM PCs which support dates past the year 2100, the issue isn't a problem
except to the extent of programs that still use six-digit dates.

Some of you might not understand why this is a serious issue.  I'll explain.

Much software which is still in use - especially on mainframes - was written
ten, fifteen, even twenty years ago for use in the solving of current problems
at that time.

Some of that software survives, even twenty years later.  As I once pointed
out in a posting on the newsgroup alt.cobol, a large company might have a
massive 2,000,000 line cobol program with 500 modules that requires 50
programmers for its constant maintenance, care and feeding, and that over the
years the company has probably spent in excess of fifteen million dollars.

These applications are the "bet the company" applications that are
used every day to keep it in business.  They are the "crown jewels" that
if anything goes wrong with the application, the company might actually go
into Chapter 11 or suffer massive customer backlash.

These applications cannot be rewritten because it would be too expensive,
and the company can't afford to be without them.  Thus, unless something
happens to encourage the company to change its systems, they will continue
running these old, maintenance-heavy applications.

In some cases, the program is so huge and so complicated nobody knows
everything it does; it is beyond the capacity of any one person to know
every function and interface and module.

Therefore it can't be said with certainty what the different sections are
doing with each other.  Thus finding where things are happening can be
frustratingly difficult.

Which comes to the issue at hand.  Many of these programs were written to
use dates which are six digits in length.  Three days from now it will be
August 14, 1994.  You can write that as 08/14/94 or 14/8/94 depending on
which way your system codes dates.

Figuring out the difference between 8/14/94 and 8/15/94 is no problem, and
figuring out that 8/13/95 is after 8/14/94 is also no problem.

The last date of this century is Friday, December 31, 1999.  12-31-99.
Want to tell me what the next date after that is?  Saturday, January 1, 2000.
01-01-00.

Which date is earlier, 01/01/99 or 01/03/00?  What is the difference
between 12/15/99 and 12/31/99?  About two weeks.  What is the difference
between 12/15/99 and 01/03/00? About 99 years.

Hypothetical Example #1. I use my Visa Card to charge $15.00 on December
15, 1999, and the bill is calculated on Monday, January 3, 2000.

99 years of 21% compounded interest on $15 can be over a billion dollars.
Depending on where the minus sign is, either the company is going to
think I haven't paid them for 99 years, and freeze my account, send me a
bill for $1 billion in interest, or roll over into positive numbers, and
tell me my account has $1 billion in available credit.

Or it simply dumps every account with outstanding balances for manual
handling as the numbers are outrageous, which effectively stops automatic
billing.  Or the system simply crashes.

Scenario #2.  A major petrochemical processing plant has a system that
cooks a batch of chemicals for a certain period of time, before pushing
that load out to the next process.  The plant runs continuously, and
batches are cooked according to time.

A plant computer shoves a load in to cook for one hour beginning at 11:45
pm on December 31, 1999.  At Midnight, one of these things happens:
(1) the system notices that the batch has been in the oven too long, and
pushes a batch of molten chemicals into the next process, where the
process of spraying them causes an explosion.
(2) the clock counter overflows and shuts down the whole system.
(3) the system counter overflows and the batch isn't released, so it
overcooks in the oven and perhaps explodes under high heat.
(4) the batch stays in the oven while a new batch is shoved in,
overloading the oven and causing an explosion.
(5) any of these explosions carries back through the utilities and
supplies, causing gas line explosions or power surges, as a plant that is
eating perhaps 2 megawatts of power suddenly drops off the grid, causing
an instant overflow and shutting down power for several areas.

Scenario #3.  Several power plants go into maintenance shutdown because
they've been running continuously for 98 years and 7 months longer than
the maximum 90 day operating maximum.  Some Nuclear Power plant goes
critical or shuts down because the system believes that the rods have
been installed too long.

So having looked at this issue, what can we do about it?

I got thinking about this.  In some systems, there's little or no room to
expand their data files and the ability to remove running applications is
impossible.  Therefore any method that changes the system must allow
their applications to continue running.

And I thought of a method.

By coding the date into a character field, effectively in base 32, it
would be possible to encode a larger date and still only use 6 characters.
By encoding the year to use the letters of the alphabet, e.g. AA through
ZZ plus A0 through Z0, it is possible to cover more than 900 years, e.g.
start counting with 1400 through 2300, thus covering any date that could
have occurred during civilization.

In fact, if one wants to encode the month and day - Month encoded to add
A,B and C and day encoded as 0-9 and A-U, it is possible to use 4 digits
for the year and still fit everything into 6 bytes.  Or use both and fit
everything into 4 bytes.

This would also then work for places using packed decimal for the
six-digit year and thus only allowing 4 bytes.

One of the things that is necessary is to make programs expecting numbers
fail so that they can be changed.  Programs that read these records will
have to expect both old and new format records, while programs that write
them should only output the new format.

The point is that with many sites having hundreds or even thousands of
programs, the effort could be equivalent to three full-time people over a
three year period at some sites.  (Some companies have thousands or tens of
thousands of programs in their libraries.)  This is extra and additional
maintenance on top of current maintenance.  Expensive overhead that will
get worse in the future as it needs to be more urgently done.

What is needed are automated searching and checking facilities to find
programs that manipulate dates and change those programs to handle a new
date format.

If we do not make the changes, we could be looking at failed programs,
massive errors, disasters and setbacks that could produce serious,
perhaps even fatal problems.  It can't be done in a hurry in the last 6
months of 1999.

Let us not forget the amount of time needed to do updates, which could be
days or weeks, depending on how good the automated tools are and how many
applications they have.

What do we need to do?

(1).  If your site has in-house applications, and lots of source files,
      you need to push for the acquisition of automated checking tools.
(2).  You need to push for the manpower and resources necessary to do the
      work now rather than later, because "later" won't be budgeted for.
(3).  You need to push for the updating of databases to allow full
      8-digit dates.
(4).  Push for all reports to eliminate use of 6-digit dates, even in
      display fields.
(5).  Find out what your vendor is doing if you use canned applications.

If we work on the problem now while there is time, we can do this with
less error and better control, then trying to rush fixes in November of
1999 when errors could spell disaster.

If you have better ideas on how to solve the six-digit problem, please
write back.

----
To Reply to this message, write to <[e-mail]>; for private replies or
subscriptions use <[e-mail]>; or use newsgroup <tdr.problems>.
Please feel free to redistribute this article widely.

This message is file ftp.digex.net:/pub/access/tdarcos/0026

  [This message was also forwarded by Monty Solomon <[e-mail]>.
  By the way, I also am a subscriber to PROBLEMS.
  Note that this topic has been the source of many discussions in RISKS,
  an Inside Risks column (January 1991), and a more recent summary of the
  most interesting RISKS cases that will appear in the RISKS book,
  Computer-Related Risks, scheduled for publication in about five weeks.
  Also, see the following item, which is "old" news to gray-RISKers. PGN]

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

Date: Wed, 10 Aug 94 21:21:35 +0200
From: [e-mail] (Bruce Scott TK)
Subject: A Minor Risk for Centenarians

The following was reported in the News of the Last Page section of the
German News regularly posted by [e-mail]:

    Babies and young children need their check-ups. One Erna Schnoor
    also received an invitation to the "U6" for her first birthday:
    "Dear Erna, now you are already suuuuch a big girl..." was how
    the letter from the insurance company AOK Marne of Schleswig
    Holstein began. Unfortunately, the computer only saves the last
    two digits of each person's birthday. Erna Schnoor, at 101 the
    oldest city's oldest inhabitant, took it in good humor.

The poster adds that he is looking forward to the turn of the Millenium...

Dr Bruce Scott  Max-Planck-Institut fuer Plasmaphysik  [e-mail]

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

Date: Wed, 10 Aug 94 10:38:54 EDT
From: [e-mail] (Andrew David Tinkham)
Subject: IRC bug

A friend told me I should mention this bug here, so here goes....

In some ircII (Internet Relay Chat) clients (v2.2.9, I believe but possibly
other versions as well), there is a bug called the GROK or JUKE bug which
allows other people to take over your client.  Irc clients have functions
built in by default that allow access to an account, most notably the ability
to run shell commands and such, and as long as the only person accessing the
client is the one whose account it is, these commands have their uses.  When
someone with malicious intent gets control of a client, they can cause major
troubles such as deleting the entire account or compromising system security.

This bug seems to have been in copies of the code that was available last
spring.  Personally, I got a client compiled through the auto-compiler at
sci.dixie.edu sometime last April or early May, I believe, and that client had
the bug.  I believe that since then however, they have fixed their code as
have the people at cs.bu.edu and the bug no longer appears.

To determine if the bug is present in your client, login to irc and then type:

/ctcp <nickname of person running client you want to check> clientinfo

This will return a string of words.  If the words "GROK" or "JUKE" appear in
the list anywhere, then that client has the bug in it.  I do not know how the
bug itself works, because the way I found out about it was by having someone
pointing out I had it and then doing a few non-malicious demonstrations (I
checked my account thoroughly afterwards, and found no evidence of tampering),
but the demonstrations I saw lead me to believe that the entire range of
client commands available to someone using a client legitimately are available
to someone who takes over a client through the bug.  I only saw a couple of
commands demonstrated but to anyone with a little knowledge of the more
advanced irc features, many more possibilities are available than just making
the user logout of irc, or echoing to their client.

Apologies if this has already come up here, I searched the archives and didn't
find anything about it, but I am not a normal reader of this group and as I
said, I am posting this at the advice of a friend. Please send any followups
to me personally as well as to the list....

Andy Tinkham <[e-mail]><[e-mail]><[e-mail]>
Check out my WWW page at: http://caligari.dartmouth.edu/~tinkha/andy.html

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

Date: Wed, 10 Aug 1994 17:21:49 EST
From: Dave Banisar <[e-mail]>
Subject: Privacy Conference

ANNOUNCEMENT: TECHNOLOGIES OF SURVEILLANCE, TECHNOLOGIES OF PROTECTION
Sponsored by Privacy International, The University of Eindhoven, and
             The Electronic Privacy Information Center

                      Friday, September 9, 1994
   Nieuws Poort International Press Centre, The Hague, The Netherlands

The conference will bring together experts in law, privacy, human rights,
telecommunications and technology to discuss new technological developments
that affect personal privacy. The sessions will be interactive, starting with
introductions to the subjects by leading experts, followed by questions and
discussion led by the moderators.

8:45 Introduction
Simon Davies, Chairman, Privacy International

9:00 Information Infrastructures
Marc Rotenberg, Electronic Privacy Information Center (US), Stephanie
Perrin, Industry Canada

10:00  Euopean Government Information Sharing Networks
Jos Dumatier, professor of law and director of the Interdisciplinary
Centre for Law and Information Technology (ICRI) at K.U.Leuven

11:00 Cryptography Policy
David Banisar, Electronic Privacy Information Center, Jan Smiths,
University of Eindhoven

12:00 Lunch

1:00 Smart Cards and Anonymous Digital Transactions
David Chaum, Digicash

2:00 Wrap up

   [SPACE IS LIMITED.  For the application form or more information,
   contact David Banisar, 1+202-544-9240(voice), 1+202-547-5482(fax)
   [e-mail] (email) or
   Privacy International, Washington Office, Attn: Conference Registration
   666 Pennsylvania Ave, SE,  Suite 301, Washington, DC 20003]

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

Date: Mon, 15 Aug 94 15:24:43 -0700
From: [e-mail] (Debra Anderson)
Subject: Intrusion Detection Workshop announcement for interested people

I am writing to invite you to attend a one-day workshop on intrusion detection
to be held at the Baltimore Convention Center in Baltimore MD on
Thursday,October 13, 1994, in conjunction with the 17th National Computer
Security Conference.  Because of your interest in this field, your ideas and
experience will be valuable to the discussion.

The NCS Conference organizers have kindly provided us with a room at the
convention center.  We need know if you and/or your colleagues will attend by
returning the attached reply form.  For other questions, please call Liz
Luntzel at 415-859-3285 or send us a fax at 415-859-2844 or email at
[e-mail].

The workshop will consist of several short presentations as well as discussion
periods.  To help me in preparing the agenda, I would be interested in knowing
whether you have any progress to report on an intrusion-detection project or
some related work that would be appropriate for a brief presentation.  If so,
please indicate the title and a paragraph describing your proposed talk on the
attached form.  Please also indicate there your suggestions for discussion
topics.

Please respond to me, [e-mail]
  Debra Anderson, Room EL-223
  SRI International
  Computer Science Laboratory
  333 Ravenswood Avenue
  Menlo Park, California  94025

There will be no charge for the workshop, and meals will not be included.
There are numerous places in the surrounding Baltimore Harbor area for
breakfast and lunch.  The workshop will begin at 9am and will conclude at 4pm.

I look forward to seeing you at the workshop!

            Fourteenth Intrusion-Detection Workshop

Yes! I will attend the Intrusion-Detection Workshop October 13 at the
Baltimore Convention Center.

Please complete the following:

Name:
Title:
Affiliation:
Address:

Check one:
I am interested in presenting a talk.      [ ]
I am not interested in presenting a talk.  [ ]

Title of Talk:
Abstract:

Suggestions for Discussion Topics:

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

Date: 31 May 1994 (LAST-MODIFIED)
From: [e-mail]
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 <[e-mail]>
 (Dennis Rears <[e-mail]>).  UK subscribers please contact
 <[e-mail]>.  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
 <[e-mail]> (which is not automated).

 CONTRIBUTIONS: to [e-mail], 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: "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; [e-mail] 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 [phone], or fax [phone] 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
 [phone] if you cannot E-mail [e-mail] .

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

End of RISKS-FORUM Digest 16.32
************************