precedence: bulk
Subject: Risks Digest 19.88

RISKS-LIST: Risks-Forum Digest  Wednesday 22 July 1998  Volume 19 : Issue 88

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

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at http://catless.ncl.ac.uk/Risks/19.88.html

 Contents:
USS Yorktown dead in water after divide by zero (PGN, Michael D. Crawford)
More on Navy software problems (Robin Sheppard)
OS Design 101 (Lindsay F. Marshall)
Product safety recall (Leonard X. Finegold)
If you want medical privacy, get the Feds out of healthcare (Declan McCullagh)
Sloppy date handling in Perl scripts (Manu Iyengar)
Federal Court holds that source code is a functional device (Peter D. Junger)
Commerce Committee approves WIPO (Dan Lin)
Japanese snake vs. railroad electrical supply (Danny Burstein)
Another cable cut, near Jacksonville (Charles P. Schultz)
Auckland power supply failure report released (Tom Worthington)
Re: Y2K contingency plans needed (Rob Bailey)
Y2K dig-gerel (Brill Michael)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 21 Jul 1998 13:07:45 -0700
From: "Peter G. Neumann" <[email protected]>
Subject: USS Yorktown dead in water after divide by zero

The Navy's Smart Ship technology is being considered a success, because it
has resulted in reduced manpower, workloads, maintenance and costs for
sailors aboard the Aegis missile cruiser USS Yorktown.  However, in
September 1997, the Yorktown suffered a systems failure during maneuvers off
the coast of Cape Charles, VA., apparently as a result of the failure to
prevent a divide by zero in a Windows NT application.  The zero seems to
have been an erroneous data item that was manually entered.  Atlantic Fleet
officials said the ship was dead in the water for about 2 hours and 45
minutes.  A previous loss of propulsion occurred on 2 May 1997, also due to
software.  Other system collapses are also indicated.  [Source: Gregory
Slabodkin, Software glitches leave Navy Smart Ship dead in the water,
Government Computer News, 13 Jul 1998, PGN Stark Abstracting from
http://www.gcn.com/gcn/1998/July13/cov2.htm]

 [Thanks to over a dozen readers who commented on this item.  This makes
 me wonder: if I ran each snippet that was sent in, we could have stayed
 within the fair-use guidelines by publishing the entire article in
 twelve pieces, each with its own individual comments on the situation!
 For example, Lloyd Wood picked out this paragraph on which to comment:
 "The program administrators are trained to bypass a bad data field and
 change the value if such a problem occurs again, Atlantic Fleet officials
 said."  ``That's an interesting RISK-prone way of handling the problem,''
 said Lloyd.  PGN]

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

Date: Tue, 21 Jul 1998 14:52:55 -0800
From: [email protected] (Michael D. Crawford)
Subject: USS Yorktown dead in water after divide by zero

[...] The article describes how depending on Windows NT to automate many
ship functions caused serious trouble because of "system failures".

``Using Windows NT, which is known to have some failure modes, on a warship
is similar to hoping that luck will be in our favor,'' said Anthony
DiGiorgio, a civilian engineer with the Atlantic Fleet Technical Support
Center in Norfolk.

A sidebar in the article says that despite the setbacks, the Navy awarded
a large contract to Litton to do ship automation.

I'm not personally opposed to using computers in critical situations like
aboard a warship, but I would think you'd want a fault-tolerant OS and
applications, not a consumer product like Windows NT.

Mike Crawford [email protected] http://www.goingware.com/
Michael D. Crawford <[email protected]> http://www.scruznet.com/~crawford/

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

Date: Fri, 17 Jul 1998 17:08:55 -0700
From: Robin Sheppard <[email protected]>
Subject: More on Navy software problems (Rosenthal, RISKS-19.87)

Ideally, the next few generations of operating systems will end up being so
incompatible with legacy systems that no country anywhere will be able to
wage war.

At least we can hope so.

Robin Sheppard, MITS Helpdesk  [email protected]  888-543-9993  X7911

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

Date: Wed, 22 Jul 1998 15:50:03 +0100 (BST)
From: "Lindsay F. Marshall" <[email protected]>
Subject: OS Design 101

I give you the following excerpts from Microsoft's official developer
documentation on Windows CE (The Windows CE Programmer's Guide, in the MS
Developer's Library), in a section entitled: "Tips for Efficient Memory
Use."  I refrain from further comment.

"Whenever the system attempts to allocate more than 16 KB of
memory, it has the potential to fail without displaying the
System Out of Memory dialog box and without sending a
low memory warning to the user."

"Small memory allocations almost never fail.  Before this type
of allocation fails, the user has been sent both low-memory
and critical-memory warnings, in the form of System Out of
Memory dialog boxes, and has had an opportunity to respond."

"Include memory management capabilities in your application
to supplement those in the system."

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

Date: Wed, 22 Jul 1998 09:42:08 -0400
From: Dept of Public Safety at Drexel, via Leonard X. Finegold
Subject: Product safety recall

This message has been approved by Mr. Anthony T. Caneris, Senior Vice
President Student Life & Administrative Services, [email protected],
215-895-2800.

To:     Administration, Department Heads, Faculty, and Staff
From:   Armour Floyd, Director, Safety and Health Programs
Date:   July 16, 1998
Re:     Product Safety Recall

The Safety & Health Programs Department has been made aware of a product
safety recall by the Textronix Corporation.

Textronix has determined that certain incorrect use of their model TDS210
and TDS220 oscilloscopes may cause the ground connection to fail on these
products, potentially exposing the user to risk of serious personal injury
or death.  This recall applies to TDS210 and TDS220 products with serial
numbers below the following:

TDS210 - Serial Number below B049400 or C010880
TDS220 - Serial Number below B041060 or C011175

Textronix will modify your product(s) to remove this shock potential and
return it to you free of charge.

Even if your product appears to be functioning properly, you should not
assume that it does not have an open ground connection. Consequently,
immediately stop using the product. All returns will be at the expense of
Textronix.

If this particular product is in your possession, please contact Armour
Floyd, Safety and Health Programs Department at 895-2880 for further return
information.

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

Date: Tue, 21 Jul 1998 06:47:12 -0700 (PDT)
From: Declan McCullagh <[email protected]>
Subject: If you want medical privacy, get the Feds out of healthcare

http://cgi.pathfinder.com/netly/0,2326,201980721-14116,00.html

TIME.com / The Netly News, July 21, 1998

 Both Parties Weigh Medical ID Numbers
 By Declan McCullagh ([email protected])

 Spooked by the government's attempts to ban strong encryption
 products? If you thought that was troubling, wait'll you hear about
 the move towards mandatory medical ID numbers. A government panel met
 in Chicago on Monday to discuss a 1996 law that regulates the health
 insurance industry -- and in exchange requires that everyone receive a
 "unique health identifier."

 Liberal privacy advocates quickly condemned the move as a Big
 Brotherish intrusion into our personal lives. But conservatives and
 libertarians charge that liberal groups like the ACLU and the
 Electronic Privacy Information Center miss the point: if Feds regulate
 healthcare, invasive government databases are as inevitable as a
 sweaty Washington summer.  [...]

POLITECH -- the moderated mailing list of politics and technology
To subscribe: send a message to [email protected] with this text:
subscribe politech
More information is at http://www.well.com/~declan/politech/

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

Date: Mon, 20 Jul 98 13:16:19 -0700
From: Manu Iyengar <[email protected]>
Subject: Sloppy date handling in Perl scripts

InfoWorld's web site has a page for "Top News Stories" which is
programatically generated by a CGI script:

http://www.infoworld.com/cgi-bin/displayStory.pl?weekreview/weekinreview.htm

Visitors to the page today (July 20, 1998) see the page report the date as
Wednesday December 31, 1969! RISKS readers and other sharp folk will
immediately recognize this as the date of the epoch minus 1 second.
Conjecturing wildly, I suspect the problem is likely a sloppily written line
of code (the CGI program seems to be a Perl script) along the lines of:

       print "<FONT SIZE=4> ", localtime(time()), " </FONT><BR>\n";

Both localtime() & time() are Perl equivalents of the corresponding C
functions and use them internally. But what most Perl programmers probably do
not know is that time(3c) will return (( time_t )-1) if it fails for any
reason, so localtime(-1) will happily return a formatted date string for
"Wednesday December 31, 1969".

The risks? This particular idiom is extremely common in Perl scripts of all
sorts, since it's a convenient way of printing out a date or timestamp in
human readable format. RISKS readers are well aware of the dangers of not
explicitly checking return values, but many programmers may routinely take
shortcuts such as this. After all, who expects time(3c) to ever fail? In this
case, the result is harmless - visitors to the page get a good laugh. But
what if the same code was recording the timestamp to a database, or using it
for something important?

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

Date: Mon, 20 Jul 1998 18:18:25 -0300
From: "Peter D. Junger" <[email protected]>
Subject: Federal Court holds that source code is a functional device

Back in May 1993 I had an article in RISKS Volume 14, Issue 65 about ``The
risks of teaching about computers and the law'', relating how I wrote a
simple encryption program for use in my course in Computing and the Law and
discovered that I had to have a license from the government before I could
publish the program, or even discuss it in a class if any foreign students
were present.

Quite a bit has happened since then.

I filed a suit on 1 Oct 1996 challenging the constitutionality of the
International Traffic in Arms Regulations (the ``ITAR'') as they applied to
cryptographic software like my little demonstration program, as well as much
more functional programs like Phil Zimmermann's Pretty Good Privacy.  At
that point matters appeared to be moving right along.

But then the President transferred the authority to regulate encryption
technology to the Secretary of Commerce under the Export Administration
Regulations (and thus the ITAR was replaced by the EAR).  The new
regulations considerably relaxed the restrictions on cryptographic software
and it was, much to my relief, no longer necessary for me to get a license
from the government before discussing my program or PGP with a foreign
student.  And the publication of encryption software in a book or a journal
or in other ``hard copy'' form was no longer subject to the licensing
requirements.  But a license is still required under the EAR if one
publishes encryption software on the Internet or the World Wide Web or in
other ``electronic form''.  And by that time I had collected lots of
cryptographic software that I wanted to publish on my web and ftp servers,
and some of it was embedded in my casebook and in a couple of law review
articles that I am writing.

So it was back to the drawing board.  On 2 Sep 1997, we filed a new
complaint naming Secretary of Commerce Daley as the defendant, and both
sides moved for summary judgment.  The complaint, answer, briefs, and other
documents relating to the case are available on my web site at
<http://samsara.law.cwru.edu/comp_law/jvd/>.

Our position was quite simple and is summarized in our final brief: ``Making
software available on the Internet and the World Wide Web is publication of
that software, and publication in that medium is entitled to the unqualified
protection of the First Amendment.''

The government's position was not so clear; in fact, I find it rather
incoherent.  It seems to argue that the publication of software amounts to
using that software, and that Congress could restrict its use to prevent
fraud and other criminal acts, ignoring the reality that Congress has never
passed any law that forbids the use of encryption software.

But don't take my word for that.  Here is what the government argued in its
final brief:

 The linchpin of plaintiff's First Amendment argument is that
 ``software is speech'' This notion is not only irrelevant to
 deciding the case, but has unknown and potentially harmful
 implications. If it were necessary to decide the matter, the more
 prudent judicial finding would be that encryption software,
 whatever its informational value, is properly treated as a
 functional item. The common sense understanding of software -- as
 recognized by courts -- is as a set of instructions to a computer
 microprocessor that enables a computer to function a certain
 way. . . . The common use of software is to perform tasks on a
 computer, ranging from word-processing, electronic mail, exploring
 the Internet, playing games, or encrypting data.

 Much software, however, is designed to cause substantial
 harm. Software exists to spread and install ``viruses'' that can
 destroy computer hard-drives or the files they contain. Software
 also exists to ``hack'' into secure computer systems, such as
 banking and telephone systems. Such software can be used to invade
 privacy, commit fraud, and substantially disrupt or even endanger
 people's lives -- not because it contains a harmful ``idea'' but
 because it can do harmful things.  Those who transmit such
 software cannot validly claim they were merely distributing an
 ``idea'' or ``speech'' when that ``speech'' destroyed a computer
 hard-drive, shut down a phone system, or hacked into a bank
 account.

 In the case of powerful encryption, there are valid uses of
 hardware and software in securing communications, including to
 prevent the harms described above. But encryption can also secure
 the communications of criminals, terrorists, and other hostile
 entities overseas, which gives rise to the government's concern
 over its uncontrolled export. When all the consequences are
 considered, the conclusion that ``software is speech,'' because
 some people understand the intricacies of how it works, is
 simplistic and should be avoided, particularly in judicial precedent.

Finally, on July 3, 1998, Federal District Court Judge Gwin of the Northern
District of Ohio ruled in favor of the government, concluding that software
is not constitutionally protected speech because it is ``inherently
functional'', saying: ``while a recipe provides instructions to a cook,
source code is a device, like embedded circuitry in a telephone, that
actually does the function''.

Now some of the risks of having a legal system that simply miscomprehends
the very nature of software---and that is what the government's argument and
Judge Gwin's decision strongly suggest to me---should be all too apparent to
the readers of this digest.  I suspect, however, that there are many unknown
risks lurking here as well.  What, for example, is the implication of Judge
Gwin's decision that source code is a device for copyrights on software?

I have created a new electronic discussion list and web site called
SoftSpeech, which I hope will be a forum in which programmers and computer
scientists, on the one hand, and lawyers and legal scholars, on the other,
can discuss the issues raised by Judge Gwin's decision, including whether
software is constitutionally protected speech or a functional device.

For further information about the SoftSpeech discussion list and Judge
Gwin's decision, see <http://samsara.law.cwru.edu/~sftspch/>.

Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH
[email protected]  http://samsara.law.cwru.edu

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

Date: Mon, 20 Jul 1998 17:37:05 -0500
From: Dan Lin <[email protected]>
Subject: Commerce Committee approves WIPO

Here is a quick update on the House Commerce Committee consideration of the
Digital Millennium Copyright Act (WIPO)

HOUSE COMMERCE COMMITTEE APPROVES H.R. 2281, DIGITAL MILLENNIUM COPYRIGHT ACT

H.R. 2281, known as the Digital Millennium Act, was approved by the House
Commerce Committee on July 17 by a 41-0 unanimous vote. A total of eight
amendments were considered during the mark-up. Six were adopted and two were
withdrawn. There now currently exist two versions of H.R. 2281 - the
Commerce version and the Judiciary version. The two versions are quite
different and must ultimately by reconciled. The Commerce version is an
amended version of the Senate bill, known as the Digital Millennium Act, and
the Judiciary version uses language from the original House bill, known as
the WIPO Copyright Treaties Implementation Act.

USACM had sent a letter to the House Commerce Subcommittee on
Telecommunications, Trade and Consumer Protection on June 4, 1998 that
expressed concerns about language in the bill which could prohibit
legitimate efforts in encryption research and computer security. The
amendments adopted by the Committee address several of the concerns raised
by USACM.

1. ENCRYPTION RESEARCH - ADOPTED
  An amendment was adopted which allows a person to circumvent a
  technology protection measure "in the course of an act of good faith
  encryption research." Good faith in this case means that the person
  lawfully obtained the encrypted work, the act of circumvention is
  necessary to conduct the research, and the person made a good faith
  effort to obtain authorization before the circumvention.
  Additionally, the amendment directs the Assistant Secretary of
  Commerce for Communications and Information to report to Congress
  on the effects of the legislation on encryption research no later
  than one year after the enactment of the act.

2. PERSONAL PRIVACY - ADOPTED
  The adopted privacy amendment permits a person to circumvent a
  technological protection measure which collects or disseminates
  personally identifying information provided that the act of
  circumvention has "no other effect on the ability of any person to
  gain access to any work."

3. DEFINITION OF "TECHNOLOGICAL PROTECTION MEASURE" - WITHDRAWN
  An amendment defining a "technological protection measure" was
  vigorously debated, but ultimately withdrawn. Supporters of the
  amendment argued that it was necessary to preserve the
  constitutionality of the bill. Without a clear definition of a
  technological protection measure, courts would be quick to throw
  out cases involving the law due to the vague term. While opponents
  of the amendment conceded that a precise definition was necessary,
  they argued that the amendment as drafted provided a poor
  definition. Ultimately, the amendment was withdrawn with the
  provision that members would work together to perfect the
  definition in the legislative history.

4. REVERSE ENGINEERING - ADOPTED
  Unamended, the bill would allow reverse engineering only for the
  purposes of interoperability. An amendment was adopted that
  included the consideration of the extent to which claims were
  brought against persons who used reverse engineering in research in
  an annual report by the Secretary of Commerce. The report would
  include an assessment of the level of impediment such claims would
  have on the development of goods and services. Even with this
  amendment, however, the bill still prohibits reverse engineering
  for uses other than interoperability.

5. FAIR USE - ADOPTED
  For the past month, the Commerce Committee had struggled with the
  concern of fair use. While libraries feared that the bill would
  prohibit fair use rights essential to library lending, publishers
  feared that any legal circumvention techniques would lead to
  uncontrollable piracy. Early Friday morning, both sides apparently
  struck a compromise deal. The adopted compromise amendment delayed
  the prohibition of circumvention for two years, directing the
  Secretary of Commerce to "conduct a rulemaking on the record to
  determine whether users of copyrighted works have been... adversely
  affected by the implementation of technological protection
  measures..." Every two years thereafter, the Secretary could waive
  the prohibition for particular "classes" of copyrighted works which
  were adversely affected by the legislation.

The Commerce Committee is currently drafting the legislative history for the
bill. Next there will be an informal conference between the House Judiciary
Committee and the House Commerce Committee to reconcile the two different
versions of the bill.  In general, the Commerce Committee version is more in
line with the positions of the USACM, though it still contains provisions
that may be problematic for computer research.

Please let me know if I can provide any more information.

Daniel Lin, ACM U.S. Public Policy Office, 666 Pennsylvania Avenue SE,
Suite 302B, Washington, D.C. 20003  1-202-544-4859  [email protected]

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

Date: Mon, 20 Jul 1998 08:38:08 -0400 (EDT)
From: danny burstein <[email protected]>
Subject: Japanese snake vs. railroad electrical supply

In the continuing tradition of animals versus electrical power grids, I
submit this snippet from a news story of a Japanese snake, genus unknown,
who gave its life making commuters late:

Electrocuted snake causes train havoc in northern Japan
Associated Press, 20 Jul 1998

Officials canceled 34 train runs after a snake crawled up an electricity
pole and touched a high-voltage overhead rail wire.  Railway workers later
removed the charred remains of the electrocuted snake, which was 3 feet, 4
inches long.  The snake's type was not immediately known.

 [The lack of strong typing was not on the scales.  PGN]

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

Date: Wed, 22 Jul 1998 17:08:29 -0500
From: CharlesP Schultz-ECS013 <[email protected]>
Subject: Another cable cut, near Jacksonville

Where have we heard this before?

The July 16th edition of the Miami Herald newspaper carried a story with the
headline "Severed cable shuts down superhighway." It seems that a telephone
work crew north of Jacksonville accidentally cut a cable owned by WorldCom
that carries telephone and Internet traffic from Florida to the northeast
(recurring theme #1). This cable handles Internet traffic for WorldCom's
UUnet, which acts as part of the Internet backbone, carrying traffic between
thousands of customers. There was no specific count on the number of people
affected, but the paper reported "it was a significant number."

One thing that is interesting to me is how differently various South Florida
service providers were affected.

America Online, which uses WorldCom and other backbone providers said it
experienced temporary slowdowns. [ How could anyone tell???  ;-) ]

CyberGate, a Broward County-based ISP with 47,000 subscribers, said
customers were unaffected since they don't use UUnet and have multiple
connections to avoid this kind of problem.

The worst hit seems to have been Icanect, a Miami-Dade county provider for
20,000 people, who was almost totally shut down. The reason for this is that
their backup provider, Cable & Wireless, experienced technical problems on
the very same day. Bob Hurwitz, president of Icanect, was expecting it to
take at least 24 hours to clear up his problem, and he was quoted in the
paper as saying "To have both your primary and your backup both go down,
that's not supposed to happen." (recurring theme #2).

Fortunately, this was only a non-fatal reminder that these kinds of things
still happen and need to be accounted for.

Charles P. Schultz <[email protected]>

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

Date: Tue, 21 Jul 1998 21:54:42 +1000 (EST)
From: Tom Worthington <[email protected]>
Subject: Auckland power supply failure report released

"After a series of four power cable failures, on 20 February 1998 Mercury
Energy Limited, the major distributor and retailer of electrical power to
the city of Auckland, announced that it could no longer supply power to the
central business district. Emergency services were notified and mobilised..."

Quote from the report of the Ministerial Inquiry into the Auckland power
supply failure, issued today.  Now available:

* Executive summary:
http://www.executive.govt.nz/minister/bradford/power/summary.htm
* Media Release from the Minister of Energy:
http://www.executive.govt.nz/minister/bradford/power/release.htm
* Inquiry Home Page: http://www.moc.govt.nz/inquiry/

ps: The lights are on, here in Auckland, now. See: http://www.webcam.co.nz/

Tom Worthington, Immediate Past President, Australian Computer Society
http://www.acslink.net.au/~tomw POB 13 Belconnen ACT 2617 [email protected]

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

Date: Tue, 14 Jul 1998 18:35:05 -0400
From: Rob Bailey <[email protected]>
Subject: Re: Y2K contingency plans needed (Frankston, RISKS-19.85)

That's what I thought, too. The point was raised over on the Emergency
Management Net distribution list that lots of talk about identifying and
fixing the problem had taken place, but that the emergency management
community as a whole had been pretty much ignoring the problem of response
and damage mitigation to a problem that is 18 months off (and, unlike all
other disasters, can be timed quite accurately on any calendar).

In response, <[email protected]> wrote that "[t]he Y2K bug seems to mostly
lurk in old COBOL code." So I decided to offer a couple of examples that had
been brought up here in Risks and some pointers in the Web to embedded
systems that might / will fail on Y-day. I was pounded with criticism. The
most poignant attack came from <[email protected]>, who opined that I
was promulgating unfounded "Fear, Uncertainty and Doubt". Steve went on to
add that "[a]ll in all, [he's] not really that concerned about Y2K."

With that attitude, it's no wonder that little if anything has been planned
by the emergency management community in response to the 01-01-01. For
example, FEMA has implied that few or no Y2K-*specific* preparations have
been made; instead, FEMA will rely on the national response plan to deal
with the (alleged) emergency like any other emergency. I hope it works;
unlike others, all in all, I *am* really concerned about Y2K.

Rob Bailey, [email protected]  WVIT School of Engineering, Class of 1986
W&L School of Law, Class of 2000 [Assuming their computers let you out.  PGN]

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

Date: Tue, 21 Jul 1998 10:56:19 -0400
From: "MICHAEL BRILL" <[email protected]>
Subject: Y2K dig-gerel

Millennium Panic
Michael H. Brill, 5 June 1998

The Bug hangs off in distant skies
And stares with double-O for eyes,
Between my digits now.  But soon,
It hides itself behind the moon.
Emerging on the other side--
New-grown, and much too large to hide--
It grows again.  I see it nears,
Igniting all my primal fears.
(But no-one else sees this display;
They're deep into their business day.)

With jaws agape and wings unfurled,
This Bug's about to eat the world!
Now sages see the ghastly form,
And mumble that it's just the norm:
"The 'Bug' is just a trick of lights,
A cloud of dust, or must--or mites."

As evening comes, arachnid pall,
It scarcely dims the sun at all.
Though jaws envelop all the sky,
I see through them the planets fly.
Orion studs the frigid night.
I feel no heat; I find no light.
Our world, the lifeblood that we've prized
With digitalis paralyzed.
The ichor from the jaws has spread
In smaller things beside my bed.
Outside, crowds mad with fear and pain,
For lack of power their kin have slain.
As gun-filled hands my door break through,
The sages' echoes all ring true.

"They're right," I sigh with my last breath.
"A cloud of 'mights' has brought my death."

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

Date: 31 Mar 1998 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
.MIL users should contact <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

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

End of RISKS-FORUM Digest 19.88
************************

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.