precedence: bulk
Subject: Risks Digest 19.93

RISKS-LIST: Risks-Forum Digest  Tuesday 25 August 1998  Volume 19 : Issue 93

  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.93.html and at
ftp.sri.com/risks/ .

 Contents:
Computer crashes cripple Northeast air traffic control (Keith Rhodes)
Embassies are victims of Y2K problems (Henry G. Baker)
Computer-controlled roller coasters (Martin Minow)
How not to get a date (Mark Brader)
Car thieves and bad design (Phil Agre)
Small credit unions targeted for debit-card fraud (D. Scott Lucero)
FLIR for Cadillacs (Steve Holzworth)
Clothing privacy risk due to tech misuse (Scot E. Wilcoxon)
ATM prototype using Sensar's iris identification (Derek Ziglar)
Galaxy IV revisited (PGN)
Re: Titan IV explodes with Vortex satellite explodes (Capt Stephen Judkins)
Re: Amsterdam Airport down (Roalt Aalmoes)
Citibank on-line banking service (Steven Wertheimer)
AT&T and snails (Bob Frankston)
Re: USS Yorktown: WinNT --not?-- the fault (Dave Kristol)
"Deep Crack" John Gilmore on PRIVACY Forum Radio (Lauren Weinstein)
Re: The bloatware debate (John Mainwaring)
Re: Software flaw exposes e-mail programs ... (Richard M. Smith)
The risks of namespace confusion in the consumer mind (Andrew Shieh)
RISKS of multilanguage environments (Lloyd Wood)
Newest version of the Deception ToolKit (Fred Cohen)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 24 Aug 1998 07:20:39 -0500
From: [email protected] (Keith Rhodes)
Subject: Computer crashes cripple Northeast air traffic control

The Northeast Air Traffic Control Center in Nashua, New Hampshire, reverted
to the old voice-and-paper-slip backup system for 37 minutes on 19 Aug 1998,
because of a computer failure.  350 planes were being handled at the time.
The system also failed again the next day.  Over 100 system failures have
been reported already this year at that center.  William Johannes, president
of the National Air Traffic Controller's Association, said, "It's like a
Chevy with 485,000 miles on it and you are trying to stretch it.  The longer
it goes, the more time were are going to have failures."  The mainframes
("aging equipment") are supposed to be replaced beginning in 1999, with a
new display system expected in 2000.  [Source: David Tirrell-Wysocki,
Computer crash cripples New Hampshire air traffic controllers, Associated
Press, 21 Aug 1998; PGN Abstracting]

 [Do you think the Y2K impact on the
 ATC system will last only 37 minutes?]

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

Date: Fri, 14 Aug 1998 08:16:18 -0700 (PDT)
From: "Henry G. Baker" <[email protected]>
Subject: Embassies are victims of Y2K problems

I heard on the TV news today (CNN?) that one of the reasons why the security
at the recently bombed embassies could not be upgraded last year was that
the budget was too tight.  One of the largest single budget items: upgrading
the embassy telephone (PBX) systems to solve their Y2K problems.

Oh, and by the way, no one had bothered to put in the videotape to record
from the video camera that apparently saw the whole sequence of events
leading up to the blast.  In an era when a VCR costs less than a single
phone call to Tanzania, when every 7-11 rolls tape continuously (to the
chagrin of its bored/frisky clerks), where the streets of Detroit,
Washington, DC, and probably every other major city are multiply monitored,
the idea that a U.S. embassy isn't under constant surveillance is
unbelievable.

Henry Baker www/ftp directory
URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html

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

Date: Thu, 20 Aug 1998 11:13:37 -0700
From: Martin Minow <[email protected]>
Subject: Computer-controlled roller coasters

*The New York Times* Web page has an interesting article on the way
computers (actually "programmable logic controllers") are used to manage
roller coaster rides.
<http://www.nytimes.com/library/tech/98/08/circuits/articles/20roll.html>

``Removing the human element from nearly all aspects of roller coaster
operations is no accident,'' said Walt Davis, vice president of Togo
International, a roller coaster manufacturer in Cincinnati. Automation is
more reliable than part-time amusement park workers, who may be faced with
disturbances in the station, he said.

``We try to make the control systems as idiot-proof as possible,'' Davis
said. ``Suppose an unruly kid distracted the operators and his friend came
over and started pushing buttons. We don't want to give them the flexibility
of changing things.''

Martin Minow, [email protected]

ps: While on vacation in England, I rode on a "steam yacht" -- a 100
year-old steam powered amusement park ride that was every bit as
frightening as anything in an amusement park. It was hand-controlled.

 [Newer RISKS readers need to be alerted to previous roller coaster problems
    Timber Wolf (RISKS-9.96)
    Dorney Park Hercules (RISKS-14.83[our only issue out of order!],82,85)
    Blackpool's Pleasure Beach (RISKS-16.22,23)
 and a wonderful spinmeister in RISKS-10.18 (``If people knew how
 safe they are, they would lose a lot of their thrill.'')  PGN]

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

Date: Wed, 19 Aug 98 02:25:01 EDT
From: Mark Brader <[email protected]>
Subject: How not to get a date

A short item in the 10 Aug 1998 issue of *Newsweek* tells of a TV commercial
featuring one Scot Armstrong, who says he doesn't have a date for his high
school reunion and gives an e-mail address.  However, "he chickened out
during filming of the ad and gave a random address he assumed would be
bogus."  At press time the actual owner of that address had received more
than 1,500 responses, mostly from prospective dates for Scot, while Scot
still had no date.

Mark Brader <[email protected]>

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

Date: Tue, 18 Aug 1998 17:21:32 -0700 (PDT)
From: Phil Agre <[email protected]>
Subject: Car thieves and bad design

The *LA Weekly* last week included a 1600-word article discussing the
lifestyles and electronics of modern car thieves:

 Eddie Little, Chop shop guys, LA Weekly, 7 August 1998, page 13.

It's online at:

 http://www.laweekly.com/ink/archives/98/37news3-080798-little.shtml

Here are the pertinent passages:

 Vlad ... emerges with a handheld device that looks like a large
 walkie-talkie.  This is actually a large custom alarm decoder that
 would cost you close to five grand if you knew the guy who makes
 them.  Vlad flips a switch and within minutes the Toyota's alarm
 chirps and the doors unlock.  Vlad just loves those car alarms that
 also automatically unlock the doors.  ... From that point it takes
 less than a minute to slap-hammer the ignition and get rolling.

 This baby was hand-assembled in one of the old Eastern Bloc nations.
 [It] will send out hundreds of signals until it hits the right numbers.

I don't know why, but I am continually amazed at how unsecure so many
digital systems are.  Assuming that the *LA Weekly* reporter wasn't just
blowing smoke, are the people at Toyota really unaware of the incentive
they're creating to build a device that simply runs through all of the codes
that the key might be sending to the remote unlocking mechanism?  This is,
obviously, a *trivial* problem to fix.  It seems incredible, but I myself
have read specs for several other systems for exchanging wireless data with
automobiles that were even less immune to spoofing and other attacks that
can be straightforwardly conducted in public places.

What most annoys me is not the economic loss -- you have to figure that
insurance companies will push the necessary economic incentives back through
the system eventually -- but the space that bad design opens up for
paranoia.  Normal people nowadays have to read one headline after another
about the hackers in Finland or somewhere who have discovered some gaping
security hole in expensive, complicated devices that they increasingly
depend on to run their lives.  Then, often, they have to read smaller
headlines the next day saying that the security hole has been patched if you
download such-and-such fragment of code, or that bogus patches are floating
around that will erase your hard drive, or that the problem wasn't quite
real after all, or that reading an e-mail message really can erase your hard
drive, or maybe it can't, and so on.  Who needs "The X-Files"?

Phil Agre

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

Date: Wed, 19 Aug 1998 14:06:07 -0400
From: "D. Scott Lucero" <[email protected]>
Subject: Small credit unions targeted for debit-card fraud

Small Credit Unions Targeted for Debit Card Fraud.  The 14 August 1998
Washington Post reports that thieves used sophisticated computer programs to
guess debit card numbers of members of the Transportation Federal Credit
Union, running up $1 million (U.S.) in charges.  According to a vice
president for the credit union insurer investigating the case, these
programs analyze sample credit card numbers to determine the relationship
between the card's digits and generate numbers that are valid about half of
the time.  An organized crime group in Asia appears to have targeted several
small credit unions, which do not have the staffs and budgets to protect
their accounts like larger institutions.  As a security measure, debit cards
have encrypted codes on their magnetic strips; however, the processing
system at the Transportation Federal Credit Union which checks these codes
was not working.  This system has a date when to start processing the codes
but this date was mistakenly set in the future.  Apparently this has been
corrected since members were told that they will be keeping their same debit
card numbers.  A RISK that long time readers are familiar with - small
automation oversights having large consequences.

Scott Lucero

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

Date: Thu, 20 Aug 1998 19:49:42 -0400
From: Steve Holzworth <[email protected]>
Subject: FLIR for Cadillacs

Night vision for your Cadillac:

Excerpted from Nando.net:

"WASHINGTON (August 20, 1998 00:18 a.m. EDT http://www.nandotimes.com) --
You're driving at night, and a deer jumps in front of the car. No problem:
You braked in time.  Seconds earlier, you had glanced at a TV-like screen at
the bottom of your windshield that let you "see" a distance up to five times
beyond your headlights.

This is not science fiction but the latest high-tech gizmo for an
automobile, being introduced formally by General Motors Corp. at a Thursday
press conference. GM will offer the so-called "night-vision" system as an
option on its DeVille Cadillacs starting with the 2000 model year."

original article: http://www.nando.com/newsroom/ntn/biz/082098/biz2_5118.html

The article goes on to describe a 4x10 black and white display that projects
the infrared image on the "lower part of the driver's windshield", enabling
you to see up to 500 yards at night. I wonder how often you have to clean
the IR pickup, said to be mounted in the grill? What about flare from
oncoming vehicles? On top of car computers, stereos-from-hell, cellular
phones, radar detectors, etc., do we really need another gadget to distract
the driver from paying attention to plain old driving?

On a lighter note:

I don't live there, but I seem to remember that California made it illegal
for "civilians" to have or operate night-vision gear. If I drive a
so-equipped Caddy into CA, am I busted? :-)

Steve Holzworth, Senior Systems Developer, SAS Institute - Open Systems R&D
VMS/MAC/UNIX Cary, N.C.  [email protected]

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

Date: Wed, 12 Aug 1998 10:05:57 -0500 (CDT)
From: [email protected]
Subject: Clothing privacy risk due to tech misuse

Some versions of a consumer video camera have infrared technology which can
almost look through clothes.  The technology was included for night time
uses such as filming nocturnal animals or your children sleeping.  Using the
camera in daylight can show underwear of someone who is lightly dressed or
make "people wearing swimsuits look almost naked."  Sony altered the camera
so the version now in stores only uses infrared in the dark.

If you're familiar with infrared you recognize that what would actually be
shown is the heat given off by the bodies rather than the actual colors and
details carried by visible light which the clothing blocks.  I suspect
whether heat-scattering clothing will become a fashion feature or not will
depend upon popular media coverage and popular opinion.

Scot E. Wilcoxon        [email protected]

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

Date: Fri, 21 Aug 1998 10:27:13 -0400
From: "Derek Ziglar" <[email protected]>
Subject: ATM prototype using Sensar's iris identification

Another lovely RISKS-laden story. Using iris identification in ATMs.

Naturally, you will have all the biometric identification issues:
* Finite amount of irreplaceable keys. Maximum of two eyes per person means
 you have to use the same key with every business you deal with.
* Key cannot be replaced if the biometric code is compromised.
* What about people with missing or otherwise impaired eyes?

Now with the added fun of this means for banks:
* New ability to compare biometric information to connect previously
 unrelated (meaning private) accounts and activities.
* Since this won't replace ATM cards (since not all banks will have this
 technology) it merely adds a step on some ATMs. Criminals will simply
 take your stolen or forged card to a non-biometric equipped ATM.

http://nt.excite.com/news/pr/980820/nj-sensar-iris-scan

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

Date: Fri, 21 Aug 98 9:13:51 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Galaxy IV revisited

We have previously discussed the loss of the Hughes HS-601 Galaxy IV
satellite (RISKS-19.75-78,84-85).  The primary processor failed because of a
problem in the main processor's power supply, and the backup system also
failed.  Three months later, the reason for the primary failure remains
unknown, whereas the failure of the backup system has been attributed to ``a
rare buildup of crystals in a switch designed to control the flow of
electricity to the processor.''  The failure mode has been duplicated by
Hughes Space and Communications Co. in tests on the ground, and is believed
to have been the cause of the other processor failures noted in RISKS-19.85.
This problem affects only the HS-601 systems.  [Source:*Space News*, vol 9,
no 32, 17-23 Aug 1998, courtesy of Keith Rhodes]

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

Date: Fri, 14 Aug 1998 09:46:23 -0500
From: Judkins Stephen Capt 82AMDS/SGPB <[email protected]>
Subject: Re: Titan IV explodes with Vortex satellite explodes (RISKS-19.91)

The Titan IV that was lost recently (RISKS-19.91) *was* only the second one
lost.  In April 1991, it was a newly designed solid rocket motor that blew
up on a test stand (RISKS-12.09). (The Titan IV uses two of these motors.)
This motor used larger segments and therefore had fewer joints.  I believe
it was also designed for more thrust.  Yes, the computer models did not
predict the build-up of pressure that led to the explosion.  That is why
testing is critical.

Actually I think the explosion is a great success as far as risks are
concerned.  Instead of just relying upon what the computer said, the Air
Force had its contractors do a full-scale test.  The test revealed a design
flaw, and the loss of a launch vehicle and payload was prevented.  Also
because the Air Force and its contractors took proper precautions, no one
was even slightly injured.  By the way, the flaw was corrected, and the next
five test firings were successful.

Please do not oversimplfy the process and imply that the explosion was
easily preventable.  Was there an error of relying too much upon technology?
Or was the 1991 explosion the result of a thorough testing process that
relied upon different methods to work as checks and balances?

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

Date: Fri, 14 Aug 1998 08:58:03 +0200
From: "aalmoes r." <[email protected]>
Subject: Re: Amsterdam Airport down (RISKS-19.85)

RISKS-19.85 reported on a failure of the new triple-A air-traffic control
system of Amsterdam Airport Schiphol. The failure was an out-of-range value
entered by an air-traffic controller. Immediate restarts did not seem to
work as the value was still in the system.

Countermeasures have been taken. Whether this is changing
the software or educating the controllers not to enter
out-of-range values is unknown to me :-)

Roalt Aalmoes, Software Engineer  [email protected]

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

Date: 20 Aug 98 10:27:06 -0700
From: "SWERTHEI.US.ORACLE.COM" <[email protected]>
Subject: Citibank on-line banking service

I have a Citibank credit card, and thought I might sign up for their new
on-line Direct Access service to check balances, etc.  I found the following
phrase in their user agreement:

 "we will not be responsible for your losses if ... you knew there was a
 technical malfunction in Direct Access and you used it anyway"

The risk here is offloading the responsibility for determining the existence
of a "technical malfunction" to (often) very non-technical people.

Steven Wertheimer, principal technical staff      [email protected]
Oracle Data Server Applied Technologies  (650) 506-2741

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

Date: Fri, 21 Aug 1998 10:21 -0400
From: [email protected]
Subject: AT&T and snails

Using Quicken I sent a payment to my ATT wireless account. A few weeks later
they started dunning me though the payment was clearly listed and processed.
But it hadn't cleared. After a while I looked at the payee record and
noticed it was queued for electronic payment. But that confuses ATT wireless
which claims to not accept electronic payments. So I try again but notice
that my paper payment is coerced into an electronic payment automatically. I
finally figure out that if, instead of paying "ATT Wireless Services", I add
a {} comment to the end, it remains a paper payment. At least on my side.

I figured this out when one of the ATT billing people called me on the
phone.  She said she would note that the payment is on the way. Just got
another call from someone at ATT wireless demanding payment. Of course,
nothing in my record and once again told me that ATT doesn't handle accept
electronic payments and that everyone places a check on the back of a snail
(OK, snailmail might not be a fair term but it seems most appropriate or, at
least, colorful here). Of course, this is nonsense considering the
demographics of the PCS early adopters.

Maybe I shouldn't be surprised since this is the same company that has been
sending me a monthly bill for a $.15 credit on an old home office line for
over a year.

My real puzzle is why ATT doesn't seem to have a clue that it is their fault
that the payment is coerced to an electronic payment and that someone should
attempt to solve it. The larger issue is that whether a problem is caused by
new technologies or more traditional problems, I'm struck by the lack of an
attitude that problems are there to be solved instead of simply suffered. It
is a reaction consistent with dealing with any bureaucracy but for those of
(some of) us reading this list they are teething problems which need
attention.

 [Although this is otherwise a contribution that RISKS does not usually
 include, even though it represents an all-to-common problem, we have
 included it here in the public-service mode of trying to inspire
 companies to get moving in the right direction.  PGN]

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

Date: Fri, 21 Aug 1998 17:23:51 -0400 (EDT)
From: Dave Kristol <[email protected]>
Subject: Re: USS Yorktown: WinNT --not?-- the fault (Fraser, RISKS-19.90)

"Mike Williams" <[email protected]> says (in Risks Digest 19.92)

       However, for a full release you would either mask the exceptions to
       prevent the crash, or install an exception handler for each exception
       not masked.

The idea of suppressing the exceptions brings to mind this quote:

       Removing the error messages "now that the program is working"
       is like wearing a parachute on the ground, but taking if off
       once you're in the air.
       -- Kernighan & Plauger [Software Tools]

Dave Kristol
P.S.  Will Risks Digest survive after 19.99?
 [There is no technological reason for it not to!  PGN]

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

Date: Wed, 19 Aug 98 11:57:32 PDT
From: Lauren Weinstein <[email protected]>
Subject: "Deep Crack" John Gilmore on PRIVACY Forum Radio

I'm very pleased to announce that a recent audio interview I conducted with
John Gilmore [See RISKS-19.87.  PGN] is now available via PRIVACY Forum
Radio.  John is co-founder of the Electronic Frontier Foundation (EFF) and
leader of the EFF team that built the "Deep Crack" computer, that has solved
a DES-encrypted message in less than three days.  John is a widely known and
frank advocate of strong, non-escrowed encryption systems.

In this half hour interview we discuss the Deep Crack project and the
various pros and cons regarding encryption accessibility, ranging from
technical to more philosophical issues.

This is a very important topic and an interview you definitely won't want to
miss--I think you'll find it very interesting.

To hear the interview over the net via streaming audio, please visit
PRIVACY Forum Radio via:

       http://www.vortex.com/pfr

Lauren Weinstein, Moderator, PRIVACY Forum, Host, PRIVACY Forum Radio
http://www.vortex.com

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

Date: 19 Aug 1998 18:13 EDT
From: "John Mainwaring" <[email protected]>
Subject: Re: The bloatware debate

The posting from Edupage quotes Jeffrey Tarter as saying: "I can't think
of a single lite version of any product that has ever succeeded.  It may
be inelegant and sluglike, but bloatware sells."

Probably that's because lite versions usually heavily trim the 13% often
used and 7% always used features of the full version.  If they didn't, why
wold anyone buy the full version?  I suspect that the reason lite versions
exist is to sucker people into upgrading to the full version, not to give
them a reasonable way to avoid bloatware.

There must be a few of you out there who remember that the automobile
industry in the US said the same thing about large cars until a breed of
small imports with a full set of features arrived on the scene -- and even
then, it took a significant market discontinuity (the oil embargo) to really
tip the balance.  It took several years for the big three to realize that
they couldn't stem the tide by pushing feature-free sub compacts.  Since
MIPS and disk space are cheap at the moment (like gas was until 1973, and is
again at the moment) I wouldn't expect any real market resistance to
bloatware.  After all, trade in gas guzzlers is brisk again at the moment
too.  I wonder what sort of discontinuity might affect the continued
tolerance of bloatware?

John Mainwaring  Nortel RTP NC  [email protected]

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

Date: Fri, 14 Aug 1998 00:28:15 -0500
From: "Richard M. Smith" <[email protected]>
Subject: Re: Software flaw exposes e-mail programs ... (Gong, RISKS-19.91)

>But by lumping everything together and then calling it "Java applets or
>scripts", the announcement is grossly misleading [...]

People get Java and JavaScript confused all of the time.  Too bad Netscape
didn't stick with the original LiveScript name.  Then maybe Java wouldn't
have had its name dragged through the mud by Qualcomm.

On the other hand, JavaScript is getting its name tarnished by the recently
discovered Java bug in the Netscape JVM found by the folks at Princeton.
This bug allows a Java applet to get read/write access to a user's hard
drive.  What most people don't realize is that this security hole is the
worse e-mail security hole found so far.  This technique can easily be
exploited in an HTML e-mail message that loads the hostile Java applet from a
Web server.  This means that Java applet will be executed when an e-mail
message is read.  Yikes!

Does anyone else consider it less than safe that HTML-based e-mail messages
now automatically execute JavaScript programs, Java applets, and ActiveX
controls?  Even worse, none of the e-mail readers have decent methods of
turning this "feature" off?

Richard M. Smith, Phar Lap Software, Inc.

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

Date: Fri, 14 Aug 1998 01:04:51 -0600
From: [email protected] (Andrew Shieh)
Subject: The risks of namespace confusion in the consumer mind (Gong, R-19.91)

> [...] grossly misleading, creating unnecessary confusion [...]

Does the creation of confusion start at home?

It didn't help that Sun allowed Netscape to call its unrelated scripting
language "JavaScript". I hear many complaints from users about various
problems/annoyances caused by JavaScript, except people are always referring
to it as "Java", since the names are obviously similar, and the average user
does not make the distinction. The security holes found in some
implementations of JavaScript certainly have not helped Java's reputation
either.

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

Date: Mon, 24 Aug 1998 11:47:00 +0100 (BST)
From: Lloyd Wood <[email protected]>
Subject: RISKS of multilanguage environments

Sometimes, choosing a 'safe' password that is unlikely to be guessed
comes with its own risks - below.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/>PGP<[email protected]>

>---------- Forwarded message ----------
>Date: Sun, 23 Aug 1998 21:51:10 -0400
>From: [email protected]
>Subject: Unclear on the concept. Part II.

To: [email protected]
Forwarded-by: [email protected] (Vadim A. Borshchev)

This is an article from "Technical Product Information CD"
by "or Industrial Computers GmbH".

Support Note

Supervisor Password AWARD Power BIOS
Keywords: Password, CMOS Setup, BIOS

Related Software: AWARD Power BIOS

If a user isn't able to access the CMOS setup due to a mistake
related to the password he can either use the "insert key method"
at power up or use the hard coded supervisor password.

The password is: q_l27&z
On a german keyboard the user has to type: q?l27/y
since there is no keyboard translation active at the
time the password has to be entered.
(!!!Attention 'l' is not a 'one' but the letter 'l')
This password is valid for all or BIOS versions based on the AWARD POWER BIOS.

 ["Keyboard not detected, press F1."  BIOS]

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

Date: Thu, 20 Aug 1998 10:57:11 -0700 (PDT)
From: Fred Cohen <[email protected]>
Subject: Newest version of the Deception ToolKit (Re: RISKS-19.62)

The new and improved version 0.3 of the Deception ToolKit is now online at:
               http://all.net/dtk/dtk.html

Improvements include:

- Remote access to deception logs for network-based collection and analysis
 of logfiles and 'enterprise-wide' deceptions.

- Database format (comma separated quoted fields) log files for integration
 into existing intrusion databases and analysis of network-wide attacks.

- A new test-version of flexible response - currently permitting rudimentary
 analysis of intrusions and ranking of intruder progress.

There is also a new "DTK" mailing list at all.net to allow those who
regularly exchange information related to DTK to have a common forum for
discussion. This is a fully moderated list available via e-mail to
[email protected] or [email protected]

FC

Fred Cohen & Associates: http://all.net - [email protected] - tel/fax:925-454-0171

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

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

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.