precedence: bulk
Subject: RISKS DIGEST 19.53

RISKS-LIST: Risks-Forum Digest  Tuesday 6 January 1998  Volume 19 : Issue 53

  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:
Sun Valley ski area forgets to back up (David Kipping)
Debit-card program cancelled because of fraud (Steve Bellovin)
Japanese bank records stolen (Steve Bellovin)
Easter Eggs in Commercial Software (Larry Werring)
Pharmacy computer keys on names, mixing confidential records (anonymized)
MCImail spam blocker adds to woes (Michael M. Krieger)
Spammers blackmail AOL (Stephan Somogyi)
Sending the wrong message with flowers (Bear Giles)
Re: What really happened on Mars Rover Pathfinder (Ken Tindell, Fred Schneider)
Re: Adjust your defibrillator (Richard Cook)
Re: Has Microsoft already infected itself? (David M. Chess, Eric Cholet)
ERCIM-FMICS 3 - Call for papers (Diego Latella)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 24 Dec 1997 12:09:16 -0500
From: David Kipping <[email protected]>
Subject: Sun Valley ski area forgets to back up

The Sun Valley ski area in Idaho has a high-tech ticketing system.  You buy
a season discount pass for a small fee and get a card with photo and bar
code.  To ski you then pay for the day (at a discount).  There is no paper
ticket as all information is in the ticketing computer.  When you are ready
to get on the ski lift, an attendant scans your pass with a hand-held
terminal, your bar code is sent to the ticketing computer by radio, the
computer validates that you have paid for the day, and the result is sent
back by radio to the hand-held terminal.  All this happens in less than a
second.  The pass database is built up over several months as passes are
sold.

During the week of 14 Dec 1997, the hard disk on the ticketing computer
failed and the ticketing database was destroyed.  The computer hardware was
quickly repaired, but there was no backup for the ticketing database.  All
pass-holders (several thousand) are required to come to the Sun Valley
offices where personal data is re-entered, new photos are taken, and new
passes are issued.

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

Date: Sun, 28 Dec 1997 09:22:45 -0500
From: Steve Bellovin <[email protected]>
Subject: Debit-card program cancelled because of fraud

According to the AP, Burns National Bank (Durango, CO) is cancelling its
debit-card program because of fraud.  The article is maddeningly incomplete
about technical details.

Apparently, the "hackers" (to quote the article) counterfeited plastic cards
and "took account number sequences off software that resides on the Internet
before encoding them in the magnetic strip on the back of the card."  When
the fraud was detected, some customers had new cards issued, with some
unspecified extra security feature.  It didn't work; within a month, the
accounts were penetrated again.

Three other banks have been victimized by a similar scheme.  All four use
the same debit card vendor; Burns blames the vendor for inadequate security,
in some unspecified form.  They're looking for a new supplier; until then,
the entire program is being suspended.  Losses to date -- which are
apparently being absorbed by the banks -- total $300,000.

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

Date: Mon, 05 Jan 1998 11:40:15 -0500
From: Steve Bellovin <[email protected]>
Subject: Japanese bank records stolen

Reuters reports (http://www3.zdnet.com/zdnn/content/reut/0105/268074.html)
that a Japanese bank's computer records were penetrated.  Data on some
customers, including names, addresses, and birthdays, was taken.

The bank says that the problem likely occurred because of a software upgrade
last year.  It declined to release any further details about the software.

An AP report on the incident said that an employee with the firm doing the
software upgrade allegedly offered the data to a mailing-list company.  That
company alerted the bank, saying that the data -- which included financial
information -- was "too detailed".

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

Date: Mon, 5 Jan 1998 12:29:09 -0500
From: [email protected] (Larry Werring)
Subject: Easter Eggs in Commercial Software

Do you know what kind of hidden features are hidden in commercial
applications?  Do you know how much disk space is wasted as a result of
these hidden applications (known as Easter eggs) within commercial
applications?  What do Easter eggs have to say about project management,
quality control and configuration management of the company developing
products containing the Easter eggs?  How much extra is the consumer paying
for products to cover the cost of developing these hidden and utterly
useless applications?  How much time is being wasted by employees at the
expense of their employer (usually the customer who paid for the
application) to look for and play with these Easter eggs? What other unknown
features are embedded within commercial products? Can you trust any
commercially developed product?  What follows are two examples of Easter
eggs hidden within commercial applications (I have used Microsoft products
only to demonstrate how elaborate an Easter egg can be).

Example 1:

Open Excel 97.
Open a new worksheet and press the F5 key.
Type X97:L97 and press the Enter key.
Press the Tab key.
Hold Ctrl-Shift and click the Chart Wizard button on the tool bar.
Once the Easter egg is activated, use the mouse to fly around - right
button for forward, left for reverse.

Note: If you don't have DirectX drivers installed you will only get a list
of developer names.  If you do, you will encounter a flight simulator.  Can
you find the focal point of the virtual region with the scrolling display?

Example 2:

Open Internet Explorer.
Select "About Internet Explorer" from the help menu.
Hold down the Ctrl key and use the mouse to select and drag the "e" in the
upper right hand corner onto the picture of the Earth and release the Ctrl key.
Hold down the Ctrl key again and use the mouse to drag the "e" so that it
pushes the words "Microsoft Internet Explorer 4.0" out of the way and
return the "e" to the planet earth.
If it hasn't already started to run, press the "unlock" button to see a
display of all the IE 4.0 development team.

Note: This Easter egg is lengthy.  The author has attempted to interject
humour at various points in the display but has failed miserably.  In fact,
the author admits to a crime committed by one or more members of the team
(theft of construction sign - remember the teenager convicted of multiple
counts of manslaughter for stealing a traffic sign).  Also, at the very end
of the display, the author impugns the character of several team members
(basis for possible defamation of character suit by the individuals?).  I'll
bet that this Easter egg was never approved by the IE 4.0 project manager or
Bill Gates.

So-called Easter Eggs are hidden within many Microsoft applications (Windows
95 and NT, for example).  However, other products apparently have them as
well (e.g. Netscape and Macintosh System 7.5 for example).

I remember the days when every line of code was examined before we would
allow a program to be used in a trusted environment.  This was deemed too
expensive so now we "trust" software creators.  How can you "trust" any
commercial product sold by a major manufacturer when it can be demonstrated
that many products from the manufacturer include hidden applications and
possibly functions as part of the product.

Note:  I addressed an e-mail about this to Microsoft's Security guru's but,
as usual, got nothing back but an acknowledgement of receipt.

Larry Werring, IT Security Consultant

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

Date: Weds, 24 Dec 1997
From: [identity withheld by request]
Subject: Pharmacy computer keys on names, mixing confidential records

I suffer from an embarrassing medical condition, treatable only by expensive
medication that has no other uses in adults.  If you buy the medication, in
other words, you probably have the condition.

My doctor phoned a prescription in to the local CVS.  Ninety minutes later,
I showed up to collect it.  I told the pharmacist my name, and she handed me
the medication.  She then told me my insurance had expired in January 1997,
and I would therefore have to pay the full price.

I explained to her that my insurance (through an HMO) is very much in force
but doesn't cover drugs, and that she obviously had bad information,
presumably from CVS' computers.  Both my given name and surname are fairly
common in the U.S.A.; there are at least four others with my first and last
names in the local area.

She refused to believe me at first, changing her mind only when I pointed
out that it wasn't my address her computer had printed on the receipt.  She
then took back the medication, asked for my name, date of birth, address,
telephone number, and medical allergies.  Irked, but wanting to avoid a
fight, I tendered information to her satisfaction, paid for the medication,
and left the store.

Apparently, when the prescription came in, CVS simply assumed that it must
have been for the person with the same name already in their system.  I can
think of at least five risks of this sloppy system:

1.  If the other guy's insurance hadn't expired, I could have scammed
   free or nearly-free medication on his (insurance's) dime.

2.  If I hadn't asked what was going on, his records at CVS would show
   that he obtained medication for an embarrassing medical condition.

3.  Since I'm quite certain the CVS technician didn't call back to
   disabuse them, his old insurance now thinks he obtained medication
   for an embarrassing medical condition.  If I had been getting the
   equally distinctive drugs for HIV, such a disclosure could have quite
   serious consequences for the poor sap.

4.  CVS' database includes information on patients' allergies to
   medication.  The pharmacist didn't ask me whether I had any
   allergies until after I established that she was working from
   the wrong record.  Their vaunted system for tracking patients
   will not work to the extent they are mixing up people with the
   same name.

5.  Immediately distrustful of CVS, I gave the pharmacist a false
   address, phone number, and date of birth.  Now there are five
   locals with my first and last name.

Silver lining: at least they don't key on the Social Security Number.

 [... although that can beneficially disambiguate...  PGN]

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

Date: Thu, 25 Dec 1997 22:26:39 -0500 (EST)
From: "Michael M. Krieger" <MKRIEGER/[email protected]>
Subject: MCImail spam blocker adds to woes

MCI Mail's new anti-spam filter option depends on a non-optional system
change MCI's Internet gateway makes to subscriber addresses when sending
outbound messages; this yields undesirable consequences, perhaps worse than
the original spam problem.

In particular, MCI Mail created a (probability ---> 1.0) Risk of its users
being sitting ducks for spammers when it switched to sequentially assigning
the traditional seven digit 123-4567 address/ID's to new accounts (in lieu
of spacing them out).  This allows automated spam addressing, e.g., the
Internet addresses <[email protected]>, <[email protected]>, ...

To overcome this, MCI Mail recently gave its users the option to block
numerically addressed messages (e.g., <[email protected]> in my case),
while making
         <username/[email protected]> a new acceptable address format.

Because "username" (which is a user's logon, e.g., "jsmith") is not public
(nor susceptible to automated deduction from the 7-digit address),
over-spammed MCI Mail users can invoke the filter while giving
<username/[email protected]> to friends and other correspondents.

All well so far.  But "to complement the new filtering capability," MCI
Mail now converts (NON-optionally) its members' addresses to the new
format when messages exit the gateway into the Internet
 "so that if you did invoke the filter, your correspondents could still
  use their "reply" function and capture your address in a way that won't
  be impacted by the filter.  This change will take effect on Nov. 24."
  [quotes from MCI Messaging Notification, to Users on 12 Nov 1997]

Oops! Shouldn't this have been optional too?
Might not an MCI Mail user's intended Internet recipient have him/herself
already implemented blocking rules or filtering mechanism which will reject
  <username/[email protected]> as unknown?

The obvious Risks are failed messages (some of which likely won't even yield
rejection notices) and corresponding business and personal loses, the burden
of resubscribing to listservs which can no longer recognize you, etc.
Moreover, in the future changing a "username" will mean resubscribing to
lists, and other administrative overhead.  Good way to drive off customers.

Perhaps most detrimentally, this forces the user's "username" into the
clear.  Although MCI Mail defaults new users to "jsmith" format, that can
be changed arbitrarily to anything, e.g., "smartestjsmith."  One might wish
to keep it private (account logon is the "username" and, if unique within
the MCI Mail system, "username" can also replace 123-4567 within MCI Mail,
as part of Internet addresses, etc.).

Finally, with time listmakers and spammers will capture many "username"'s
after which they will be even more difficult for users to elude than before!

Michael M. Krieger

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

Date: Wed, 31 Dec 1997 16:31:30 -0500
From: Stephan Somogyi <[email protected]>
Subject: Spammers blackmail AOL

 [Via the IP list of Dave Farber <[email protected]> ]

CNN's been reporting this on Headline News today, but no reference to it on
their Web sites. However, the LA Times has the following on the subject:

<<http://www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_aol1231.htm>http://
www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_aol1231.htm>

Stephan

A small snip of the LA Times article:

The opposing interests of electronic commerce and individual privacy erupted
in conflict Tuesday after a small Internet business group threatened to make
public the e-mail addresses of 1 million of America Online's 10 million
users if the giant service continues to bar the businesses from pitching
their products online to AOL members.  The Chino-based National Organization
of Internet Commerce said it would post the e-mail addresses on its own Web
site at the stroke of midnight Wednesday, making them available for
downloading by any business, group or individual seeking to make mass
electronic mailings.  The organization said it would leave the names posted
for 24 hours unless AOL offered small businesses a way to reach its 10
million members through inexpensive electronic means.

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

From: Bear Giles <[email protected]>
Subject: Sending the wrong message with flowers
Date: Fri, 2 Jan 1998 15:39:57 -0700 (MST)

At the FTD website (www.ftd.com), the links for "get well" and "funeral"
arrangements are adjacent.  No problem with new mice driven by someone under
no stress, but with an older mouse and frazzled nerves it would be easy to
click "funeral" instead of "get well" -- something that would not be
pleasant for the viewer.

The risk is that page layout for interactive media is different than
non-interactive media.  Something which works well, when simply read, may
have serious flaws when it requires a person to interact with it in
real-world conditions.

Bear Giles <[email protected]>

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

Date: Fri, 12 Dec 1997 19:16:15 -0000
From: Ken Tindell <[email protected]>
Subject: Re: What really happened on Mars Rover Pathfinder (Jones, R-19.49)

>This scenario is a classic case of priority inversion.

So classic that it has happened before many times in many projects.  And I
fear will continue to happen. Today, people are building critical real-time
systems based on Windows NT. But NT doesn't implement priority inheritance.
Instead it contains a "priority randomizer" which randomly selects tasks and
alters their priorities in the hope that eventually the priority inversion
goes away. Whilst this may be adequate for a general-purpose computer in a
workstation environment, this is unlikely to be adequate for a critical
real-time system.

>For the record, the paper was:
>L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
>Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
>vol. 39, pp. 1175-1185, Sep. 1990.

I must point out that their work appeared much earlier in technical reports
and conference proceedings and was widely cited before the 1990 paper
appeared.  Interested readers might like to read the following paper, which
gives an historical perspective on when major results were made available:

 "Fixed Priority Scheduling: An Historical Perspective", Audsley, Burns,
 Davis, Tindell, Wellings, Real-Time Systems journal, March 1995, Volume 8,
 No. 2/3, pp. 173-198.

I find it outrageous that engineers in 1997 are building critical systems
that contain serious defects that were detectable and correctable ten years
ago. I do wonder at what point failure to be aware of these risks
constitutes negligence.

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

Date: Mon, 5 Jan 1998 18:29:27 -0500 (EST)
From: "Fred B. Schneider" <[email protected]>
Subject: What really happened on Mars Rover Pathfinder (Mike Jones, R-19.49)

Readers of RISKS could get the wrong impression about who did what and when
from what David Wilner is reported to have said in Mike Jones' item on the
Mars Pathfinder mission in RISKS-19.49.  This note attempts to provide some
missing information.

Jones' Mars Pathfinder article ends with:

  "THE IMPORTANCE OF GOOD THEORY/ALGORITHMS

  David [Wilner] also said that some of the real heroes of the situation
  were some people from CMU who had published a paper he'd heard presented
  many years ago who first identified the priority inversion problem and
  proposed the solution.  ...

  For the record, the paper was:

  L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols:
  An Approach to Real-Time Synchronization. In IEEE Transactions on
  Computers, vol. 39, pp. 1175-1185, Sep. 1990."

Actually, a "priority inheritance" protocol can be found in

 B. W. Lampson and D. D. Redell.
 Experience with processes and monitors in Mesa.
 {\it Communications of the ACM},
 vol. 23, no. 2, pp. 105--117, February 1980.

which is a reprint of a paper that appeared in Dec 1979 (7th ACM Symposium
on Operating System Principles).  Below is the relevant excerpt; it is
almost -- but not exactly -- what Sha et al. investigate.

  "4.3  Priorities

    In some applications it is desirable to use a priority scheduling
  discipline for allocating the processor(s) to processes which are not
  waiting.  Unless care is taken, the ordering implied by the assignment
  of priorities can be subverted by monitors.  Suppose there are three
  priority levels (3 highest, 1 lowest), and three processes P_1, P_2,
  and P_3, one running at each level.  Let P_1 and P_3 communicate using
  a monitor M.  Now consider the following sequence of events:

   P_1 enters M
   P_1 is preempted by P_2
   P_2 is preempted by P_3
   P_3 tries to enter the monitor, and waits for the lock
   P_2 runs again, and can effectively prevent P_3 from
    running, contrary to the purpose of the priorities

    A simple way to avoid this situation is to associate with each
  monitor the priority of the highest-priority process which ever enters
  that monitor.  Then whenever a process enters a monitor, its priority
  is temporarily increased to the monitor's priority..."

So, it would be incorrect to credit Sha et al. for first *identifying* the
problem or for first *proposing a protocol* to solve it.  Lampson & Redell
do not give any quantitative analysis of their prio scheme, though.

The development of this thread of research in real-time scheduling is
accurately described in section 5 of Audsley et al., as noted by Ken Tindell.

A parable comes to mind.  School children in the U.S. are taught that
"Columbus discovered America".  Ultimately they learn that Columbus
was preceded by, among others, the Vikings.  So why aren't they taught
that "The vikings discovered America"?  Perhaps it is because when
Columbus discovered America, it stayed discovered.

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

Date: Fri, 26 Dec 1997 08:40:50 -0600
From: Richard Cook <[email protected]>
Subject: Re: Adjust your defibrillator (McGraw, RISKS-19.52)

Gary McGraw seems surprised that implantable defibrillators can be
externally programmed and hopes that there are some safety mechanisms
available to prevent unintended or maliciously intended reprogramming. I
encounter these devices in my daily practice and want to provide a little
background for other readers of RISKS.

Actually, these devices are pretty much the definers of what is the state of
the art in medical electronics. I know of no other information technology in
medicine (including all the monitoring and lab system technology that we
have studied and written about over the years) that has anything like the
reliability and robustness of heart pacers and defibrillators.  It may be
interesting for readers to know that, until very recently, the only way one
could become a candidate for an implantable defibrillator is to have had a
documented episode of sudden cardiac death, i.e. to have had ventricular
fibrillation. Needless to say, this kept the potential recipient pool small:
few people survive the initial event!

The devices have a number of features that are tuned to individual patient
characteristics, and they are re-tuned over time. What one is trying to do
is to assure that the device will sense fibrillation and fire but not fire
when fibrillation is not actually present. It can be uncomfortably startling
to be defibrillated when nothing is really going on, and these devices have
lots of program dedicated to making sure that a shock is really indicated.

For this reason, programming of the devices is an essential feature -- you
can't really use them effectively without being able to interrogate them,
reset various features and tune them in a number of ways. Gary's claim that
this is a source of risk is surely true, and it is one (but only one) reason
that the guys who make these things are so heavily invested in reliability
and safety. In fact, I suspect that this sort of device is less a model of
what can go wrong and more a model of what actually can be done well not
only in medical devices but with technology in general. But it is always
useful to keep in mind that the people walking around with these things have
already had at least one major lesson in coping with risk! This is the only
device, besides a coffin, that I know of that you have to die to get!
                                          Cognitive Technologies Laboratory
Richard I. Cook, MD, Department of Anesthesia and Critical Care, University
of Chicago; 5841 S. Maryland Ave., MC 4028; Chicago, IL 60637 1+773-702-5306

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

Date: Tue, 6 Jan 98 09:19:49 EST
From: "David M. Chess" <[email protected]>
Subject: Re: Has Microsoft already infected itself? (Brown, RISKS-19.52)

> Can anyone explain what this string is doing in WWINTL32.DLL

That is a string that occurs in the "DMV" Word macro virus.  It is present
in that DLL almost certainly in order to allow Word for Office 97 to
recognize that virus in infected Office95-format files, so that it can avoid
bringing the virus along when it converts to Office 97 format.  There are a
number of different virus-fragments in that DLL.  (This has in fact led to a
certain amount of confusion.  It is accepted practice in the anti-virus
community to always mask or otherwise trivially encrypt such virus
search-strings so as to avoid false positives and user suspicions; that was
not done in this case, obviously.)

Knowing too much, too obviously, about the enemy is often enough
to get you suspected yourself...  *8)

David M. Chess, High Integrity Computing Lab, IBM Watson Research

 [Also commented on by Eric Florack <[email protected]>.  PGN]

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

Date: Wed, 24 Dec 1997 20:02:14 +0100
From: Eric Cholet <[email protected]>
Subject: Re: Has Microsoft already infected itself? (Brown, RISKS-19.52)

Well, I examined my copy of the same file, and found a bunch of such strings:

You have been infected by the Alliance
This one's for you, Bosco
echo y|format c: /u
STOP ALL FRENCH NUCLEAR TESTING IN THE PACIFIC!
Parasite Virus 1.0
InfectorPayLoad
Where's the Gerbil of bubby?
Now, where's that Gerbil of bubby?
Hi sexy!
Description : On FileOpen, detect documents masquerading as templates,
 warn user and optionally restore them to documents

My guess is that they're simply virus signatures used by Word's macro virus
detection code.  Still, where's the Gerbil of bubby ?

Eric Cholet <[email protected]>

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

Date: Mon, 5 Jan 1998 15:46:27 +0100 (MET)
From: Diego Latella <[email protected]>
Subject: ERCIM-FMICS 3 - Call for papers

                        FIRST CALL FOR PAPERS
             Third ERCIM International Workshop on
      Formal Methods for Industrial Critical Systems (FMICS)
               Centrum voor Wiskunde en Informatica (CWI)
          CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
                            May 25-26, 1998

The First International Workshop on Formal Methods for Industrial Critical
Systems took place in Oxford on March 19, 1996, and the second edition was
held in Cesena on July 4-5, 1997. The Third International Workshop will take
place in Amsterdam on May 25-26, 1998.

The aim of the FMICS workshops is to provide a forum mainly intended for,
but not limited to, researchers of ERCIM sites, who are interested in the
development and application of formal methods in industry. In particular,
these workshops should bring together scientists that are active in the area
of formal methods and interested in exchanging their experiences in the
industrial usage of these methods. They also aim at the promotion of
research and development for the improvement of formal methods and tools for
industrial applications.

Please notice that the FMICS workshop will be held in the same week as the
ICDCS98 conference, which will also be held in Amsterdam.

Authors are invited to send five copies of a full paper (in English, up to
25 pages) to the Programme Chair:
 J.F. Groote, CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands
by February 15th, 1998. An electronic version of the paper in Postscript
format plus an abstract should also be sent to: [email protected].

INVITED SPEAKERS include
 W.J. Fokkink - University of Swansea - UK
 G. Kolk - Holland Railconsult - NL
 S. Smolka - State University of New York - Stony Brook, USA

PROGRAMME COMMITTEE:
 J.F. Groote - CWI - NL (Chair)
 F. Gnesi - CNR/IEI - Pisa, IT
 D. Latella - CNR/CNUCE - Pisa, IT
 R. Mateescu - CWI - NL
 A. Poigne - GMD - Bonn, G
 J. Tretmans - University of Twente - NL

Informal participant proceedings will be distributed at the workshop.

Deadline for submission:  15 February 1998

Up-to-date information will appear at
 http://www.cwi.nl/~luttik/FMICS/index.html

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

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

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.