precedence: bulk
Subject: Risks Digest 20.13

RISKS-LIST: Risks-Forum Digest  Thursday 24 December 1998  Volume 20 : Issue 13

  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 <URL:http://catless.ncl.ac.uk/Risks/20.13.html>
and at ftp.sri.com/risks/ .

 Contents: [HAPPY HOLIDAYS!]
Near-miss at LaGuardia Airport, NYC (Dave Weingart)
Runaway train on Capitol Hill (Thomas A. Russ)
Another fibre-optic cable cut (Bob Blanchard)
British Government admits Y2K missile problem (Phil Pennock)
2,000 Texans get false overdraft notes in Y2K test (Bill Bauriedel)
Wassenaar Agreement exempts 'public domain' software (Martin Hamilton)
Other infrared security crocks (Paul Wexelblat)
Re: PalmPilots voiding car locks in Europe (Philip Koopman)
E-LIFE'S RISKS? I.R.S. E-FILE! (Andrew Greene)
Should pilots trust TCAS? (Andres Zellweger)
Airlines databases lock in increases better then refunds (Peter)
Re: Frequent Flyer miles accessible (Peter)
Y2K expansion (Jerry Leichter)
Intelligent virus invades NT servers (Edupage Editors)
Unexpected date behavior in Windows 95 (Daniel Weber)
Microsoft Trojan Horse (Frank Markus)
Quark XPress, hates Unix scripts! (Ben Sherman)
Password hint risks (Alexander V. Konstantinou)
Risks in incorrect warnings and alerts (Flint Pellett)
CFP: 1999 National Information Systems Security Conference (Ed Borodkin)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 10 Dec 1998 09:24:40 -0500
From: Dave Weingart <[email protected]>
Subject: Near-miss at LaGuardia Airport, NYC

According to reports I heard on the radio this morning, a US Airways Boeing
737 came less than 100 feet (some reports say withing 50 feet) landing on
smack on top of a small corporate plane at LaGuardia Airport in New York
City on Wednesday, 2 Dec 1998.  The passenger flight was given permission to
land, despite the fact that the smaller plane was waiting to take off on the
same runway.  The near-disaster has been blamed on too few controllers being
too distracted.

Dave Weingart, Strategix Solutions  [email protected]     1-516-682-1470

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

Date: 17 Dec 1998 13:52:45 -0800
From: [email protected] (Thomas A. Russ)
Subject: Runaway train on Capitol Hill

I found the following item in the *Los Angeles Times* 16 Dec 1998.
Especially intriguing are the spokesman's comments.  There is also the
nagging question of why there is an operator on a fully automated system in
the first place.

 ...there IS a runaway train on Capitol Hill.  The automatic brakes on
 the Senate subway between the Russell Office Building and the Capitol
 failed last week, sending the train crashing into a wall and slightly
 injuring the operator and the two other people on board.  In the best
 congressional spirit, a spokesman for the architect of the Capitol
 stressed that "there was no operator fault involved.  It's all
 automatic," said Herb Franklin, "and it's supposed to stop by itself."

Thomas A. Russ,  USC/Information Sciences Institute          [email protected]

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

Date: Wed, 09 Dec 1998 22:07:20 -0500
From: Bob Blanchard <[email protected]>
Subject: Another fibre-optic cable cut

My office's frame relay link to our corporate WAN was out for a day on 26
Nov 1998.  As it turns out, we were not alone.  A railway backhoe operator
accidentally cut an AT&T Canada fibre cable along the rail line between
Toronto and Windsor, crashing computers, knocking out phone lines, and
generally disrupting communications in southern Ontario.  The main branch of
the Bank of Nova Scotia was computerless.  Rerouting of Internet lines via
the U.S. was slow because of the Thanksgiving holiday.  [Source: Veronique
Mandal, ``Cut Cable Paralyses Network - Severed line brings hi-tech to its
knees'', *Windsor Star, London Free Press, Chatham Daily News*, 27 Nov 1998;
PGN Abstracting]

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

Date: Wed, 9 Dec 1998 23:03:55 +0000
From: Phil Pennock <[email protected]>
Subject: British Government admits Y2K missile problem

From The Times, 9 Dec 1998, p2:

Bug threat to missile

The Ministry of Defense admitted for the first time that the millennium bug
could have left Britain vulnerable to air attack.  It discovered that the
Rapier anti-aircraft missile would have failed to retaliate.  The problem
was identified inside the field equipment which activates the missiles and
it would have made the system inoperable.  The threat to Britain's defenses
posed by the computer bug was outlined by George Robertson, the Defense
Secretary.  [Well, at least the failure mode was to not fire.]

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

Date:     Fri, 18 Dec 98 10:47:21 PST
From: "Bill Bauriedel"  <[email protected]>
Subject:  2,000 Texans get false overdraft notes in Y2K test

2,000 Texans get false overdraft notes in Y2K test
Reuters, Detroit News, 12/17/1998

Bank One Texas was testing their Y2K systems to see if they could send out
overdraft notices after "1/1/00".  They were able to print over 2,000
fabricated notices.  But someone forgot to throw away the printouts, which
were mailed out! <http://www.detnews.com/1998/technology/9812/17/12170189.htm>

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

Date: Fri, 11 Dec 1998 17:00:48 +0000
From: Martin Hamilton <[email protected]>
Subject: Wassenaar Agreement exempts 'public domain' software

Just to note that the Wassenaar Agreement explicitly exempts 'public
domain' software, in its 'General Technology Note':

 Controls do not apply to "technology" "in the public domain", to
 "basic scientific research" or to the minimum necessary information
 for patent applications.

The 'General Software Note' has this to add:

 The Lists do not control "software" which is either:

   1. Generally available to the public by being:

     a. Sold from stock at retail selling points without restriction,
          by means of:

       1. Over-the-counter transactions;
       2. Mail order transactions; or
       3. Telephone call transactions; and

     b. Designed for installation by the user without further
          substantial support by the supplier; or

   N.B. Entry 1 of the General Software Note does not release
      "software" controlled by Category 5 Part 2.

   2. "In the public domain".

See <URL:http://www.wassenaar.org/List/GTNGSN.doc>.  Category 5 is the
section on 'Information Security', of course.  Last updated 10th
December 1998.

"In the public domain" is defined as:

 This means "technology" or "software" which has been made available
 without restrictions upon its further dissemination.

 N.B. Copyright restrictions do not remove "technology" or "software"
 from being "in the public domain".

See <URL:http://www.wassenaar.org/List/Def.doc>.

Martin

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

Date: Thu, 10 Dec 1998 11:52:02 -0500
From: Paul Wexelblat <[email protected]>
Subject: Other infrared security crocks

The discussion in RISKS-20.10 about theft of infrared codes for door locks
brings to mind two similar issues.

1. Conventional RF garage door openers left in cars at parking/repair
garages are easily opened so "the baddies" can see the code and program a
"universal" opener to get in -- many folks don't lock the door between their
garage and house.

2. My household internal alarm system uses coded infrared beams. These are
trivially defeated with one of those X-10 type "control extenders".  A
device (you may have seen them, they're 3" pyramid shaped things) that you
zap your IR remote control at, this device converts the signal to RF that
goes through walls and the receiver reconverts and emits IR to the
sensor. (I use one to control my cable box from the bedroom.)

Using this thing I can just put the pair between the alarm transmitter and
receiver and walk on through.

..wex

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

Date: Thu, 10 Dec 1998 03:43:17 GMT
From: Philip Koopman <[email protected]>
Subject: Re: PalmPilots voiding car locks in Europe (McCoy, RISKS-20.10)

I have heard that one can get stand-alone "diagnostic" boxes to record and
play back transmissions for the RF car interfaces.  In fact, in response to
this some vehicles with RF interfaces already have cryptographic encoding of
transmissions (I designed such a system with Alan Finn back in my industrial
research lab days, and it is in moderately wide use in some US vehicles
today).

One of the RISKS of this area is that in general the market won't currently
bear the cost of high-strength cryptography -- they only get a few cents
extra to spend on it, and even something like DES tends to cost too much.
So it is difficult for consumers to evaluate whether they're getting crypto
that is strong enough to be reasonable for the application, or one of the
systems that says it is but really isn't (or one of the systems that really
is but competitors claim it isn't, or ...).

Phil Koopman -- [email protected] -- http://www.ece.cmu.edu/~koopman

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

Date: Thu, 10 Dec 1998 11:16:38 -0500
From: [email protected] (Andrew Greene)
Subject: E-LIFE'S RISKS? I.R.S. E-FILE!

I received a postcard this weekend from the Internal Revenue Service,
notifying me that my wife and I have been selected to (optionally)
participate in a pilot implementation of the new, improved "e-File".  This
is a way of electronically filing our income tax returns next April, where
not only is the information transmitted electronically and the payment or
refund handled via EFT, but we will not even be required to mail in a
signature card.

Instead of the physical signature card, we can simply use the electronic
"signature" number enclosed in a sealed section of the postcard that we
received this weekend. (The number is only five digits, but for a one-time
use that's probably not too bad.... right?)

It's an old story, I know, but one which apparently bears repeating, because
organizations are still doing it. This piece of mail was unsolicited, so had
someone pilfered it from my mailbox and used it to file a false return, *I*
would have been the one in trouble with the IRS.

- Andrew Greene

 [Nice palindromic subject line (ignoring punctuation)!  PGN]

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

Date: Thu, 24 Dec 1998 10:14:08 -0500
From: [email protected] (Andres Zellweger)
Subject: Should pilots trust TCAS?

In RISKS-20.12 David Wittenberg reported on two situations, one where TCAS
may have created an incident that was "saved" by air traffic controllers and
another where air traffic controllers may have created an incident that was
"saved" by TCAS.  He asks "How are pilots to know which one to trust when
they must make decisions quickly?"

I recently completed a case study on TCAS for a graduate seminar on building
safe systems.  My students and I were convince, after looking at the
extensive TCAS safety activities over the last 15 years, that TCAS is indeed
a very effective "safety net" for pilots.

After TCAS introduction began, it became clear that a clear set of TCAS
operational procedures for both pilots and controllers was necessary to get
the full safety benefits of TCAS.  For instance:

- "pilots should follow resolution advisories unless doing so jeopardizes
the safe operation of the flight or the flight crew has definitive visual
acquisition of the intruder."

- "when responding to a resolution advisory hat directs a deviation from an
ATC clearance, pilots should communicate with ATC as soon as possible."

- "after a controller has been informed that an aircraft is responding to a
resolution advisory, the controller should not issue control instructions to
that aircraft that are contrary to the resolution advisory."

and so on ...

I would personally be very upset if pilots, at this stage in the evolution
of TCAS did not follow TCAS resolution advisories.  The probability of TCAS
errors is very small compared to the likelihood that an air traffic control
countermand to a TCAS advisory will lead to potential problems.

Unfortunately, I have not seen any reports of the FAA's (or anyone else's)
investigation into the former (more interesting, from a safety perspective)
incident. The good news is that analysis of reported incidents like this has
historically continued to lead to TCAS improvements.  The bad news is that
the FAA's investment banker has not seen it fit to continue funding of the
~TCAS Program at levels sufficient to continue TCAS improvements. Indeed,
there are some who have questioned whether the safety analysis of the new
TCAS version 7.0 (developed primarily for use in European airspace) has been
adequate.

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

Date: Sat, 12 Dec 1998 22:43:47 +0000
From: [email protected]
Subject: Airlines databases lock in increases better then refunds

Earlier this year I had occasion to return from Johannesburg to London on
business. I was booked business class for this journey.  On the flight day
the airline was a plane down so I and a colleague were transferred to
economy on the next plane. All the paperwork ws completed and entered into
computer on check-in.

When I returned to the office I asked the staff who deal with travel to
verify with our travel agent that the downgrade was credited with a refund
to the business. This did not happen. Full fare was charged.  It took many
months to unsnarl the paper trail and it was not clear who should have
informed who about what. The way the legalese on tickets is written maybe it
was all our fault for traveling!

It took us many man-hours to resolve the situation and probably many
business travelers do not bother assuming that "the system" sorts out
little details. But when "the system" comprises the IS systems of several
travel firms and subcontractors programmed to bill any upgrades or additions
exactly it only takes one to fail to pass on refunds to give a "heads you
lose" situation. Just like the vending machines -- they never dispense free
drinks but there are often stickers on them saying, "it owes me 17p" (UK
pence).

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

Date: Sat, 12 Dec 1998 22:43:47 +0000
From: [email protected]
Subject: Re: Frequent Flyer miles accessible (RISKS-20.12)

I find the quote from NW surprising in view of the fact that the BA
"Airmiles" accounts can only be used from the WWW with an initial PIN sent
by snail mail to the account holder's address. Changing the PIN can only be
done online using https: access.

Unlike in the US, in Britain there is popular reluctance to adopt universal
ID such as by Social Security number or phone number.

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

Date: Sun, 13 Dec 98 08:21:25 EST
From: Jerry Leichter <[email protected]>
Subject: Y2K expansion

As not-particularly-competent (but professionally paranoid) lawyers have
gotten more and more heavily involved, the range of "Y2K critical" dates has
grown.  A story has made the rounds that some software uses "9999" in the
date field to indicate special processing; hence, software is now supposed
to be tested for proper operation on 9 Sep 99.  (Why operation *on that
date* should be affected is beyond me.  Then again, since a date written
with a two-digit year and no separators necessarily has to be stored in at
least a 7-digit field -- there being at least one month with a month number
larger than 9 containing at least one day with a number larger than 9 -- it's
beyond me why one would expect software to use 9999 as a flag; 9999999 is
much more likely, and completely safe.)

I recently saw proposed language that would require a vendor to certify
proper operation on about 15 dates, starting with 9 Apr 1999 and ending some
time in 2002.  One could make a rough kind of sense of many of the dates --
e.g., they tested proper leap year handling in 2000 and thereafter -- but
some of them are real head-scratchers.  The 9 Apr 1999 date is one of those.
Is it that 4 and 9 look alike, so that 9499 (or is it 4999?) might have been
used as a magic flag?  :-)

I worked with a lawyer doing Y2K requirements for a major corporation, and
convinced them not to put *any* explicit date requirements in.  Rather, the
language is all written in terms of proper operation on any dates, and with
any input date data, that will foreseeably arise in normal system operation
during the expected lifetime of the system.  Not only does this avoid
getting into silly "my list of dates is longer than yours, hence you weren't
exercising due diligence" games, but it also avoids a genuine *bug* in the
way most of these provisions have been written: They focus so closely on
dates around the year 2000 that they ignore the possibility of problems with
dates further away.  For example, a vendor could introduce windowing -
continue to store two-digit years but have 50-99 always represent 1950-1999
while 0-49 represent 2000-2049 - to easily comply with most Y2K requirements
I've seen.  That's fine if the field in question represents order dates, but
not so good if it represents dates of birth.
                                                       -- Jerry

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

Date: Tue, 22 Dec 1998 14:22:43 -0500
From: Edupage Editors <[email protected]>
Subject: Intelligent virus invades NT servers

A new computer virus that attacked 10 MCI Worldcom networks last week is
capable of spreading throughout computer networks and scrambling the
documents on those networks as it goes.  "We've never seen anything this
sophisticated in 10 years of doing this," says Network Associates' general
manager of network security.  "This is a completely new strain of virus and
the first we've seen that propagates itself with no user interaction."  The
"Remote Explorer" virus runs on Microsoft Windows NT servers and affects
common programs like Microsoft Word.  Users clicking on their Word icon
might experience a slight delay, but otherwise would be unable to detect the
presence of the virus; meanwhile, the virus is busy corrupting files and
spreading to other programs.  Microsoft officials say they're "aware of
other viruses that have the same characteristics," and Network Associates
says it has developed a Remote Explorer detector and is working on a
solution to decode the affected files.  (*Wall Street Journal*, 22 Dec 1998,
Edupage, 22 December 1998)

 [Sounds like a worm to me.  PGN]

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

Date: Wed, 16 Dec 1998 18:21:46 -0500
From: Daniel Weber <[email protected]>
Subject: Unexpected date behavior in Windows 95

I came across the following interesting behavior in Windows 95: if you use
the "Date/Time Properties" dialog box to change the month or day of month,
the system clock is actually set to that date, without the user hitting "OK"
or "Apply."

The risk is that the user is changing system properties without really being
aware of it--if the user hasn't pressed "Apply" he or she will figure that
the change hasn't occurred yet.  Although pressing "Cancel" will restore the
date, any applications that check the system clock in the meantime will read
the altered system time.

As a simple example, consider a mail reader that checks for new mail every
five minutes by comparing system times.  If it checks mail during an
interval when the clock is set forward a day and then reset, the mail reader
will not check mail again for 24 hours.

I don't know how many applications expect and rely on the system time
to be monotonically increasing.

I've been told that other Windows dialogs, besides the date/time, also
prematurely change system settings in similar ways, but I'm not sure what
implications other settings may have.

I tested this on an NT machine and on a Windows 98 machine that was said to
have the recent Y2K patch installed, and noticed the same behavior.

Dan Weber, Sandstorm Enterprises, Inc.  http://www.sandstorm.net/
1-617-547-0011  [email protected]

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

Date: Thu, 10 Dec 1998 21:33:24 -0500
From: "Frank Markus" <[email protected]>
Subject: Microsoft Trojan Horse

I am running Win98 with a Microsoft module that automatically notifies me of
"critical updates" and takes me to a Microsoft Updates web site.  The first
item on the list of updates was one that was intended to make Win98 Y2K
compliant.  This module was roughly 1.5MB.  Further down the list was a beta
IE virtual machine (presumably designed to comply with the Sun Java
decision.)  This file was roughly 4MB; I decided to pass on it.  Having
specified what I wanted to download -- and install (it is both or nothing)
-- I noticed that the download was going slowly.  And then I discovered the
reason: the file that I was downloading was over 5MB ... and included the
Virtual Machine Beta that I had not checked!  I cancelled the download and
went back to check whether I had made and error.  I had not.  I repeated the
exercise with the same result.

My conclusion is that in an effort to show 'good faith' compliance with the
Sun Java court order, Microsoft is installing the revised Java engine on the
computers of users who have decided against using it.  The cheese that they
are using to bait their trap is the promise of Y2K compliance.

Does anyone who is using Win 98 and the IE 5.0 beta know how to get only the
Y2K update?

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

Date: Wed, 9 Dec 1998 21:28:10 -0500 (EST)
From: Ben Sherman <[email protected]>
Subject: Quark XPress, hates Unix scripts!

Recently, we at 2600 Magazine published an article with a few Unix scripts
in it.

A neat feature of XPress is that it allows you to put XPress specific
formatting using plain ascii text, i.e. <i> for italics, <b> for bold and
so on.  So what do you do if you need to you the > or < symbols (in a
script for instance)?  Easy, XPress just looks for 2 > or < in a row.

So when you print something that says:

echo "root2:x:0:1:Root:/:/sbin/sh" >> /etc/passwd

it gets truncated to

echo "root2:x:0:1:Root:/:/sbin/sh" > /etc/passwd

In unix, >> appends something to a file, and > replaces the file, so any
command in a script to append something to the end of a file, would actually
ERASE the file and REPLACE it with the one thing that was supposed to be
added.

Eeek!

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

Date: Fri, 11 Dec 1998 12:29:51 -0500
From: "Alexander V. Konstantinou" <[email protected]>
Subject: Password hint risks

In the process of using the Netscape 4.5 automatic update feature I was
asked to join the Netscape Netcenter.  The form requests that you supply an
account name, password, name, electronic as well as physical address (to be
fair, you are given several options on how this information can be used).
The unusual aspect of this form, was an option to include a password hint
with the following explanation :

 "If you forget your password, Netcenter will present you this
  password hint to help jog your memory. Example hint:
  'same password as my bank acct.' "

The risks are clear : potential access to your name, address and bank PIN !

Alexander V. Konstantinou

 [Various comments received on this one.  TNX.  PGN]

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

Date: Wed, 16 Dec 1998 18:02:34 -0600
From: Flint Pellett <[email protected]>
Subject: Risks in incorrect warnings and alerts

It seems to me that more often than not, the reason a Risk rears its ugly
head is because either somebody wrote a piece of software without thinking
about what possible states exist for various variables, or (a pet peeve of
mine), somebody issued an incomplete error message, or both.  [My definition
of a "complete" error message is one that tells me not only what is wrong,
in a way I can be expected to understand, but also gives me some clue what
to do to fix it or where to go to get help.]

While the example below is a trivial Risk (I hope), it illustrates
both of the above quite well.

I just installed my copy of the 1999 version of a widely used personal
finances software package, and migrated data from a much older version
without incident.  The new version includes a new feature (new to me anyway)
to show alerts if my charge card balances are "near my credit limit."  I was
very surprised, on my first entry, to see an alert telling me that one of my
cards was near my credit limit.  I was even more confused when I examined
the account: my balance owed was $0!

I eventually figured out their default algorithm for those alerts, by
examining several other accounts.  They would take the account's credit
limit, subtract $3,000, and set the resulting value as the default upper
limit on the balance owed before an alert would be issued.  That made the
default on my gasoline company card with its $700 credit limit be negative
$2,300.  [Feel free to draw your own conclusions about the person who came
up with _that_ algorithm.]

When I found the place where you can change those defaults, the offending
account wasn't listed, so I can't fix the -2,300 value.  I suspect that
perhaps someone used a negative number in that field to decide that this
account isn't a credit card account and shouldn't be in the list.  I appear
to be stuck with this incorrect warning message until such time as the gas
company owes me more than $2,300 on the account.

As for that (scary) error message, "Account XXX is near your credit limit",
it could have almost trivially been presented to me as the following: "You
owe $0 on Account XXX, which has a $700 limit.  You will see this alert
whenever your balance exceeds $-2,300."  The first message wasted a
considerable amount of my time in having to figure out what was going on.
The second would have made it a lot easier, if not obvious, and would
certainly have generated less stress.  Millions of people use this program-
millions of minutes can get wasted when people can't figure out what is
triggering a warning.  Is that a trivial Risk?  Maybe not.

Can I conclude anything else about this incident?  Yes.  The QA people who
tested this, who apparently don't have any charge accounts with credit
limits under $3,000, are quite likely overpaid. :-)

--Flint Pellett

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

Date: Fri, 18 Dec 1998 14:43:26 -0500
From: "Ed Borodkin" <[email protected]>
Subject: CFP: 1999 National Information Systems Security Conference

The National Information Systems Security Conference (NISSC) welcomes
papers, panels, and tutorials on all topics related to information
systems security.  Our audience represents a broad range of information
security interests spanning government, industry, commercial, and
academic communities.  Papers and panel discussions typically cover:

* research and development for secure products and systems, presenting
  the latest thinking and directions;
* electronic commerce;
* legal issues such as privacy, ethics, investigations, and enforcement;
* practical solutions for government, business and industry
  information security concerns;
* network security issues and solutions;
* management activities to promote security in IT systems including
  security planning, risk management, and awareness and training;
* implementation, accreditation, and operation of secure systems in a
  government, business, or industry environment;
* international harmonization of security criteria and evaluation;
* evaluation of products, systems and solutions against trust criteria;
* tutorials on security basics and advanced issues;
* security issues dealing with rapidly changing information technologies;
* highlights from other security forums; and
* implementing policy direction.

For more details see http://csrc.nist.gov/nissc/call.htm.

 [The most important detail: the deadline
 for submissions is 15 Feb 1999.  PGN]

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

Date: 23 Sep 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 19" for volume 19]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
PostScript copy of PGN's comprehensive historical summary of one liners:
  illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.13
************************

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.