precedence: bulk
Subject: RISKS DIGEST 19.78

RISKS-LIST: Risks-Forum Digest  Thursday 4 June 1998  Volume 19 : Issue 78

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

 Contents:
Mir mortals' bum steer (PGN)
Senate talks martial law and Y2K; Indian nuke-hackers (Declan McCullagh)
Corporate insurance excludes Y2K (Ulf Lindqvist)
The Year-2000 Muddle Continues (Andy Goldstein)
Texas accent required for voice recognition in UK (Mich Kabay)
Netomania (Edupage)
Nielsen Rate-Hiked (Declan McCullagh)
Risks of online phone books (Jeremy Epstein)
NorWeb denies 999 interference (Michael A. Eccles)
Re: Pager unreliability (Chris Cartledge)
Re: Navy stops teaching celestial navigation (Jeff Uphoff, Geoff Kuenning,
   Jim Wolper)
Re: Failure modes when the power fails (George C. Kaplan)
Disabling Java and JavaScript isn't totally safe either (Don Byrd)
Who is watching the capacity and performance needs of Java solutions?
   (Jerry Svigals)
Referer-log security hole (Jorn Barger)
globe.com vs Advertising Age passwords: spam and security problem
   (David Wittenberg)
Re: CzERT group of hackers ravage Czech & Slovak cyberspace (Steven Slatem)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 2 Jun 98 20:18:36 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Mir mortals' bum steer

Over the last weekend of May 1998, a computer critical to the Mir automatic
steering system failed.  The cosmonauts replaced it with a new one, but they
were unable to load the new one with software necessary to run the steering
system, at a time when the shuttle Discovery was about to be launched to
dock with Mir.  Finally, on Monday 1 June, the problem was resolved (just
*how* was not specified in the reports I saw), and the Discovery launch took
place.

 Does a tear appear when Mir won't steer?
 Well, have no fear, the veer's not near.
 The cheer from here I hear is clear.
 It's sheer delight.  You have our ear.

 So, quaff a kvass and hoist a beer,
 Let's hear it for the programmeer
 who caused the glitch to disappear --
 and thus inspired this sonneteer.

PGN

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

Date: Thu, 4 Jun 1998 14:21:28 -0700 (PDT)
From: Declan McCullagh <[email protected]>
Subject: Senate talks martial law and Y2K; Indian nuke-hackers

http://cgi.pathfinder.com/netly/afternoon/0%2c1012%2c2038%2c00.html

time.com / The Netly News / Afternoon Line, 4 Jun 1998

The Martial Plan

Think the Year 2000 problem means mere elevator snafus? Try dealing with a
platoon of Marines who show up in your front yard to confiscate your hoarded
lentils. Sen. Robert Bennett (R-Utah) asked the deputy secretary of defense
at a hearing this morning what plans the Pentagon has "in the event of a
Y2K-induced breakdown of community services that might call for martial
law." John Hamre replied carefully, but none too reassuringly, "We've got
fundamental issues to deal with that go beyond just the Year 2000
contingency planning. And I think you're right to bring that up." Another
distressing point that came up at the Senate Armed Services committee
hearing was the fact that the military directs one quarter of U.S. air
traffic. "You may be flying across the country and an air traffic controller
may be a military guy in certain areas as opposed to it being an FAA
person," Hamre said. Although the FAA's head Y2K guru assured us this
afternoon that the agency will have its Y2K fixes complete by October 1998,
the military appears to be in much worse shape. And other countries? "We can
be sure that there will be social unrest in many parts of the world as a
result of Y2K," Bennett said. For the record, though, Bennett did say, "I am
not one of those who says that Y2K will automatically produce martial law,"
and blamed "alarmists, extremists out there on the Internet" for unnecessary
scaremongering. --By Declan McCullagh/Washington

Hackistan

As if the accelerating arms race on the subcontinent weren't disturbing
enough, a group of hackers broke into the local area network of India's
Bhadha Atomic Research Center (BARC) and copied five megabytes' worth of
data, including e-mail between scientists and files from India's nuclear
research program.  [...]

 [According to an article by James Glave in WiReD News, 3 Jun 1998, James
 interviewed the three teenage "Milw0rm" crackers (in New Zealand and
 England) by Internet Relay Chat.  They apparently gained control over 6 of
 the 8 servers in *.barc.ernet, altered the BARC Web site, and deleted
 many files -- in protest against the Indian nuclear testing.  (The BARC is
 worse many bytes?)  They also e-mailed some of their discoveries to James.
 They say they are now going to take a closer look at the Pakistanis.  PGN]

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

Date: Mon, 1 Jun 1998 14:04:54 -0700 (PDT)
From: Ulf Lindqvist <[email protected]>
Subject: Corporate insurance excludes Y2K

I note that in their general conditions for corporate insurance policies,
one of the large Swedish insurance companies (Trygg-Hansa) have made the
following exclusion effective as of May 1, 1998 (my layman translation):

 "The policy will not cover damage, cost, legal or other liability caused
 directly or indirectly or connected to time-related disturbance in
 computer functionality."

This is hardly surprising, but it is interesting to note that the exclusion
specifically concerns only time-related overflow and would not for example
exclude the Dow Jones 10K problem.

Ulf Lindqvist, Department of Computer Engineering, Chalmers University of Tech.
SE-412 96  Goteborg, SWEDEN, Currently at SRI.   http://www.csl.sri.com/~ulf/

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

Date: Sun, 31 May 1998 10:41:48 -0400
From: [email protected] (Andy Goldstein - VMS Development)
Subject: The Year-2000 Muddle Continues

Yesterday I was in line at the register of a store I will leave nameless
to avoid undue embarrassment. Ahead of me, a silver-haired gentleman
handed over a check for his purchase. The register clerk stamped the
check (getting the stamp right side up on the second try) and took the
customer's vital statistics. She was puzzled when the computer wouldn't
take his birth date. After a phone call and consultation with a
supervisor, the man's check was approved, with the explanation that his
date of birth had been rejected "because of a recent year 2000 fix".

Figured it out? No further explanation was available, but I'll bet you
dollars to donuts they made the old "sliding window" fix, making all dates
before, say, 50, be in the 21st century. And of course the program was
smart enough to not accept birth dates in the future.

Morale: Having your code inspected and fixed for year-2000 compliance
is no guarantee it's going to work right.

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

Date: Wed, 3 Jun 1998 17:05:18 -0400
From: "Mich Kabay [ICSA]" <[email protected]>
Subject: Texas accent required for voice recognition in UK

According to an article in _The Guardian Weekly_ (May 10, 1998; p. 11),
biometric authentication using voice recognition has hit a stumbling block
because of trans-oceanic differences in accent.

> Tagging Test Pines for Texas, by Alan Travis

> A British experiment using an American device to monitor convicted
> criminals to be introduced later this year has hit a snag -- the high-tech
> "voice recognition" system only responds to a Texas drawl.

> The Home Office scheme involves ordering offenders to carry dedicated
> pagers with them to ensure check-ins several times a day.

The author explains that the paroled convicts are supposed to respond to the
request for check-in by phoning a toll-free number and identifying
themselves.  The biometric authentication system then authenticates their
identity.  I guess the system must also use automatic number identification
to track their physical location (although auto-forwarding of calls poses an
unmentioned threat to such a scheme).

The problem occurred when the unnamed brand of voice recognition system
failed to respond reliably to British accents.  Seems the Texas company
"trained" the system using only Texas drawls.

One additional problem: if the manufacturers in Texas assume that all
British people sound the same, they are in for a nasty surprise.  I suspect
that the variations of pronunciation and even of prosody in that tight
little isle exceed the variations found in television-drenched America (not
counting the wonderful flavours added by immigrants' accents).

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education International
Computer Security Association (Carlisle, PA) <http://www.icsa.net>

 [Quick-drawl artists need not apply.
 The AYES of Taxes are a pun us. PGN]

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

Date: Tue, 02 Jun 1998 16:49:05 -0400
From: Edupage Editors <[email protected]>
Subject: Netomania (Edupage)

Reporting a study of 14 so-called Internet "addicts," psychiatrist Nathan
Shapira of the University of Cincinnati says that, on average, the subjects
of the study each had had five psychiatric disorders.  Shapira thinks that
excessive online use should be considered not as a separate addiction but
as a disorder of impulse control, in the same category as kleptomania or
compulsive shopping.  He suggests the problem be called Internetomania or
Netomania.  (*USA Today*, 1 Jun 1998; Edupage, 2 June 1998)

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

Date: Wed, 3 Jun 1998 15:39:48 -0700 (PDT)
From: Declan McCullagh <[email protected]>
Subject: Nielsen Rate-Hiked

"Release of the prime-time television ratings has been delayed due to
computer problems at Nielsen Media Research. We hope to move them by
noon EDT."  (according to an AP item on 3 Jun 1998)

 [Declan later noted that a story slugged BC-Nielsens was out
 by 1:12pm, and the list of primetime shows made it by 3:10pm EDT.
 I suppose that many folks consider the ratings even more moving
 than the content of the listed programs themselves.  PGN]

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

Date: Tue, 02 Jun 1998 14:45:13 -0400
From: Jeremy Epstein <[email protected]>
Subject: Risks of online phone books

One of our staff took off early the other day because he received an
emergency phone call that a family member had been shot.  But it was a false
alarm caused by technology.

Seems that "Cousin Patrick" was shot, and "Aunt Penny" decided to tell
everyone.  She did a Web search for everyone with the same unusual last
name.  [I don't know how wide a geographical area she searched over.]  Among
the hits was someone on my staff, who was unrelated, but happens to also
have a Cousin Patrick and an Aunt Penny.  So he got an emergency phone call,
trundled off, etc.

Of course this could have occurred in the "old days" too, but it's much
easier to get those phone numbers now, while in the old days it would have
required a trip to the library and leafing through dozens of phone books (or
lots of calls to directory assistance).  And as a result, people would be
less likely to broadcast a warning to unknown "relatives".

Other than some lost time and some frightened people, no harm was done by
the mistaken identity.

Jeremy Epstein  [email protected], TIS Labs at Network Associates,
Northern Virginia Office  +1 (703) 356-2225 Ext 106

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

Date: Wed, 3 Jun 98 12:36:25 +0000
From: [email protected]
Subject: NorWeb denies 999 interference (Re: Slade, RISKS-19.74)

> ... Nick Long from the Low Power Radio Association reports that
> streetlamps in the Nortel trial region have been acting as highly
> efficient antennae ...

According to PCWEEK newspaper (2 June 98) here in the UK, NorWeb (the
company Nortel and Norweb established to develop the technology has
described the allegations as "fictitious and laughable". The company claim
that they have been working with the UK Radiocommunications Agency which has
stated "DPL (Digital Power Line) technology has not interfered in any way
with any radio spectrum users." NorWeb is considering legal action against
Great Circle Design, the company that made the allegations to the press.

Mike Eccles <[email protected]> Independent Safety Auditor for Software

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

Date: Tue, 2 Jun 1998 15:32:08 +0100
From: "Chris Cartledge" <[email protected]>
Subject: Re: Pager unreliability (McInnis, RISKS-19.76)

> Hospitals, doctors, and other emergency personnel (and those who
> depend on them) are dependent on paging systems.  Many businesses are
> dependent on paging systems.

I would question the risk analysis of any organisation that depends for
critical messages on the general use of pagers outside a well defined area.

Pagers have the message sent to them once and there is no acknowledgement --
the transmission is single ended and prone to failure.  In a recent test, a
UK consumer magazine found as many as 40% of messages could go astray if the
intended recipient was in a multi-story car park, metro station or similar
location where reception is difficult.

There is a more modern and reliable alternative - SMS, short message system
used with mobile phones, though it may be even more satellite dependent.

Chris Cartledge

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

Date: Tue, 2 Jun 1998 15:36:07 -0400
From: Jeff Uphoff <[email protected]>
Subject: Re: Navy stops teaching celestial navigation (Mannes, RISKS-19.76)

>> ... midshipmen will no longer have to learn the often tedious task of
>> using a wedge-shaped sextant to look at the stars and plot a ship's
>> course.

This statement strikes me as just a bit misleading: Celestial Navigation
was--at least when I was a Midshipman at Annapolis in the late 1980's--a
full-semester course; it was not just a few easily-replaced lessons stuffed
inside another course.

So...not only are they eliminating the Celestial Navigation course--they're
planning (according to a friend of mine that currently teaches at Annapolis)
on adding those "few extra lessons on how to navigate by computer" by
replacing some of the lessons in *yet another* navigation course: the basic
navigation course (a prerequisite for the Celestial Navigation course) that
teaches voyage planning, tidal computation, triangulation fixes, etc...real
bread & butter stuff for a junior officer.

Jeff Uphoff - Scientific Programming Analyst, National Radio Astronomy
Observatory Charlottesville, VA, USA [email protected] [email protected]

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

Date: Mon, 1 Jun 1998 14:06:29 -0700
From: Geoff Kuenning <[email protected]>
Subject: Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77)

> I believe there are still backup satnavs, independent of GPS...

I know of no backup satellite systems.  There was a predecessor to GPS, but
I'm pretty sure it's been shut down.  There are two existing ground systems
that provide near-worldwide coverage: Omega and Loran.  Omega is the older,
and is in the process of being retired (it was pretty unreliable already,
judging from the frequent outage notices).  Loran will be retired in the
next few years.

For some perspective, however: sextants are *not* reliable.  They depend on
having a reasonable clear view of both the horizon and some celestial body,
simultaneously.  That means that in bad weather you're stuck, sometimes for
many days at a time.  A flotilla steaming at 30 knots can cover a lot of
ocean, and might just go aground on an island, in that interval.  Even in
the best conditions, sextant shots are accurate to only +/- a mile or so,
making it hard to avoid (or find) that island if it's very small.

In contrast, the military built GPS under the assumption that the USSR would
have anti-satellite capability.  You know all those missiles we have in
silos?  Some don't have warheads; they have spare satellites.  I don't know
the exact numbers, but I'd bet they can get a new GPS broadcaster online in
minutes if they *really* need to.

Geoff Kuenning   [email protected]   http://fmg-www.cs.ucla.edu/geoff/

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

Date: Tue, 02 Jun 1998 19:34:02 +0000
From: Jim Wolper <[email protected]>
Subject: Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77)

Dave Pierson suggests, probably correctly, that the US Navy does not intend
to use GPS as the sole source for navigational information.  However, he
alludes to the Transit/SATNAV system as a possible backup system. This
system was decommissioned on 31 Dec 1996.

Nobody has said that the Navy intends to stop using celestial navigation ;
the assertion is that it will not be taught at the very beginning of an
officer's career.  A typical military officer undergoes advanced training as
a prerequisite to new assignments or promotion; a naval officer's training
no more stops at the Naval Academy than a physician's stops at medical
school.  It is certainly possible that young officers will be trained in
celestial navigation at sea.  This might be an improvement over classroom
training.

Jim Wolper ATP/PhD/CFI, Associate Professor of Mathematics, Idaho State
University   Pilot/Instructor, Avcenter, Inc.

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

Date: Tue, 26 May 1998 16:30:32 -0700
From: "George C. Kaplan" <[email protected]>
Subject: Re: Failure modes when the power fails (Weaver, RISKS-19.76)

In RISKS-19.76, Nicholas C. Weaver described various failure modes in the CS
department during the power failure that hit UC Berkeley on 19 May.  The
entire campus network was, of course, offline during this period, and all
the major network equipment was turned off to prevent damage due to surges
when the power returned.

When it became apparent that the power wouldn't come back before the
end of the working day the network support personnel went home, leaving
instructions with the skeleton operations crew to page them when the
power came back on.

By now we all know about that *other* little problem that afternoon.
Because our pagers weren't working, we didn't hear that power had returned
until someone happened to call in to work to check.  So restoration of
network operations took about an hour longer than it would have if Galaxy IV
hadn't failed.

George C. Kaplan, Communication & Network Services, University of California
at Berkeley  1-510-643-0496  [email protected]

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

Date: Wed, 03 Jun 1998 09:43:27 -0400
From: Don Byrd <[email protected]>
Subject: Disabling Java and JavaScript isn't totally safe either

To avoid the well-known risks of Java and JavaScript--cf. McGraw and
Felten's book Java Security, numerous comments in this forum, etc.--I
usually leave Java and JavaScript disabled in my Browser. But this leads to
another risk, namely missing something important that requires Java and/or
JavaScript but where it isn't clear that they're required. A minor example:
I was just looking at a Web site that boasted a link called "Privacy
Statement". I clicked on it and nothing happened. I tried again; same
result. I was about to give up, concluding that either they hadn't actually
put a statement online yet or the server was having problems of some sort,
when I noticed the status line of my browser showing the link as
"javascript:mapOpen...".

In experience, it is _very_ common for Web pages that depend on Java and/or
JavaScript to give no indication of that, even when you try to use the
dependent features. (If Java is disabled or not implemented, the browser
won't recognize the <applet> tag, and will very likely display any text
until </applet>. So informing the user of this situation is trivial. I
don't know about JavaScript.)

Don Byrd, Center for Intelligent Information Retrieval (CIIR), Computer Science
Department, U. Mass, Amherst, MA 01003 1-413-545-3147 [email protected]

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

Date: Mon, 25 May 1998 17:01:19 -0700 (PDT)
From: [email protected] (Jerry Svigals)
Subject: Who is watching the capacity and performance needs of Java solutions?

For the past decade, the "conventional" microprocessor smart card had an 8
bit wide microprocessor and up to 64,000 bits of memory.  The Sun Java
language has been proposed as a write once, run in any smart card,
application solution.  it is intended to overcome the fact that most smart
card vendors have an individual design and application architecture.  to run
the java application solution in any smart card requires the use of the java
virtual machine (jvm).  this is an interpretive program language which
converts the java application description into the native language of the
smart card being used.

last december (1997), at the card tech meeting in san jose, a senior sun
executive stated that performing the java application and the jvm requires
more capacity and performance than available in the "conventional"
microprocessor smart card. at the recent april 1998 card tech meeting, the
sun executive changed his tune.  it was possible to run a java application
and jvm in a conventional smart card.  when pressed for details he offered
that the operating system and input/output portions of the application
solution could be expressed in smart card native microprocessor language.
use of the java application language and the jvm could then be processed in
a conventional microprocessor smart card.

what happen to the write one solution, run anywhere java goal.  it has been
quietly abandoned if you want the economics of the conventional 8 bit wide
microprocessor smart card. the full solution is available by going to a
higher performance, higher capacity microprocessor smart card.  with the
need to use a 16 bit or 32 bit wide microprocessor the cost of the smart
card has increased by a factor of two or three times that of the
conventional smart card.

there appears to a quiet conspiracy not to disclose these facts.  sun will
not talk publically, unless pressed.  big java fans like ibm carefully omit
capacity and performance projections from their worldly pronouncements of
java application and smart card architecture.  the smart card vendors have
mostly announced support for java - but they appear to omit performance and
capacity details, even if pressed.

there are serious consequences to these actions.  the significant increase
in smart card costs is of great assistance to those trying to delay smart
card action programs.  it postpones the point at which a business case may
be made to proceed with smart card issue.  it also forces the smart card
vendors to come up with their individual native language components to
support java applications.  this is called an api.  how long will it take to
provide those components?  to what specifications?  what happened to the
write-once, any smart card solution - at implied conventional smart card
costs?

Jerome Svigals Inc., 221 yarborough lane, redwood city, ca 94061
1-650 365 5920  fax 650 363 2198  [email protected]

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

Date: Wed, 27 May 1998 17:14:23 -0500
From: [email protected] (Jorn Barger)
Subject: Referer-log security hole

On 11 May, CNet reported a security hole with the "My Excite" web 'portal',
where a subscriber's private ID (effectively their private password) may
show up in the referer-log of the next site they visit.  The article is at:

<URL:http://www.news.com/News/Item/0,4,21994,00.html>

..and I doublechecked it today with "Pascal's Header Echo" at
<URL:http://echo.znet.de:8888/> -- by pasting the Pascal URL into my
Netscape Location Bar, Pascal *or anyone* will see much more in my
headers than they ought:

===
I. Your Browser sent the following request to this server:

GET / HTTP/1.0 Referer: http://my.excite.com/?uid=12345ABC654321A0
Connection: Keep-Alive
User-Agent: Mozilla/4.03 (Macintosh; I; PPC, Nav)
Host: echo.znet.de:8888
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

===

I've changed the "uid" to a random equivalent, but anyone who found it in
their Referer-log would gain full access to my customized Excite data.

I don't remember even seeing this discussed, but presumably it applies just
as well if you've been browsing pornography, etc, or even looking at an HTML
file in your local filesystem... it would happily deliver up the full path
to that file.

[Added note:] It gets worse and worse:

Going to Altavista and querying "+my.excite.com.uid" turns up 200 pages,
many with usable My Excite passwords.

I EDIT THE NET: <URL:http://www.mcs.net/~jorn/html/weblogs/weblog.html>

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

Date: Thu, 4 Jun 1998 14:40:30 -0400 (EDT)
From: David Wittenberg <[email protected]>
Subject: globe.com vs Advertising Age passwords: spam and security problem

According to the New York Times 4 June electronic edition article "Marketing
Mixup Raises Concerns About the Privacy of Passwords", 35000 subscribers to
"Advertising Age" received unsolicited e-mail from theglobe.com.  There are
two concerns.  The minor concern is that some of them felt spammed.  The
major issue is that the mail contained an invitation to a free e-mail account
and provided a username/password pair.  This pair was their
username/password from "Advertising Age"'s web site.  Some users worried
that their passwords had been hacked.

In fact theglobe.com was running a site for "Advertising Age", so in that
sense the passwords weren't compromised directly, but why were the passwords
stored in plaintext?  There is also the risk of e-mailing passwords.

David Wittenberg <[email protected]>

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

Date: Wed, 03 Jun 1998 21:57:18 +0200
From: Steven Slatem <[email protected]>
Subject: Re: CzERT group of hackers ravage Czech & Slovak cyberspace (R 19 77)

Herewith are the links, mistakenly omitted in the last RISKS posting, to
the full story "CzERT lives on":

http://www.intellitech-media.cz/public-access/nbisn/19980524-75x.htm

Central & East European Hack Archive/CzERT Hack Archive:

http://www.intellitech-media.cz/public-access/cee-hack-archive/czert-hack-ar
chive

The author (me) welcomes your comments, questions and opinions in regards
to this story as well as the last posting to RISKS which contained points
exclusive to that posting.

- Steven Slatem, Editor-In-Chief, Networked Business & Information Security
News (NBISN), IntelliTech Media, Inc.  http://www.intellitech-media.cz

 [When including URLs in RISKS submissions, please remember to use only
 long-term URLs as in the case of these archival ones.   TNX.  PGN]

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

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

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.