Subject: RISKS DIGEST 17.41

RISKS-LIST: Risks-Forum Digest  Tuesday 24 October 1995  Volume 17 : Issue 41

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

 Contents:
"Crimestoppers" and bank-clock coincidence (Sarah Holland)
A Curious Mac User (Mike Crawford)
"core" files (Ross Oliver)
RISKS of assuming "Flaws In Internet Security" (A. Padgett Peterson)
U.S. Army to use software to control and direct artillery fire (David Graf)
Lots of copies, but why? (Lord Wodehouse)
RISKS of believing the newspaper's twist (or shimmy) (Sidney Markowitz)
Getting your clearance on the net [Name withheld]
Guess what happened at the Pittsburgh Airport? (Alan Tignanelli)
More air-traffic control woes: Las Vegas (E.H. Emerson)
FLASH * Marketry Dumps Marketing Plan (Marc Rotenberg)
Re: Risk of not knowing [when] something goes wrong (Ken Calvert)
Re: Northwest Spit Me Out (Daniel Frankowski)
Re: How to derail a train (Leonard Erickson)
Re: The Johnson Bug (David A. Curry)
Re: Determining the health of disk drives (Martin Minow)
Re: Risks in Java and Beyond Java (Charles J. Wertz)
NSA Museum on Web (Adrian John Howard)
Minitrack on Risks in End User Computing (Ray Panko)
ABRIDGED info on RISKS (comp.risks)

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

Date: 20 Oct 95 01:37:05 EDT
From: Sarah Holland <[email protected]>
Subject: Crimestoppers and bank-clock coincidence

>From the October 18, 1995 Vancouver Sun
"Man seeks to clear his name after police error"

  A Tsawwassen whose photo was wrongly placed on a "Crimestoppers" episode
linking him to bank-machine fraud says he wants his name cleared and those
responsible to pay.  ...  Sonny Walker, 19, withdrew money from a Richmond
Savings Credit Union bank machine on Dec 25, 1994. On the same day, someone
used a stolen card at the same machine.  Because the clock in the video
camera filming bank customers indicated Walker withdrew his money at the
same time as the fraud occurred, the bank forwarded his photo to Richmond
RCMP.  But the video-camera clock was wrong. Rachael MacKenzie, manager of
public relations for Richmond Savings admitted Thursday. It was out by about
one hour.  ...  When the [Crimestoppers] episode first ran, Walker heard
about it from friends.  ...  Walker and his mother went to the police right
away. Even though he protested his innocence and insisted a mistake had been
made, Walker was interrogated for 45 minutes.  ...
  The Crimestoppers episode ran throughout the summer. Walker continued to
protest his innocence to police, but said he got nowhere.  ...  Finally, in
September, Colleen [his mother] called the bank to complain.  MacKenzie said
the call was the first she heard of the Crimestoppers episode, and she
immediately had the bank check its records.  "Within 2 or 3 days, we knew
the timing was wrong," she said. "We made a mistake on the evidence. Thee is
no question we feel horrible about this."
  MacKenzie immediately sent a letter to police notifying them of the error
and criticizing police behaviour.  "We are concerned that you passed this
photo on to Crimestoppers with no prior notice to us and that you idn't
attempt to re-contact us after your initial discussions with Sonny's
mother," MacKenzie said in her letter.  But two weeks later, Walker's sister
saw an hour-long Crimestoppers special in which her brother's face was
displayed as part of the fraud episode, with an addendum stating that the
suspect and his family deny the allegations.  ...
  Crimestoppers' police liason officer Dave Baker refused to comment except
to say there was a "screw-up, but I don't know whose."  ...

Risks? The usual dose of human stupidity, and as BC Privacy's commissioner
put it: "Our assumption is that technology can't make mistakes, but once
again we are shown it does make mistakes."

Sarah Holland  [email protected]

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

Date: 17 Oct 1995 13:29:55 -0800
From: "Mike Crawford" <[email protected]>
Subject: A Curious Mac User

This item is bouncing around Apple lately.  Apparently, the VP of Compaq
considers it too much of a RISK to make an important presentation on a PC.
Mike Crawford [email protected] http://www.scruznet.com/~crawford

>From Guy Kawasaki's MacWay mailing list... I wonder how many closet
Macintosh users are out there!

>From the "Feedback" column in this week's "New Scientist":

FEEDBACK was present when the International Data Corporation held its annual
European Information Technology Forum in Paris recently. Top executives from
top computer companies Lotus, Oracle, Hewlett-Packard, IBM and Compaq all
gave speeches. So did Bill Gates of Microsoft, who was in France to launch
Windows 95.

Needless to say all the speakers relied on electronic "slides", stored in a
computer and projected by a video system. The picture quality was fine, but
several speakers had a lot of trouble controlling the computer. Perhaps they
do not often use the equipment they sell to the public.

Whatever the reason, their slides kept refusing to change, or changed
too soon. When Andreas Barth, senior vice-president of Compaq, took the
stand he announced that he was not going to risk the same embarrassment.

So he was using an Apple Mac to show his slides.

It took a moment or two to appreciate the full significance of Barth's
remark. The vice-president of a huge company that has built its success on
selling PCs that run Windows was admitting to a top industry seminar that he
dare not use a Windows PC for his presentation, and was using the rival Mac
system instead.

Compaq's Mac presentation progressed without a hitch. But Feedback was more
than a little disappointed to see that Bill Gates had already left the hall.
So there was no chance to see the look on his face.

One is left wondering how many of the other presenters secretly identify
with Barth and, in the privacy of their own homes, use Apple Macs instead of
PCs.

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

Date: Sat, 21 Oct 1995 08:26:00 GMT
From: [email protected] (Ross Oliver)
Subject: "core" files
Newsgroups: alt.folklore.computers,alt.folklore.urban

 [Via Mark Brader <[email protected]>]

Rob J. Nauta ([email protected]) wrote:
: Anyway, there is an urban legend about a professor who wrote his thesis
: about the earth's core in a file called 'core'. In the weekend however
: a coreseeker wiped out his file. And, the clever person who wrote the
: backup script had added a filter so that core files weren't backed up ...

This was definitely not a legend at my school, UC Santa Cruz.  There are
eight "colleges" at UCSC, and each has a required course that all freshman
have to take, which supposedly makes up the "core" of the college
curriculum.  Thus, it was known as the "core course."  At the time (12 years
ago) about 50% of campus CPU cycles were used to run nroff for writing
papers (the other 50% were for playing rogue.)  Less imaginative freshman
would use "core" as the filename for their beloved papers, with occasional
unfortunate results.

Ross Oliver  [email protected]

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

Date: Thu, 19 Oct 95 19:08:54 -0400
From: [email protected] (A. Padgett Peterson)
Subject: RISKS of assuming "Flaws In Internet Security"

THERE IS NO SECURITY ON THE INTERNET (see RFC 1281 if you do not believe
me). The Internet addresses one thing and one thing only: delivering the
mail (packets).  It is solidly on the A of Availability.

Consequently, there is no "flaw" in the Internet, rather there may be a flaw
in the design of a module which makes use of the Internet, or there may be
a flaw in people's expectation of the Internet, but not the net itself, it
does its job very well.

It is probably best to think of the Internet as "the world's biggest party
line" (if that does not translate well outside the US, I apologise but have
no idea what other terms are common).

Unless the user takes steps to ensure the security of a message/file/etc.,
to authenticate that something actually came from where it appears to have,
and that it does not contain anything you might not want to receive, then
he/she/it/other has no-one to blame than themselves and certainly not the
'net (have noticed a certain tendency of the lemmings to be wont to blame
*anyone* else, mob rule/mob IQ & all that).

When I examine a virus my favourite tool is DEBUG, when reading a message
that came from "somewhere", I use Vern Buerg's LIST. Both have the endearing
quality of assuming nothing for me.

Misplaced trust is really is not a prerogative of digital usage but "to
really screw things up takes a computer."  I suspect that we are rapidly
reaching a point where we are going to have to reassess trust in objects for
which no one is accountable.

In 1969, when the first Internet connections were made, the government
relied on strong encryption not only for confidentiality but also for
accountability, strong encryption which was the responsibility of the sites.
I suspect that the Internet is rapidly returning to that paradigm.

Padgett

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

Date: Thu, 19 Oct 1995 21:12:17 -0400
From: [email protected]
Subject: U.S. Army to use software to control and direct artillery fire

On page 24 of the October 16, 1995, issue of PC Week, an article ("Mark your
target--objects in the field) describes how the U.S. Army with Magnavox
Electronic Systems is designing an AFATDS (automated field artillery
tactical data system) which can use battlefield intelligence data in
conjunction with programmed standard operating procedures to direct
artillery file onto enemy forces in a matter of seconds.

The development of an AFATDS should come as no surprise to anyone familiar
with the military.  The U.S. armed forces have historically relied upon fire
support such as artillery to reduce enemy forces and so reduce the number of
American casualties.  In addition, the military is downsizing and so has to
"do more with less".  By automating the control of artillery fire, the
military is hoping to literally get "more of a bang for the bucks".  A
well-designed functioning AFATDS has the possibility of being a critical
"force multiplier" which could deter "enemy" forces from even tangling with
U.S. forces.

However, as readers of this digest are aware, there are two main dangers
from automating such a process to the point where there is little room or
time for human control of the system.  First, there is the problem of
intentional sabotage.  I would not put it past the capabilities of an
"enlisted hacker" to spoof the AFATDS into mistaking the Officer's Club as a
concentration of enemy troops.  AFATDS could give a "fragger" the chance to
do a lot more damage than he/she could do just using a grenade or gun.

Second, there are the problems of unexpected software bugs which could
misdirect fire or even abend the entire system.  Given that the consequences
of either misdirected artillery barrages or losing artillery support
altogether could literally be a matter of life or death, it would be
interesting to find out how Magnavox plans to deal with these problems.

This is more than just a theoretical topic since it is possible that AFATDS
could be implemented as soon as next year according to the article.

Dave Graf

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

Date: Wed, 18 Oct 1995 10:47:24 -0700
From: Lord Wodehouse <[email protected]>
Subject: Lots of copies, but why?

Recently I ordered a copy of a book via *The Daily Telegraph*.  You
collected three tokens, sent a small cheque for the postage, and waited the
customary 28 days or so before the book arrived.

I came home one day to find five parcels:

1. A book, addressed to Lord Woodhouse (mispeled)
2. A book, addressed to Lord Woofhouse (a new spelling - I like this one)
3. Three books, addressed to Lord Woofhouse
4. Three books, addressed to Lord Woofhouse
5. Three books, addressed to Lord Woofhouse

A total of eleven books. We are now giving them away to friends [...], as
the thought of trying to explain to someone that eleven was ten too many and
getting them sent back was rather more than I could face at the time. The
book order numbers are the same, except the first parcel.

Of course if the mailorder computer system has done that to more than
myself, the risk is obvious. The company will go bust. I hope I don't have
their software or operations procedures anywhere near anything critical I
use.  [They are indeed in your Doghouse.  PGN]

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

Date: Fri, 20 Oct 1995 11:33:40 -0700
From: [email protected] (Sidney Markowitz)
Subject: RISKS of believing the newspaper's twist (or shimmy)

RISKS-17.40 quoted *The Boston Globe* describing a high-level executive at a
Manhattan health company accidentally e-mailing an erotic video of herself to
400 coworkers. While the story makes for interesting gossip, with the lack
of details I have to wonder if it is more of a male fantasy embodied as
urban myth. 1) Has anyone heard of such a neat video e-mail system being
commercially available and in common enough use that a "health company"
would be using it for company-wide communications? 2) If there are e-mail
systems with video capability, are they so cheap, small and convenient that
people have cameras on their laptops as well as on their office desktop
machines? 3) Even if there were such systems, has anyone devised video
compression algorithms so good that it would be practical to send video
e-mail over a modem from one's laptop in the hotel? Without some
corroboration, I think that the body of evidence does not support the story
as being the bare truth.

 -- sidney markowitz <[email protected]>

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

Date: Fri, 20 Oct 1995 10:50:54 -0700
From: [Name withheld on request]
Subject: Getting your clearance on the net

I'm going in for a top-secret clearance, and was talking to the person who's
responsible for sending off the paperwork.  She's excited: seems that you
can now submit the forms over the Internet, thus saving the need to send
stacks of paper.  You obviously don't sign the form (no digital signature
capability); at some point in the future they said I'll be asked to sign a
hardcopy.

I suggested that it made me uncomfortable to have all that personal
information being sent over a public net without any form of protection, so
they agreed to submit mine on paper.

The risks of sending any sort of confidential information over the net have
been described to death, so there's nothing new.  It just amazes me that the
U.S. government office responsible for handing out clearances could be so
unaware of the risks as to allow it.  Further, as holding a clearance is
generally something that's not supposed to be discussed except for those
with a need to know, it seems odd that they would be willing to accept the
information leading to a clearance over a public network.

P.S. For those who haven't had the pleasure of applying for a clearance,
among the information they ask for is where you've lived, worked, been
married to, travelled to; also any treatment for psychiatric conditions, use
of drugs, criminal record, organizational memberships, communist party
affiliation, etc.  So there's plenty there that some people might not want
posted on bathroom walls.

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

Date: 23 Oct 95 07:26:58 EDT
From: Alan Tignanelli <[email protected]>
Subject: Guess what happened at the Pittsburgh Airport?

That's right.  It's happened again.  That's six times in a month.  This
time, however, it happened during a visit of the National Air Traffic
Controllers Association and U.S. Rep. Frank Mascara, a member of the House
Committee on Transportation and Infrastructure.

This time the FAA blamed a three-minute commercial power failure, and said
the backup generator kicked in within 20 seconds.  During the outage,
controllers maintained radio communications.  The FAA said weather was clear
and no flights were delayed.  There were high winds in the area.  Since the
radar system was installed a year and a half ago, there have been at least
nine recorded outages.  Because of the frequency of the outages, the FAA is
considering UPS.  (A few travellers may be considering sending themselves by
UPS as well - AT).

Alan Tignanelli

  [UPS and DOWNS are not good for ATC systems, but they are OK for
  airplanes (as long as the DOWNS can be followed by more UPS).  Oh, for
  non-US readers, in Alan's context, the first UPS denotes Uninterrupted
  Power Supplies, and the second denotes United Parcel Service.  PGN]

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

Date: Fri, 20 Oct 1995 15:11:42 -0700 (PDT)
From: [email protected]
Subject: More air-traffic control woes: Las Vegas

Three-minute outage blanks approach radar at McCarran

* A union official contends equipment at Las Vegas' airport is
outdated, but an air traffic official disagrees.

by Keith Rogers, *Las Vegas Review-Journal*, 19 Oct 1995

    Three air traffic controllers who were tracking aircraft approaching
Las Vegas experienced a 3 1/2-minute radar outage Tuesday night, raising
concerns with their union that it's time for new equipment.  But Paul
Strybing, assistant air traffic manager at the Las Vegas Terminal Radar
Approach Control, said, "At the time this took place, we had five other
radar displays that continued to operate fully.  At no time was there any
loss or disorientation of traffic."
    In a statement Wednesday, Daniel Maddaus, president of the National Air
Traffic Controllers Association Local-L30, the union that represents
controllers for the Terminal Radar Approach Control, said, "This outage
lasted long enough for an average air carrier to travel about nine to 10
miles unseen by air traffic control."  The Las Vegas approach control
handles aircraft up to an altitude of 17,000 feet within a 40-mile radius of
McCarran International Airport.  "The likelihood of a midair collision
zooms," Maddaus said [...].  "You have aircraft pointed at each other with
minimal separation."
    Three of the five controllers working that shift were affected by the
outage and were able to switch to other radar screens, Maddaus said, but,
"the problem I have is the equipment is old and prone to more failures."
[...]  "The flying public pays for the most complex air traffic control
system in the world.  What they are getting is a very large bureaucracy and
1950s and '60s technology."
    Strybing said the radar system is 1970s technology "and continues to
work extremely well."  "It's an extremely reliable system that has the best
track record of any system configuration of its kind in the world.  There
are redundancies and backups."  The outage at 10:02 p.m. Tuesday to what is
called the Multiplex Display Buffer Memory lasted 3 minutes, 21 seconds and
caused three radar screens to go blank, Strybing said.  [...]

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

Date: 19 Oct 1995 17:13:56 -0400
From: "Marc Rotenberg" <[email protected]>
Subject: FLASH * Marketry Dumps Marketing Plan

Marketry [See RISKS-17.39] said this week that it was dropping plans to sell
data gather from the Internet.  While some company (anyone know who?) is still
collecting the information, Marketry president Norm Swent, announced
Marketry's "resignation as manager of the e-mail Internet Interest Selector
list."

Who says a little e-mail can't make a difference? ;->

Marc Rotenberg, EPIC  [email protected]

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

Date: Tue, 24 Oct 1995 13:22:57 -0400 (EDT)
From: [email protected] (Ken Calvert)
Subject: Re: Risk of not knowing [when] something goes wrong (Cohen, R 17.40)

>I always felt that parity checking was not enough - I want ECC memory.

Of course, if you have ECC (error-correcting) memory alone, you have the
same problem, unless you ALSO have error detection.

This is an old RISK.  For a 20-year-old warning, see E.W.Dijkstra, "On a
Warning from E.A.Hauck", EWD 525 (reprinted in "Selected Writings on
Computing", Springer-Verlag, 1982).

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

Date: Sun, 22 Oct 1995 13:07:55 -0500 (CDT)
From: Daniel Frankowski <[email protected]>
Subject: Re: Northwest Spit Me Out

In RISKS-17.26, I reported that Northwest accidentally erased me from their
records, I showed a letter I sent to the president of the company, and I
promised to keep RISKS updated.

Well, there were two interesting developments.

First, an "aide to the president" called within a couple of days, and
said that when another Daniel Frankowski sent in a change of address,
they applied it to my account instead.  Northwest rectified the error
(as far as I can tell), satisfying requests (2)-(4) of my original
letter, but did not satisfy my request for

(1) detailed information that your computer information and
   information-related problem-resolution practices are safe and
   effective

I am probably going to cave on this, because I do not have the desire
to spend the time on it.

What this experience tells me is that if a customer service rep tells
you that you are out of line (as one did me), just go yell to someone
else.  Your service does depend on the person serving you, not just
the company.  This is probably obvious to RISKS readers.

The second interesting thing that happened is that within a couple of
days of my e-mail to RISKS (long before Northwest called me) I was in
contact via e-mail with the other Daniel Frankowski.  Small electronic
world!  He is Daniel J. Frankowski, I am Daniel S. Frankowski.  As we
are both 25 and in the computer business, probably we will be crossing
wires again sometime.  He seems like a nice fellow, of course.  :-)

Dan Frankowski [email protected] http://www.winternet.com/~dfrankow

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

Date: Thu, 19 Oct 95 00:40:11 PDT
From: [email protected] (Leonard Erickson)
Subject: Re: How to derail a train

[email protected] writes:

> I was surprised to see TV news stories and front page articles giving
> instructions on how to derail a train from which bolts to remove to how to
> defeat the electronic system checks.

Actually, the information is far from secret. Any bright 13-year old with an
interest in trains could tell you how to do it. Anyone with any sense of
mechanical aptitude can just *look* at the rails and see how they go
together. The "hard" part is fooling the block signals. And that's described
in just about any article on how they work. For that matter, you can *watch*
railroad employees test crossing signals and the like by placing a set of
jumper cables between the rails.

So it's pretty obvious that both connectivity along the rails, and *between*
the rails are checked. From there, it's but a moment of thought to any of
the *many* ways of getting around them.

Leonard Erickson                   [email protected]
(aka Shadow)                        [email protected] (preferred)
FIDO:   1:105/51          [email protected]


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

Date: Thu, 19 Oct 1995 15:57:40 EST
From: "David A. Curry" <[email protected]>
Subject: Re: The Johnson Bug

    Date: Tue, 17 Oct 1995 10:32:22 -0700
    From: Tracy Pettit <[email protected]>
    Subject: Re: The Johnson Bug (RISKS-17.39)

    [....] it sounds a lot like the stories about poisonous snakes wrapped
    in imported carpets or burglary victims finding their pet Doberman
    choking on severed fingers.  I believe there have been a book or books
    published on these types of stories [....]

These stories are more properly called urban legends.  There are four
well-written books on them by Jan Harold Brunvand, a professor at (I
think) the University of Utah:

       The Choking Doberman
       The Mexican Pet
       Curses! Broiled Again!
       The Baby Train

(There are a number of other books by other authors as well, but I do
not have a list.)  They should be available at your local bookstore.

Aside from being an entertaining read, the books really show why it can
be dangerous to accept things at face value without checking the facts.
I think most people would be surprised by how many of these stories
they've heard, or even repeated as true...  I was.

--Dave

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

Date: Thu, 19 Oct 95 15:53:21 -0700
From: [email protected] (Martin Minow)
Subject: Re: Determining the health of disk drives

In RISKS-17.40, Sean Reifschneider notes that some modern disk drivers
intended for portables have extensive error management built in, and asks
"but how does it report the problems."

All SCSI devices can implement an extensive error logging command protocol
defined in the ANSI SCSI Standard (ANSI X3-131-1994), including commands to
initiate self-test sequences and commands to report errors.  Presumably, the
device's manufacturer would provide a vendor-specific utility to monitor the
device. In the Macintosh community, there are several very competent
third-party disk driver vendors who are certainly technically capable of
writing this utility.

My experience, however, is that modern SCSI disks are extremely reliable,
and there isn't much cost/benefit in doing this: remember, the personal
computer user community does not -- and should and should not -- need to
know about technical details within their computer systems. Here, a
comparison with modern computer-infested automobile control systems seems
relevant: how often do you want to examine the engine logs?

Martin Minow  [email protected]

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

Date: Thu, 19 Oct 1995 19:00:35 -0500 (EST)
From: "Charles J. Wertz" <[email protected]>
Subject: Re: Risks in Java and Beyond Java (Riddle, RISKS-17.39)

I read Prentiss Riddle's comments on the risks of Java with considerable
interest. This seems to me to be one example of a larger problem that seems
worthy of considerable discussion in Risks. The Microsoft Word viruses that
have come to light recently provide another example. (Simply stated, a Word
document can contain a "macro" that executes when the document is opened.
Someone finally realized that this macro can do something nasty to the
unsuspecting recipient of the document.)

The more general concept that many folks are propounding is that we will
regularly exchange "objects" containing both data and code by mechanisms
such the World Wide Web and various kinds of object request brokers. The
broader supposition seems to be that the concepts of applications and data
files as we know them will disappear.

I've been viewing this with growing alarm for some time. It seems to me that
if all this does happen, it will be possible to turn all sorts of nasty
things loose. It also seems that scanning for nasties is not going to be
able to catch them. Monitoring various kinds of system calls might have a
better chance but this seems inadequate as well as cumbersome.

Am I missing something? Does anyone have some good solutions?

Charlie Wertz

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

Date: Fri, 20 Oct 1995 14:48:13 +0100 (BST)
From: "Adrian John Howard" <[email protected]>
Subject: NSA Museum on Web

Risks readers might be interested in knowing that the NSA National
Cryptological Museum now has a web page at:

   <http://www.nsa.gov:8080/museum/>

It includes a brief tour with pictures of some of the exhibits.

Adrian   [email protected]
+44 (0)1273 678367 http://www.cogs.susx.ac.uk/users/adrianh/

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

Date:   Mon, 23 Oct 1995 15:11:44 -1000
From: "Ray Panko" <[email protected]>
Subject: Minitrack on Risks in End User Computing

There will be a six-paper minitrack on Risks in End User Computing at the
Twenty-Ninth Hawaii International Conference on System Sciences in January,
1996.  Most of the papers will focus on spreadsheet risks and spreadsheet
errors.

Three of the papers are available online.  If you are interested, please use
the following URL.

    http://www.cba.hawaii.edu/panko/h6reuc.htm

You can also access these papers through links in my home page, which is
listed below.

The papers add to past findings.  Wherever quantitative errors have been
studied in spreadsheeting, they have been found in disturbingly high
numbers.  Galletta et al.'s paper extends this to the debugging phase.  In
addition, controls on spreadsheeting and end user computing are at best
informal.

Aloha, Ray

World Wide Web: http://www.cba.hawaii.edu/panko

Prof. Raymond R. Panko, Decision Sci., Coll. of Business Admin., U of Hawaii
2404 Maile Way, Honolulu, HI 96822  (808) 956-5049  Fax: (808) 956-9889

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

Date: 6 September 1995 (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) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
  INFO     [for further information]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.  [...]
[Back issues are in the subdirectory corresponding to the volume number.]
  Individual issues can be accessed using a URL of the form
    http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
    ftp://unix.sri.com/risks  [if your browser accepts URLs.]

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

End of RISKS-FORUM Digest 17.41
************************

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.