Subject: RISKS DIGEST 16.94
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Tuesday 21 March 1995  Volume 16 : Issue 94

  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:
Deutsche Bahnfires continue (Debora Weber-Wulff)
Canadian Government Almost Spreads Virus (Colin Perkel)
Too high-tech... (Bob Wilson)
Reevaluating Our Trust in Computers (Cynthia P. Klumpp)
Internet: Threat or menace? (Eric Raymond)
Re: Latent risks of cost-benefit analysis (Steve Smith, David Chase)
Re: The Prodigious Manchurian (Rob Slade, Bear Giles)
Re: First "Bank" of Internet (Steve Holzworth, Rob Slade, Willie Smith)
Information Security Tutorials (Sushil Jajodia)
AMAST'95 Preliminary Programme available (Pippo Scollo)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Tue, 21 Mar 1995 12:08:28 +0100
From: [email protected] (Debora Weber-Wulff)
Subject: Deutsche Bahnfires continue

  [This is in response to a query from me to DWW on this subject.
  Thanks to Debora for sharing with us what she knows.  PGN]

The Deutsche Bahn AG, the German train company, has been working round the
clock for a long time to a) electrify the state of Schleswig-Holstein, which
is just north of the city-state Hamburg, and b) to install a full
computerized train regulation system. The big traintable change is scheduled
for next Sunday (March 26), when the daylight time change takes effect, I
believe.  They went on-line with the regulation system last week and all
h*** broke loose.  It was okay for the first few hours, and then suddenly
went berserk.  I don't have all the details, as I have only listened to
radio news the past few days, but they ended up having to route all traffic
around this major switching point. The train station in Hamburg Altona,
where the diesel locomotives are removed and electric ones put on for
continuing trains, or where most people just have to change trains, was put
out of service. People had to take the S-Bahn or a bus to the main train
station, and ended up missing connections.  (And then we have the problem
with the local trains being fuller than Indian trains because of a special
super-cheap deal on weekends, but that's another and computer-unrelated
story.)

I do not know for certain if Siemens is the main manufacturer, but I suspect
that it is them together with AEG. They just founded a company together with
ABB in Sweden to combine all their rail knowledge. Yes, they subcontract out
a lot, some to a little company in Kiel, a bunch to Third-World company (but
this is just rumor). How could this pass the testing phase? Well, this is
not the first time Siemens has boo-booed (remember the microphone system in
the Bundestag? There have been many others). My personal opinion is that
Siemens/Sietec does not have control of their Quality Assurance and there
are too many programmers there that believe that they can do no wrong, and
bosses who believe them, because it costs too much to actually do massive
testing. German programmers tend to take it as a personal insult when a
fault is detected in code that they have written. Companies like
Siemens/Sietec exacerbate the situation. I repeat, this is my personal
opinion based on unscientific surveys conducted during drinking and card
playing sessions.... so nothing eminently quotable.

There should be an article in Computerwoche (German language) soon about it
when the CeBit smoke clears, they enjoy reporting about Siemens/Sietec
disasters. I'll keep an eye out for more details.

Debora Weber-Wulff  [email protected]

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

Date: Tue, 21 Mar 1995 17:46:09 -0500
From: [email protected] (Colin Perkel)
Subject: Canadian Government Almost Spreads Virus

  The Canadian government's first attempt at electronic distribution of its
budget last month could have created havoc -- but not because of the
measures it contains.  A virus was discovered about an hour before more than
5,000 disks containing budget information were to be sent to the country's
major financial institutions.  One expert is quoted as saying the situation
could have been catastrophic for banks etc.

  The RCMP are investigating how the unnamed virus (said to be boot-sector
or FAT destructive) had found its way onto the master disk being used to
make copies. The master had passed two Revenue Canada virus scans but a last
minute check by the company hired to do the copying and distribution turned
up the critter.

  Given the super secrecy and security surrounding the budget, there are
serious questions as to how this could have happened. The RISKS involved in
the federal government spreading viruses are obvious!

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

Date: Tue, 21 Mar 95 09:23:21 CST
From: Bob Wilson <[email protected]>
Subject: Too high-tech...

I just heard on the radio an announcement of a new safety project for
farmers. Farming is one of the most hazardous occupations, by usual
measures, with a significant number of injuries and fatalities happening
when farmers get off of a tractor or similar piece of equipment to do a
brief task like untangling something, but leave the equipment running. The
proposed fix? Use the GPS satellite location system, which will be used by a
piece of equipment worn by the farmer and another on the tractor: When they
move apart, the tractor gets turned off.

I suspect "the risks are obvious", as well as the availability of MUCH
simpler technologies to do the distance sensing if in fact that is a good
thing to do....

Bob Wilson  [email protected]

  [This sounds almost as far-fetched as the completely computerized
  SUNDIAL I conjured up for an editorial in the ACM Software Engineering
  Notes many years ago, as an example of technological overkill.
  Ultimately, the sundial would have used GPS to provide automatic dynamic
  seasonal corrections dependent on longitude and latitude, would track
  its own movement (no pun intended), and would work at night by simulated
  sunlight.  PGN]

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


Date: Mon, 20 Mar 1995 20:21:24 -0400 (EDT)
From: "[email protected]"@vaxc.hofstra.edu
Subject: Reevaluating Our Trust in Computers

Computers have, in most cases, improved the overall quality of life for us.
When a computer process goes smoothly we are amazed at the speed and
accuracy of the machine.  But when something goes wrong, it is human nature
to want to place the blame upon someone or something.  When the problem is
minor we can usually laugh it off or write it off as a "computer error",
whether or not this is actually true.  But, when the problem has caused
severe (life-threatening) consequences we need in depth explanations of
accountability.

Also, the number of people affected by computer errors can range from one
person who is directly involved in the use of the computer - to many people
who are innocent bystanders.  If the operator is the only one inconvenienced
by a computer error assuming it created a minor problem, blame can be
shrugged off.  While at the other extreme, if large numbers of people are
affected by the error, blame is sought.

Therefore, there are two determining factors which cause us to want to place
blame for the occurrence of computer errors.  One factor is the severity of
the problem and the other one is the number of people affected.

With the increasing involvement of computers in our daily lives the number
of errors occurring is also increasing.  Errors seen many times in the past
are still occurring while new errors are cropping up with the use of new
technology.  The dependent relationships between the software, hardware,
data input (whether it is by a person or computer generated), procedures,
and the communication links [risks-9.61], create a very complex environment.
The blind trust we have in computers and the people who operate or program
them may need to be reevaluated.  In other words, can and should we always
trust a computer operator or a computer with the ever increasing processing
of data which affect our lives and then look to blame when failure occurs?
Or should we decrease or adjust the trust we place on data input and
computers?

While I was doing a search for articles at the library on the periodical
database and happen to be short of time one night, the computer froze
suddenly for no apparent reason.  I had already spent 30 of my precious 90
minutes reading abstracts and marking (to print) the ones I thought were
relevant.  I had not yet printed the abstracts when the computer stopped
responding to keystrokes.  I asked the reference librarian if there was
anything that could be done.  He said "Not usually, but try [Ctrl] Z or
[Ctrl] [Enter]."  I did - but nothing happened.  He shrugged.  I shrugged
and laughed, then moved over to another machine to start my work all over
again...how fitting.  I would not have enough time to make copies of the
articles I searched for and would have to return another day.

I probably should not have trusted the computer to get me smoothly through
my work that night; I left no time for computer error expecting the computer
to be 100% reliable.

Cynthia P. Klumpp  [email protected]

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

Date: 21 Mar 1995 15:24:55 GMT
From: [email protected] (Eric Raymond)
Subject: Internet: Threat or menace? (Mills, RISKS-16.93)

In a recent comp.risks post, Dick Mills speculates that the stability of
civilization up to now may have depended on the ineffectiveness of
one-to-many communication, and that the Internet condemns us to drown in
memetic garbage generated by kooks, fanatics, and evangelists.

I suggest Mr. Mills think of it as evolution in action.  The people -- and
civilizations -- that survive will be those who learn and teach critical
reading and thinking skills.  This is strictly analogous to the selection
effect of biological plagues.

<a href="http://www.thyrsus.com/~esr/home.html>Eric S. Raymond</a>

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

Date: 21 Mar 1995 14:32:28 -0500
From: [email protected] (Steve Smith)
Subject: Re: Latent risks of cost-benefit analysis (Smith, RISKS-16.93)

The risks of cost-benefit analysis that I see are more direct.  First, in
order to do a cost-benefit analysis, you have to make assumptions about
relative values.  It is totally impossible to do this in a
politically-neutral way.  Consider, say, a C-B analysis of a wetland
development done by a real-estate developer and and the same analysis done
by Greenpeace.  No way are they going to be similar.

Second, C-B analyses are trotted out as some kind of Gospel.  Somebody comes
up with the numbers, lawmakers or bureaucrats make decisions, and the public
is stuck with the results.  What if the analysis is wildly off?  Where is
the responsibility?

I would like to see the organizations who do these analyses post a bond.
Won't happen, but it's interesting to think about.

Steve Smith                     Agincourt Computing
[email protected]            (301) 681 7395

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

Date: 21 Mar 1995 14:59:46 GMT
From: [email protected] (David Chase)
Subject: Re: Latent risks of cost-benefit analysis (Smith, RISKS-16.93)

[...] Or more generally, cost-benefit analysis skews in favor of what can be
"measured" (medical costs, property values, paycheck) at the expense of the
"intangible" (freedom, nice-smelling air, peace of mind, a good day fishing,
national security, employee loyalty).

Where social benefit is easily measured, it skews towards social benefit.
Where social benefit is not easily measured, it skews away.  I can well
imagine a statistical arms race between the two sides of any costly policy,
attempting to assign value to the otherwise intangible costs and benefits of
the policy.  It's also an entertaining game to see what intangibles are
considered so important that they should not have a price tag attached (and
by whom).

David Chase  CenterLine Software

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

Date: Tue, 21 Mar 1995 13:23:45 EST
From: "Rob Slade, Social Convener to the Net" <[email protected]>
Subject: Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93)

In a recent posting, Simson Garfinkel used a reference to Prodigy's former
method of handling swap space to point out that certain types of online
access systems leave you vulnerable.  In today's issue, Frank Ferguson tries
to indicate, using details of the MS-DOS FAT and delete function, that such
a concern is invalid.  They are, or course, both right, but Garfinkel is
righter.

While Prodigy never did have any specific function in their software to
browse and return information from the user's computer to the company, the
software did have provisions to automatically update software.  This could
(although it wasn't) be used to run other types of software without the
user being aware of it.  But we don't have to pick on Prodigy.  Other
commercial systems "take over" your machine when you run the front end
software.  This is, of course, done to ease the burden of use for the
subscriber, but it does mean that the online service can basically do
anything they want with your computer.  (The same, of course, is true for
any software, but commercial online systems have the advantage of being
in communication with their own software while it is running on your machine.)

We need not limit the discussion to commercial services.  GUI (graphical
user interface) systems tend to have a lot of security loopholes and hiding
places anyway.  The X system has provisions for a remote system to control
your workstation.  The various World Wide Web browsers, particularly the
graphical ones like Mosaic, have the ability to both transfer files and
invoke execution of programs.  That's all you need for a really nifty
virus/worm ...

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733

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

Date: Mon, 20 Mar 1995 22:18:44 -0700
From: Bear Giles <[email protected]>
Subject: Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93)

I content that this behavior *is* a bug.  The proof is in the public's
reaction to finding bits of "their" files in the Prodigy cache area.

To give a human metaphor, imagine a coworker who casually leafs through the
papers on your desk while waiting for you to get off the phone.  This might
be nothing more than a nervous mannerism and he may be totally unaware of
what he's doing, but very few people won't be seriously annoyed at him.

To avoid even the appearance of impropiety, most people carefully stare
into space (or read a magazine) in this situation.

Prodigy didn't observe this behavior (which in the computer world would have
been allocating the space and immediately wiping the current data); it
grabbed some disk space and saved a few seconds by not wiping the existing
data...

.. and found itself tremendously embarrassed because it violated one of the
prime rules of our society (regarding privacy).  The fact that we're still
discussing this years later proves how sensitive of a nerve it hit!

In an era when computers were scarce resources and few people had frequent
interactions with one, such behavior could be justified as a valid
engineering tradeoff.  But computers are now routinely used by a large part
of the population, and it is incumbent on the programmer to observe the
social conventions even if it proves to be moderately "expensive."

Bear Giles  [email protected]

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

Date: Tue, 21 Mar 1995 16:23:44 -0500
From: Steve Holzworth <[email protected]>
Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93)

This "announcement" is so full of holes as to be ludicrous.

1) According to the NC Banking Commission, use of the term "bank", with a
   very few limited exceptions, is illegal for anyone but an organization
   that is a federally (FDIC) or state chartered, regulated entity. The NC
   Banking Commission has taken an interest in this announcement, and is
   forwarding the info to the FDIC...

2) "The alternative to personal credit cards for electronic commerce is
   based on an FBOI procured Visa (tm) Automated Teller Machine (ATM) card.
   The card is prepaid, PIN protected, replaceable, disposable, and good
   at over 200,000 Visa/PLUS (tm) ATMs in 83 countries.  "

Translation: 'you send us $x.xx to keep on account (with no interest accrued
to you). We deduct purchases from this balance'. What happens if we disagree
on the balance and/or dispute transactions? Because this an ATM card as
opposed to a credit card, normal fraud liability limitations ($50.00 US)
and disputed charge reversals are not in effect. If someone fraudulently
charges against your ATM account, you potentially bear the full loss.

Also, the "vendor" info, sent in response to the specified E-mail request,
indicates that the ATM cards are not "rechargeable". When you run your
balance down, you must buy a new one. FBOI charges a 5% commission to
establish a new card for you (ie - the "setup" fee is 5% of the balance you
wish to put on account; when that runs out, you pay another 5% for a new
card).  Since they charge vendors a 5% commission per transaction, FBOI is
keeping 10% of all funds that move through their system.

3) "The safety of FBOI is ensured because access to ATM funds without
  possession of both the ATM card and the Personal Identification Number
  (PIN) is not possible.  ATM cards are also better than credit cards because
  their purchase does not require the personal, financial, and employment
  background of the consumer."

Here is how a transaction is instigated (from FBOI info):

  "*FBOI procedures for creating a vendor E-mail invoice*
   FBOI E-mail invoices are a two line message created by a FBOI vendor.
   Line one of the message contains the customer Internet E-mail address.
   Line two contains the transaction amount in US dollars.  This message
   must then be encrypted, signed, in ASCII, and in Text using the PGP
   command "PGP -seat invoice fboi".  The "invoice.asc" is then ready to
   be E-mailed to [email protected] with subject "invoice".  FBOI will issue
   an E-mail transaction receipt."

   "*FBOI procedures for creating a customer E-mail check*
   FBOI E-mail checks are a two line message created by a FBOI customer.
   Line one of the message contains the vendor Internet E-mail address.
   Line two contains the transaction amount in US dollars.  This message
   must then be encrypted, signed, in ASCII, and in Text using the PGP
   command "PGP -seat check fboi".  The "check.asc" is then ready to be
   E-mailed to [email protected] with subject "check".  FBOI will issue an
   E-mail transaction receipt."

FBOI then reconciles the above transactions and sends payment to the vendor
(or credits the vendor's ATM card). Note that FBOI recommends product pricing
at around ONE US DOLLAR for items! (Almost-Freeware, anyone?)

4) "...In addition, consumers can reclaim their funds at any time using
   an ATM."

At what service charge per transaction? What limitations on withdrawal
amounts (how many transactions will it take to empty my account)? Any
yearly fees for this privilege? FBOI info is rather vague in this regard.
The only pertinent comment I saw was (pertaining to vendor payment):

   "... While the Visa ATM card as a payment method has many
   advantages (portable, anonymous, and cash in any country of the world),
   your ATM may not dispense the entire payment due to the exchange rate
   and possible ATM fees."

5) "...Those services will collect the consumers credit card information in
  advance because of Internet security problems."

Since those are still credit card transactions, the consumer has much better
dispute resolution abilities.

6) "FBOI transmits no sensitive information over the Internet and prevents
   forgery and impersonation by using Pretty Good Privacy, PGP (tm),
   software for all transactions.  This freeware provides excellent
   authentication and anti-alteration security."

The description of transactions as in (3) above may or may not be subject
to spoofing. I'm not up enough on crypto to comment.

7) "In addition to the unsecured nature of the Internet, consumers should be
  hesitant giving out their credit card information to vendors of unknown
  credibility."

You mean like FBOI?? Based out of a Netcom account (instead of a .com domain)?

8) "...since U.S. Postal Service and Federal Trade Commission mail order laws
   do not apply to the Internet."

The laws may not apply to the Internet per se, but credit card transactions
are still subject to all of the controls of typical "mail order" as is
normally practiced via telephone.

9) "The First Bank of Internet (tm) is not a lending institution, and is not
   chartered."

This says volumes.... (see (1), above).

And finally:

   "When FBOI procures a Visa ATM card for vendor customers the card
   becomes their money.  FBOI will be granted access to their funds
   through the FBOI customer agreement allowing FBOI to possess a
   duplicate card."
^^^^^^^^^^^^^^^^^^

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

Date: Tue, 21 Mar 1995 13:50:53 EST
From: "Rob Slade, Social Convener to the Net" <[email protected]>
Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93)

The FBOI card does seem to address some of the security concerns for commerce
over the net.  The replacement of one number by another does not provide
any particular safety, but the limit on the card does restrict the damage.
However, inquiring minds want to know:

How easy is it, aside from emptying the account, to cancel/change/get a new
card?  Is there a fee?  Is there any recourse if someone empties the account
before you do?

Does the encryption apply only to the card number, or to the whole transaction,
including time and date stamp?

Does the encryption software come with the card?  Is it a smart card?  Do
you need a card reader of some type?  What platforms is the software available
on?  Is the user responsible for getting/setting up the software?

By using PGP is the FBOI restricting its operations to the US?  Is the
version of PGP that they are using operating with the RSA algorithm, or
another?  Is the key size restricted?

If this really does work over E-mail, why do you keep talking about ATM?
(Does it only work over asynchronous transfer mode networks?  :-)

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733

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

Date: Tue, 21 Mar 1995 08:15:38 -0500 (EST)
From: [email protected] (Willie Smith)
Subject: Re: First "Bank" of Internet (Beigh, RISKS-16.93)

In Risks 16.93, [email protected] (Vinn Beigh) writes:
>The card is prepaid [...]
>The safety of FBOI [the non-chartered, non-bank company] is ensured

..by the fact that it's prepaid, and even if FBOI loses all the money
in the account due to fraudulent transactions, it's _your_ money
that's gone, not their 5[!!] percent!

>The worldwide producers on the Internet can use FBOI services without the
>expense of owning or renting a dedicated Internet server or a World-Wide
>Web site.

Yeah, just get an account on netcom and you're a business!  C00L!

>In addition to the unsecured nature of the Internet, consumers should be
>hesitant giving out their credit card information to vendors of unknown
>credibility.

Giving cash to some guy with a Netcom account is OK?  Maybe I missed
the smiley, or the original submission was tongue in cheek...

>since U.S. Postal Service and Federal Trade Commission mail order laws
>do not apply to the Internet.

Another safety net for FBOI.  What a gig!  Tell you what, I now announce the
First International Bank Of The Information Supercollider, you send me money
and I promise not to lose it.

                           [The money, that is, not the Supercollider. PGN]

Willie Smith    [email protected]         [email protected]

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

Date: Mon, 20 Mar 95 10:28:42 EST
From: [email protected] (Sushil Jajodia)
Subject: Information Security Tutorials

               INFORMATION SECURITY INSTITUTE
                       Sponsored by:
             Center for Professional Development
                   George Mason University
                   Fairfax, VA 22030-4444

Intensive, Short Courses:

o  Information Security Principles and Practice  March 27-31, 1995
  Instructors:  Marshall Abrams, Daniel Gambel, Sushil Jajodia,
    Harold Podell, Ravi Sandhu

o  Recent Developments in Information Security   March 27-31, 1995
  Instructors:  Marshall Abrams, Daniel Gambel, Sushil Jajodia,
    Harold Podell, Ravi Sandhu

o  Practical Security in a Networked Environment  April 3-7, 1995
  Instructors:  Marshall Abrams, Ravi Ganesan, Sushil Jajodia,
    Brian McKenny, Harold Podell, Ravi Sandhu

o  UNIX Security  April 3-7, 1995
  Instructors: Marshall Abrams, Ravi Ganesan, Harold Podell, Ravi Sandhu

For further information, visit the Information Security Institute home
page through mosaic at http://www.isse.gmu.edu/~gmuisi.

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

Date: Mon, 20 Mar 1995 16:50:49 +0100
From: [email protected] (Pippo Scollo)
Subject: AMAST'95 Preliminary Programme available

The Preliminary Programme of the AMAST'95 Conference (4th International
Conference on Algebraic Methodology And Software Technology, Montreal,
Canada, July 3-7, 1995) is available on the WWW at the following URL:

 http://www.cs.utwente.nl/data/amast/amast95/PreliminaryProgramme.txt

The file includes abstracts of the invited talks, conference schedule,
registration information and registration forms, and accommodation and
travel information. The deadline for reduced registration fees is:

 Monday June 5, 1995

The file is also available by anonymous ftp:

 host:      ftp.cs.utwente.nl
 username:  anonymous
 password:  your E-mail address
 directory: pub/doc/amast/amast95/
 get file:  PreliminaryProgramme.txt

More information about AMAST'95 is available from the following sources:

1. For bulletins on current status of the conference:

   [email protected]
   Tools and Demos: [email protected]
   Registration: [email protected]
   Local Arrangements: [email protected]

2. For subscribing to AMAST'95 mailing list:

   [email protected]

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

Date: 21 March 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from 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.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
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.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

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

End of RISKS-FORUM Digest 16.94
************************

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.