precedence: bulk
Subject: RISKS DIGEST 19.38

RISKS-LIST: Risks-Forum Digest  Weds 17 September 1997  Volume 19 : Issue 38

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

 Contents:
Walking Away From the Medicare Computer Project (Edupage)
Dyslexic Telephone Switch causes billing errors (Robert J. Perillo)
Barranquilla airport smells a rat (Mich Kabay)
GCCS Military Software fails Year 2000 Test (Paul Robinson)
Leaked memo on Mondex hacks embarasses bank (Paul Gillingwater)
Illinois being sued to keep information public (Anthony Stuckey)
Hewlett-Packard glitch spews spam (Gary Grossoehme)
New --faster-- Macs broke old code (John Paulson)
Personal info gone astray (Ken Knowlton)
GM car acceleration due to EMI (Don Rosenberg)
Re: SOHO gives 1 hour advance warning to Solar storms (Bob Schuchman)
Re: KAL801 and GPWS (Peter B. Ladkin)
Re: FBI wants to ban the Bible ... (Merlyn Kline, Dick Mills, Matt Millar,
   Martin Gleeson)
Re: @LARGE -- Spaf quote (Len Spyker)
Java Date Problems (Howard Melman)
Risks of bad assumptions: octal numbers (Matt Toschlog)
Long is 4 bytes? Not any more... (Peter da Silva)
Re: Y2K and C (Steve Sapovits)
1998 IEEE Symposium on Security and Privacy (Mike Reiter)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 16 Sep 1997 12:32:11 -0400
From: Edupage Editors <[email protected]>
Subject: Walking Away From the Medicare Computer Project (Edupage)

The Clinton Administration has terminated the contract with GTE for a new
computer system to handle Medicare because the current system (run by 72
private insurance companies around the country) proved to be so antiquated
and complicated that they frustrated GTE's efforts.  The Department of
Health & Human Services has told GTE to "stop all work, make no further
shipments, place no further orders and terminate all subcontracts."
Medicare officials say they will now work on individual pieces of the system
rather than attempting to do the entire project at once.  (*The New York
Times*, 16 Sep 1997; 16 September 1997)

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

Date:  Tue, 16 Sep 97 18:14 EDT
From: [email protected]
Subject:  Dyslexic Telephone Switch causes billing errors

Northern Telecom Ltd. stated last week that its widely used DMS-100
telephone switch caused numerous billing errors in many phone company
central offices due to a software bug introduced during a software upgrade
this summer. The software glitch caused the billing interface to become
dyslexic and use the wrong area code in phone company Central Offices
covering more than one area code.  The software snafu was fixed after about
a month of erroneous billings.

Net Users calling their "fixed price" local access number found hundreds of
dollars of overcharges on their telephone bills this summer. The local
number was billed as a toll call with a different area code attached. To add
to the confusion, customers were told by their local telephone company that
the billing problem was with their long distance company or the Internet
Service Provider (ISP). And these companies directed customers back to the
local telephone company. Customers were refused an explanation but were
finally told that it was a "System Error".

Pacific Bell acknowledged that 167,000 Californians, mainly in the Bay
Area's 415 and 510 area codes and 805 near Los Angeles, were billed $667,000
in unwarranted local calls. The problem was also reported by Nynex customers
(now Bell Atlantic) in the New York City area.

I do not understand why [more extensive] testing and some sort of
independent review was not done by NorTel before they released the software
upgrade? The local telephone companies should also have some sort of Quality
Assurance program in place before they allow a contractor to upgrade
software in their Central Offices?

I also do not understand why the local telephone companies did not handle
the problem better in terms of customer service, and inform all possible
affected customer's of the problem?

[References: Inter@ctive Week, "Net Users Overcharged in Glitch",
            by Louis Trager, 08-Sep-1997.

            Forbes Magazine, "Midsummer madness, New technology
            is marvelous, except when it isn't. System Errors",
            by Dan Seligman, 08-Sep-1997, page 234. ]

Robert J. Perillo, CCP, Richmond, VA  [email protected] [disclaimers]

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

Date: Fri, 12 Sep 1997 22:25:08 -0400
From: "Mich Kabay [NCSA]" <[email protected]>
Subject: Barranquilla airport smells a rat

A rat caused a short circuit on 12 Sep 1997 by urinating on a high-power
cable at Barranquilla airport in Colombia.  This knocked out communications
between the control tower and incoming aircraft, and caused the airport to
shut down for almost an hour.  [Reuters, 5 Sep 1997]

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

Date: Mon, 15 Sep 1997 17:15:24 -0700
From: Paul Robinson <[email protected]>
Subject: GCCS Military Software fails Year 2000 Test

In an article on the front page of the 15 September 1997 {Government
Computer News}, it is noted that the Defense Department's Global Command and
Control System (GCCS) failed when the date was rolled over to the year 2000.

GCCS is used at 500 Department of Defense sites worldwide to provide a
comprehensive battlefield operational picture.  It replaced an older system
in August 1996.

The test was done on 1 Aug 1997 during the Joint Warrior Interoperability
Demonstration (JWID), which is used to show off emerging technologies for
use in Command, Control, Communications, Computers and Intelligence (C4I)
operations.  Eight countries, including Canada (which has purchased GCCS for
evaluation purposes), are participants in JWID.

There are 28 tests used, including setting the date and time close to
midnight on 31 Dec 1999 and letting the clock roll over, as well as for 28
Feb 2000 and 2001.  In 10 of the 28 demonstrations, software expired or
machines froze.  One system failed to recognize that there is a 29 Feb 2000.
Another had to be rebooted and had erased every user account.

The failure is believed to be due to the underlying operating system. GCCS,
current version 2.2, runs on Solaris 2.5.1, Windows NT, and HP-UX 9.0.7 and
9.0.10.  It is said that systems running on Solaris 2.3, 2.4 and 2.5 are not
year-2000 compliant.  The Hewlett-Packard Unix systems are said to be
compliant and passed the test.  According to Lt. Cmdr. Mark Harvey,
technical director at the Defense Information Systems Agency (DISA) for the
JWID program, "So anything that was running on HP Unix worked.  Anything
that had Solaris did not."  JWID rejected claims that their software was at
fault, stating that the problem is claimed to be on Solaris versions 2.5 and
below.

Sun questions whether the application is at fault.  John Leahy, government
markets manager for Sun Microsystems Federal pointed out that "Even if the
operating system is year 2000 compliant, that doesn't automatically mean the
applications that run on it are."  He also said the problem is surmountable
if the latest release - Solaris 2.6, which has year 2000 support - is used.

But DISA plans to use Solaris 2.5 for GCCS Version 3.0 to be released in
January 1998.

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

Date: Mon, 15 Sep 1997 10:34:09 +0200
From: [email protected]
Subject: Leaked memo on Mondex hacks embarasses bank

The following URL purports to contain an interesting leaked report on the
security of the Mondex model for electronic money, as analysed during the
due diligence process by a bank.

http://jya.com/mondex-hack.htm

The Risks:

1) Is an internal memorandum really covered by Copyright, since it is not
"published"?

2) Presumably, banks operate under an agreement with Mondex whereby they are
obliged to not disclose any security weaknesses they find in such security
products as Mondex.  Clearly, banks are not acting in the best interests of
their customers.  The risk is that keeping such holes secret doesn't improve
security.

3) Attempts to suppress information, such as threatening EFF Canada with
legal action, tend to have the opposite effect.

Paul Gillingwater <[email protected]>  Internet Systems Administrator
International Atomic Energy Agency    (http://www.iaea.org)

 [TNO's Ernst Bovenlander gave some details of these attacks at
 Eurocrypt 1997.  A link exists during testing that permits the contents of
 memory to be output on the serial port.  The link is then severed before
 release of the smartcard.  The attack involves fusing the link together
 again.  [[This is an offer you can re-fuse!]]  At RSA 1997, Tom Rowley
 of National Semiconductor reported a similar attack using an ion beam
 to rewrite the link.

 Incidentally, on Paul's third point, security-by-obscurity is not very
 obscure once it has been widely promulgated.  PGN]

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

Date: Wed, 10 Sep 1997 12:40:41 -0500 (CDT)
From: [email protected] (Anthony Stuckey)
Subject: Illinois being sued to keep information public

I found out about this through an Associated Press article in the
Champaign-Urbana News-Gazette.  (http://www.news-gazette.com)
 http://www.sos.state.il.us/special/optout/optform.html

People keep mentioning the relationship between government-collected data
and privacy invasion.  Here it seems that we have an official trying to
protect privacy who may not be legally able to.

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

Date: Tue, 16 Sep 1997 15:52:19 -0400 (EDT)
From: [email protected] (Gary Grossoehme)
Subject: Hewlett-Packard glitch spews spam

By Alex Lash, 15 September 1997 [Source not specified.]  Excerpted.

> Some Web surfers who requested more information about a Hewlett-Packard
> (HWP) scanner got a bit more information than they needed--thousands of
> e-mails more.  Because of an error in a mailing list for information on
> HP's ScanJet 5, subscribers to the list received e-mail every time someone
> sent a message back to HP. The e-mail then snowballed as angry recipients
> flamed the company asking to be taken off the list.

[Everybody was getting everybody else's 'unsubscribe' message, an experience
that must be common to all of you who subscribe to UNMODERATED groups.  PGN]

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

Date: Wed, 10 Sep 1997 18:09:02 -0700
From: john paulson <[email protected]>
Subject: New --faster-- Macs broke old code

>The symptom is:
>*      I launch Frontier.
>*      The splash screen appears, then closes.
>*      Frontier hangs.
>
>According to Dave Winer, Doug Baron has found the bug and a fix is
>forthcoming! I'll be updating this page as soon as I know more.
>From Doug:
>I see what's going on. It's a bug directly tied to processor
>performance; there's never been a processor fast enough to cause this
>integer overflow before.
>
>What were we doing? When opening windows, we wanted a
>processor-independent way to pace the zooming effect, one that could
>time in fractional ticks. So we execute a simple loop, calling
>GetTickCount, and determine a loops-per-tick factor. When zooming, we d
>elay some number of loops between each drawing operation, enough to
>consume 1/6 of a tick.
>
>Unfortunately, the loop counter was a short -- ooops! The new Macs can
>loop, calling GetTickCount, more than 32767 times per 1/6 of a tick,
>i,e. more than 32767*6*60 times per second. Not bad!
>
>We're working on a patched version.

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

Date: Mon, 15 Sep 1997 08:46:47 -0400 (EDT)
From: [email protected]
Subject: Personal info gone astray

At the Continental Airlines ticketing office some robot, mechanical or
human, has folded someone else's mailed confirmation into my own.  I am
given: the name and address of a woman in Texas who, barely a week ahead of
time, bought a single ticket for a flight to Oregon, the times and dates and
flight numbers, her ticketing confirmation number, and her Visa card number
except that the last four digits are X-ed out, for "security purposes."  How
often does this sort of thing happen?

Does anybody complain?  With such information as a springboard, what kinds
of mischief or crime might a troublemaker parlay it into?

Ken Knowlton

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

Date: Tue, 9 Sep 1997 08:46:03 -0400
From: Don Rosenberg <[email protected]>
Subject: GM car acceleration due to EMI

You might want to take a look at the *Wall Street Journal*, 8 Sep 1997, page
B10, in which one incident (among many) of sudden acceleration by a GM car
was demonstrated (proven in court, after seven years) to come from
electromagnetic interference.  GM had 1,761 sudden acceleration incidents
between 1973 and 1986, with 1,121 injuries, and 31 deaths.  There is a
possibility that the Audi 5000 incidents (300 accidents, with 175 injuries
and 4 deaths between 1978 and 1986) had a similar origin.

In the GM court case, the "expert witness showed that the Buick's cruise
control was sensitive enough to be set off by simply running a power drill
near the car."

Don Rosenberg, Stromian Technologies

 [According to Peter Ladkin, this appears to be a demonstrated case, but
 it's also in an environment in which the RFI shielding requirements are
 not as rigorous.  Cars do not have to be certificated the way aircraft do.
 Check out Peter Ladkin's item in RISKS-19.24 and his Web page, and also
 Helfrick's article and the bluecoat WWW page
   http://bluecoat.eurocontrol.fr
 Also, out of band, Ira Rimson provided a useful reference:
   Roy W. Krieger, "The Danger of Electromagnetic Interference with
   Aircraft Systems: laptop laibility?", 1994 Annual Seminar of the
   International Society of Air Safety Investigators (ISASI,
   5 Export Drive, Sterling, VA, 20164, e-mail:[email protected]).
     The paper deals with results of the RTCA Special Committee
     (SC)-156 and its limitations, as well as both scientific and
     anecdotal data subsequently developed.  Although the paper was
     delivered prior to publication of a subsequent RTCA SC-177 report (in
     1995), the paper contains excellent background material which could
     form the foundation for defining research needs.
   PGN

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

Date: Mon, 08 Sep 1997 17:19:40 -0500
From: Bob Schuchman <[email protected]>
Subject: Re: SOHO gives 1 hour advance warning to Solar storms (RISKS-19.37)

I just noticed the subject in the msg from John W. Cobb in 19.37.  It isn't
SOHO that is to provide the "warning" of solar storms.  It is the Advanced
Composition Explorer (ACE), which was launched on Aug. 25th.

There is a URL with more ACE information, including the "science Goals" of
ACE. It's at http://www.gsfc.nasa.gov/ace/ace.html.

Bob

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

Date: Mon, 08 Sep 1997 23:24:29 +0200
From: "Peter B. Ladkin" <[email protected]>
Subject: Re: KAL801 and GPWS (Kohl, RISKS-19.37)

John Kohl, in a response to my assertion that incorrect
barometric altimetry on approach has a `safe' direction, opines that

> Higher is safe in regards to ground terrain, but not necessarily safe
> regarding other aircraft

but forgets that on approach (the context in which my statement was made),
the airspace above the aircraft is kept free of other aircraft by ATC, as
they are required to do to allow for a missed approach procedure.

Secondly, I don't know any meaningful designation KAL (title).  The name of
the airline is Korean Air, and its designator is KE.  The flight was KE801.

Peter Ladkin

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

Date: Thu, 11 Sep 1997 11:38:09 +0100
From: Merlyn Kline <[email protected]>
Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37)

This is reminiscent of a time a few decades ago when certain popular records
could be played backwards to reveal hidden messages. At that time there was
a movement seeking to make it illegal to record things backwards. Of course
any sound is just another sound backwards and I have seen cabaret acts by
entertainers who have trained themselves to speak backwards. Such
legislation would be nonsense for exactly the same reasons as the proposed
legislation against use of codes would be.

Any of us who have served time at the customer interface (I have spent many
happy hours giving technical support:) will also know that even apparently
plain English can turn out to be an impenetrable code (e.g. 'There was no
error message displayed' could mean 'the screen turned blue and there was so
much text displayed that it is easier to deny it ever existed rather than
try to remember what any of it said').

The risk here is in the failure to distinguish between imprecision,
inaccuracy and generalisation. The legislators seek to prevent people from
doing something they don't like but experience tells them that if they
define that thing too precisely there will be an immediate loophole in the
legislation because people will be able to achieve the same ends by an
activity which is slightly outside the definition. The solution is to
generalise by identifying what it is they are really trying to
prevent. Instead they arbitrarily lower the degree of precision in their
definition, resulting in inaccuracy rather than generalisation. The result
is all too often a meaningless definition rather than an accurate
generalisation.

Eherway oday ouyay antway otay ogay odaytay?

Merlyn Kline = [email protected]

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

Date: Tue, 09 Sep 1997 18:23:45 -0400
From: Dick Mills <[email protected]>
Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37)

I can think of an even more literal interpretation.  Namely, that any device
that can be used to communicate in any medium can be used to encrypt, and
thus would be banned. I don't doubt that it is serious, but I am confused
over the literal interpretation of the words.  But in RISKS-19.36, John R.
Levine seemed to close a long standing debate over whether literal
interpretatation of law means that computers are fax machines and thus e-mail
must be faxes.

Which is it supposed to be?  Should citizens attempt to read and interpret
the literal text of written laws ourselves, or should we rely on lawyers to
tell us what the words really mean.

Perhaps we should we have a double standard.  Get excited over the exact
wording of proposed laws, but be passive about the exact wording of existing
laws.

Dick Mills            http://www.albany.net/~dmills

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

Date: Mon, 8 Sep 1997 18:16 +0100 (BST)
From: [email protected] (Matt Millar)
Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37)

Could this be extended to foreign languages?  Before I post a message in a
language other than english do I have to check that someone in the FBI can
speak that language?  Computer languages?  Anyone speak C++ here?

Matt

"... will inevitably lead to ..."
                      - anyone without a coherent argument.


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

Date: Tue, 9 Sep 1997 13:18:40 +1000
From: Martin Gleeson <[email protected]>
Subject: Re: FBI wants to ban the Bible ... (Rivest, RISKS-19.37)

The Risks of this go on and on: would information in languages that the FBI
can't translate also be illegal? It could be argued that languages are
elaborate "substitution codes".

Martin Gleeson, Information Systems Development, The University of Melbourne.
<URL:http://www.unimelb.edu.au/%7Egleeson/>

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

Date: Sat, 13 Sep 1997 09:37:13 GMT
From: [email protected] (len spyker)
Subject: Re: @LARGE -- Spaf quote (RISKS-19.37)

> One of the chapter-head quotes is from Gene Spafford: "Using encryption on
> the Internet is the equivalent of arranging an armored car to deliver
> credit-card information from someone living in a cardboard box to someone
> living on a park bench."  [PGN]

If what you read in RISKS, on Internet networks and their nonsecurity with
or without encryption, is accurate (and I don't doubt that), I would para
phrase it the other way around:

 Using encryption on the Internet is the equivalent of arranging a bike
 courier to verbally deliver credit-card information from someone living in
 a home or company fortress to someone in an expensive shop on Park Lane.

And a possible extra clarification

 Without encryption, the Internet is the equivalent of arranging for a gang
 of muggers to come into your own home.

Len Spyker

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

Date: Mon, 8 Sep 1997 18:14:07 -0400
From: Howard Melman <[email protected]>
Subject: Java Date Problems (Ryan, RISKS-19.37)

It may well be true that Java won't have a Y2K problem. But I've yet to find
a version of Java that has working Date classes. Try creating a new
GregorianCalendar() with no arguments and then setting it explicitly to Jan
27 1997 at 3:15pm (or any other time). If you inspect any of the other
fields in the GregorianCalendar (e.g., DAY_OF_YEAR, DAY_OF_WEEK,
DAY_OF_WEEK_IN_MONTH, AM_PM, HOUR, ZONE_OFFSET, or DST_OFFSET) you'll find
they haven't been set.

Or try creating a new GregorianCalendar object and calling
getFirstDayOfWeek().  It returns 1 but should be 0 in a US Locale.

You'll find other problems if you don't run in Pacific Standard Time. There
is a bug in java.text.SimpleDateFormat.initialize(). SimpleDateFormat in an
en_US locale initializes to PST (the first one listed in
java.text.resources.DateFormatZoneData_en) not TimeZone.getDefault() which
correctly (for me) returns EST (other fields correct for Daylight Savings
Time).

If you don't program Java, point your favorite Java enabled Web browser
(e.g., Netscape 4.01 on NT, recent versions of the IE Java VM seem to have
fixed this) at Intellicast's web site where they have a little Java clock
showing the local time and the GMT time, e.g.:

 http://www.intellicast.com/weather/bos/nexrad/

You'll find the local time to be PDT if you are in the US whether you're in
PDT or not.  And in older versions of Java you'd find that the GMT time is
off by an hour for DST.

The risk?  Don't assume that Y2K are the only date bugs you might have.

Howard

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

Date: Wed, 10 Sep 1997 16:47:28 -500
From: "Matt Toschlog" <[email protected]>
Subject: Risks of bad assumptions: octal numbers (Re: Gunshannon, RISKS-19.37)

 [Sent by Chris Green at Matt's request.]

Bill Gunshannon describes treating numbers with a leading zero as octal as
"quite normal and completely intentional."  That may be true if the reader
is a C parser -- the C spec dictates this behavior.  But the orginal case
cited was a user input box on a web page.  And though there's no "spec" for
how a user interprets an input box, it's certainly the assumption of
virtually everyone that numbers are in base 10.

The RISK here is assuming that a person things like a compiler.

Matt Toschlog, Outrage Entertainment

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

Date: Mon, 8 Sep 1997 13:48:01 -0500
From: Peter da Silva <[email protected]>
Subject: Long is 4 bytes? Not any more... (Re: Coats, Year 2038 problem)

[email protected] wrote:
> There is a substantial risk that systems from Sun, SGI, HP, and DG
> will still use 4-byte integers for "long" in 2038.

But not Digital:

amanda:subsonic:s5 8 % cat demo.c
#include <stdio.h>

main()
{
       printf("%d\n", sizeof(long));
}
amanda:subsonic:s5 9 % make demo
cc   demo.c  -o demo
amanda:subsonic:s5 10 % ./demo
8

Given the amount of code already ported to Digital UNIX, with few
sizeof(long) problems, I hope that people will realize that the
4-byte long is long overdue for replacement.

I've always thought it should have been 8 bytes on the VAX, myself.
It would have made it easier for me porting my PDP-11 code that assumed
sizeof(long) > sizeof(int), which had been the standard until, then.

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

Date: Mon, 08 Sep 1997 17:32:52 -0400
From: Steve Sapovits <[email protected]>
Subject: Re: Y2K and C (Rosenthal, RISKS-19.37)

[email protected] wrote:

> >> ... a C "long" which is currently 4 bytes.  When 64-bit operating systems
> >> finally catch on there will be a lot of code to change when "long"
> >> becomes 8 bytes, while the data on disk is still only 4.

I missed the original point above, but it's not really accurate (at least in
its snipped form).  C doesn't claim a long is 4 bytes.  The size of all the
types is basically machine dependent.  Yes, on most machines a long is 32
bits, but C doesn't decree that.

> C is the only language I've ever used in which the *source* code isn't even
> portable because such basic concepts as intrinsic datatypes are
> indeterminate (and are *defined* as such in the original specification).
> Does it worry anybody else that this is the language used by most people and
> taught to most beginners?  I suppose at least we're not teaching BASIC using
> two-letter variables and GOTOs, but still . . . .

I worry more that we're not training people how to program.  While C may
leave a lot to be desired, it certainly doesn't prevent one from solving
these problems.  I can't think of any language that doesn't allow you to
write data to a disk in a binary format.  Any ability to do that could be
considered a problem since as machines progress the sizes and byte ordering
of such binary data may change.

Most people who care concerned about such issues solve them through proper
design and programming.  You can, for example, use typedefs in C to properly
map sensitive data types to the appropriate base types so they can be easily
changed when the software is ported.  When writing data to files, you can
use a canonical format such as text to avoid the problem mentioned above.

Steve Sapovits  WinStar Telebase (http://www.telebase.com)  [email protected]

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

Date: Sat, 6 Sep 1997 17:42:49 -0400 (EDT)
From: Mike Reiter <[email protected]>
Subject: 1998 IEEE Symposium on Security and Privacy

PRELIMINARY CALL FOR PAPERS for 1998 IEEE Symposium on Security and Privacy
3-6 May 1998, Oakland, California, sponsored by
the IEEE Computer Society Technical Committee on Security and Privacy, in
cooperation with The International Association for Cryptologic Research (IACR)
(abstracted for RISKS)

Papers and panel proposals must be received by 6:00 P.M. EST on Monday,
24 November 1997, sent to
 Paul A. Karger, Program Co-Chair, IBM Corporation
 Thomas J. Watson Research Center, 30 Saw Mill River Road
 Hawthorne, NY 10532, USA
Please contact Paul Karger by electronic mail at [email protected] or by
telephone at +1 (914) 784-7294, relating to the submission procedures.

General Chair:     Mike Reiter, AT&T Labs - Research, USA
Vice Chair:        John McLean, Naval Research Laboratory, USA

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

Date: 1 Apr 1997 (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.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT 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]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, 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.38
************************

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.