precedence: bulk
Subject: RISKS DIGEST 18.88

RISKS-LIST: Risks-Forum Digest  Friday 7 March 1997  Volume 18 : Issue 88

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents:
NASA: Another Website Bites the Dust (David Kennedy)
Two More Microsoft Internet Explorer Bugs (David Kennedy)
Another MacInTax "Glitch" (David Kennedy)
Re: 12/99 problem (Clive D.W. Feather, Mark Brader)
Computer glitch leads to police friendly fire (J.R.Valverde jr)
Re: Mouse-based interfaces (Dean Esmay via Phil Agre)
Trusting the software vendor (Matt Welsh)
"Rich" computing versus security (Matt Welsh)
Re: ActiveX security: The other side (Wayne K. Gerdes)
Lab monitoring (Fritz Schneider)
Risks of crying wolf (David Lesher)
Moonlighting on safety-critical systems (Jonathan Bowen)
The SEI Conference on Risk Management (Carol Biesecker)
The Ethics of Electronic Information in the 21st Century (Les Pourciau)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 5 Mar 1997 16:59:16 -0500
From: David Kennedy <[email protected]>
Subject: NASA: Another Website Bites the Dust

http://www.nasa.gov is NASA's home page.  It appears it was hacked last
night.  It's off-line now.  When a mirror of the hacked page is posted,
I'll let you know if someone else on the list doesn't first.

If my report is accurate, the hacked page included:

>Our mission is to continue where our colleagues the ILF left
>off. During the next month, we the members of  H4G1S, will be
>launching an attack on corporate America.  All who profit from
>the misuse of the internet

"ILF" refers to the Internet Liberation Front who attacked GE and others in
December 94.  The only person who has claimed to be a member of the ILF is
Christopher Schanot, a then-high schooler from St. Louis, who's in jail for
what he did.  He broke into systems using a password provided by a classmate
who was the son of an employee of one of the systems he entered.  He also
used password sniffers to capture legitimate passwords that were passed over
the net unencrypted.

The rest of the hacked NASA page is some mundane pro-hacker stuff about
Kevin "Condor" Mitnick and Ed "Bernie S" Cummings.

Lesson: Running a web site requires somebody to take the time to know about
the vulnerabilities and *do* something about them.  There are no quick
fixes.  As William Hugh Murray, a colleague, says, "There is no magic."

Dave Kennedy CISSP  National Computer Security Assoc [email protected]

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

Date: Fri, 7 Mar 1997 02:12:18 -0500
From: David Kennedy <[email protected]>
Subject: Two More Microsoft Internet Explorer Bugs

1. EliaShim warns of security hole in Internet Explorer
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service

> PC Week Online (March 6, 1997) - Less than a week after the discovery of a
> potential security gap in Internet Explorer 4.0, Microsoft Corp. may have
> another hole to fill.  EliaShim Ltd., an anti-virus company, claims it has
> identified security problems in Microsoft Internet Mail and News
> applications. "Hostile links" can be embedded in newsgroup messages or in
> messages received by Internet Mail as shortcuts, company officials said.

2. Another Internet Explorer Bug Found
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service

> REDMOND, WASHINGTON, U.S.A., 1997 MAR 7 (Newsbytes) -- By Bob Woods.
> Another bug in Microsoft's [NASDAQ:MSFT] Internet Explorer (IE) World Wide
> Web browsing software has been discovered by a group of University of
> Maryland students. The students posted their results at their Web site
> today, and claimed that the bug could let a hacker remotely break into a
> user's computer or install viruses onto the system.  UMD students David
> Ross, Dennis Cheng, and Asher Kobin found the bug in IE 3.01.

Microsoft acknowledges the bug but hasn't defined it full impact.

> The bug apparently centers around IE's Iframe, or floating
> frames feature.

The patch for the URL/LNK bug does not fix the UMD student's bug.

> The students' Web site is at http://dec.dorm.umd.edu/ .
> Microsoft's IE site is at http://www.microsoft.com/ie .

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.

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

Date: Fri, 7 Mar 1997 02:12:21 -0500
From: David Kennedy <[email protected]>
Subject: Another MacInTax "Glitch"

Intuit warns of MacInTax glitch
Courtesy of the COMTEX Newswire via CompuServe's Executive News Service:

> MacWEEK Online (March 5, 1997) - Intuit Inc. this week sent a letter to
> its MacInTax users detailing a potential pitfall for electronic
> filers. Users who fail to save their documents before filing them
> electronically may receive word from the IRS of an incomplete filing.  The
> company said the problem will likely affect only a small percentage of
> users, as most would opt to save their work before transmitting
> files. However, there are some customers who tend to go straight to the
> electronic filing function without saving.

Patch at http://www.intuit.com/ or by disk.

> In a statement, Intuit Vice President Larry Wolfe said the problem is
> "absolutely covered" under Intuit's general product guarantee. "If a
> customer has filed an incomplete electronic return with MacInTax, Intuit
> will pay the penalty plus any interest assessed by the IRS," he said.

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.

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

Date: Fri, 7 Mar 1997 08:19:07 +0000
From: "Clive D.W. Feather" <[email protected]>
Subject: Re: 12/99 problem

This looked like a Y2K problem at first sight. However, it isn't. Some names
are changed to protect me from defamation suits.

I work for a major ISP, and many of our customers pay us monthly by credit
card. This problem hit a whole batch of customers at once, but I'll just
pick one and call him or her C. C has a card issued by a major bank, who
we'll call B. We use a major credit card organisation in the UK for all
credit card transactions; let's call them V.

When a customer signs up with us, they quote card number and expiry date,
which we enter on to our computer. Each month we take that data and send V a
packet of the form <amount, card number, expiry>. Now suppose that the card
originally expired in 08/96. The customer might be good enough to let us
know that they have a new card expiring in 08/98, and we can update our
records, or they might not. If they don't, then we send <amount, card
number, "12/99"> to V.

The other day we charged C's card. It came back "rejected". So, following
normal practice, we suspended the account and waited for C to call us. After
doing so, C phoned B and confirmed the card was fine. A four-way
conversation then ensued. It turns out that what happened was the following.

C's card had an original expiry date of 12/96. Our software noticed that the
card was expired, and sent the request with an expiry of 12/99. On arrival
at V, their software looked up the card number in a table which says, in
effect: "this range of card numbers was issued by B with an expiry of
12/96". V's software also knows that B uses a 3-year rollover of cards. So
they added 3 to 12/96, amended the expiry field to 12/99, and forwarded the
request to B.

Meanwhile, someone at B decided that, given the special meaning of 12/99,
issuing cards that expiry then is a Bad Thing. So cards expiring in 12/96
were renewed with an expiry of *11*/99. The resulting mismatch caused the
rejection.

I understand that V's computers will be reprogrammed to solve this
problem. But just whose is the error?

Clive D.W. Feather Demon Internet Ltd. <[email protected]>  +44 181 371 1138
CityScape Internet Services Ltd. <[email protected]>

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

Date: Fri, 7 Mar 97 11:11:44 EST
From: [email protected]
Subject: Re: 12/99 problem

Clive Feather writes:

> This looked like a Y2K problem at first sight.  However, it isn't.

Sure it is.  Without Y2K, who would have thought of choosing the month/year
"12/99" as an out-of-band flag value?  In fact it's a particularly silly
Y2K error, since 99/99 would have fitted the field length just as well.

> But just whose is the error ?

Either B's or V's, but in order to tell which, we'd have to know what they
said to each other and when.  Did V tell B that they needed to know their
expiry rollover pattern in order to validate transactions, or did they just
assume that because B had been using a 3-year rollover they always would?
If the former, then did B inform V that their practice was being varied this
time, and if so, did they do it in timely manner so that V could be prepared
for it?

Mark Brader, [email protected] SoftQuad Inc., Toronto

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

Date: Fri, 07 Mar 1997 18:30:08 WET
From: "J.R.Valverde (jr)" <[email protected]>
Subject: Computer glitch leads to police friendly fire

The Vasque Country in the north of Spain has a strong terrorist group, ETA,
which -among other activities- often attacks the Police.

Last week there was a sad incident: two secret police groups started
shooting each other. The reason? According to the government it was all due
to a computer glitch.

Things are said to happen like this: that afternoon there had been a bombing
in town. One group of civil-dressed secret policemen saw a group of armed
guys in a car and started off after them. Of course, first thing they did
was call the central offices to ask for information on the car and its
owner. Here comes the computer bug: they could not get any information and
assumed those guys were the terrorists that had done the bombing.

The other car was loaded with secret policemen too. They saw that they were
being followed by armed civil-dressed people in a car, could not get any
information either and assumed they were being pursued by terrorists that
were after them to kill them in a second coup de main and fled away.

You can see what happened. At some point the first car stopped, the second
did the same, all them took their arms, all them got alarmed at seeing each
too their arms, someone shoot first, and hell was left loose...

The problem? relying on computers for tasks where human lifes are involved
and not having adequate fail-safe systems.

jr

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

Date: Thu, 6 Mar 1997 19:01:15 -0800 (PST)
From: Phil Agre <[email protected]>
Subject: Mouse-based interfaces (Re: Hersh, RISKS-18.87)

[He's right.  Phil]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command.  For information on RRE, including instructions
for (un)subscribing, send an empty message to  [email protected]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Date: Thu, 6 Mar 1997 21:53:39 -0500
>From: Dean Esmay <[email protected]>
Subject: mouse-based interfaces

[...]

I was both pleased and disturbed to read Jay Hersh's comments on GUIs and
the disability community in your recent RRE mailing, and a bit concerned
about some of your comments on his thoughts.  Not that either of you are
wrong, but you aren't exactly right either.

The deaf child, the woman with multiple sclerosis, and the blind man all
have fundamentally different needs, none of which are necessarily
compatible.  Given that, I'm not sure who Jay Hersh thinks he's talking
about when he refers to the "community" needing to fight against
mouse-centric interfaces, and I am even less sure that the waters aren't
further muddied by your comments about the efficiency of keyboard
interfaces.

I worked for a number of years in an employment agency for the disabled, and
have attended and even led workshops on how to make computers more
accessible to the disabled.  I think three things should be kept in mind
before anyone tries to influence how computers interact with people:

1) GUIs are substantially beneficial to some disabled users.

2) The problem with computer software not working well for some people has
been around far longer than the widespread use of GUIs.

3) There is no one solution (to date) that works well for everybody.

Prior to GUIs, the visually impaired did pretty darned well.  After all,
text-based software can often be easily adapted to speech synthesis.  While
there were things to complain about, the blind generally did pretty good.
But the blind are not the only members of the disability community, and the
non-blind disabled were often still faced with serious aggravations, or
even locked out in the cold.  GUIs fixed that for many of them.

A number of devices exist that substitute for the traditional mouse, the
best of which is a strap-on headset with which a person with no use of
hands can point by merely moving her head (or even just her tongue if neck
mobility is limited) and "clicking" with a puff of breath. Your beloved
EMACS is normally worthless to a woman without arms.  But give her an
interface where she can point and click with her hands-free mouse, "type"
clicking on the keys of a floating on-screen keyboard that feeds her
"keystrokes" to the window of her choice, and that responds to specific
voice commands for shortcuts, and she can do anything you can.  In today's
GUI world, most properly-written software can use such special tools
without need for modification or special programming.

It's also probably unfair to lump Apple in with Microsoft. Apple has a long
history of working with the disability community.  Back in the old Apple II
days, they manufactured special devices to help the disabled use their
computers.  When the Mac came along, they cooperated enthusiastically with
the manufacturers of the hands-free mouse and similar devices, and worked
hard to make their GUI and their API work effortlessly with such special
tools.  Apple also put a good bit of money into developing and testing
their Easy Access and Closeview extensions, which ship free with every
Mac/OS machine and vastly improve the interface for many disabled people
(including some with partial vision).  They even include system software
extensions to make voice control possible in any program, and powerful
built-in scripting that can automate many tasks in many applications.

Of course, Apple comes up short with some, especially the blind.  That
section of the community has generally stayed with the text interface
operating systems that work best for them.  But still, Apple has arguably
done much to adapt to people with special needs, for which they deserve
credit.

But let's set aside Apple, which is only one imperfect company.  The fact is
that today, a majority of the disabled can use much Windows software right
off the shelf, too.  This is a tremendous step forward from ten years ago.
But the same GUI which has helped so many others is forcing the blind to the
sidelines.  It's damned hard to adapt a GUI to a speech-synthesized,
sight-free world.  It's not impossible; some very clever macro-based
work-arounds do exist.  But much more needs to be done to address this
problem.

There badly needs to be a widespread discussion of issues like applications
and APIs which just plain ignore the needs of the disabled.  We need to
encourage elimination of unnecessary popup menus and dialogs, buttons with
graphics but no text, buttons with text but no graphics, hierarchical
pull-down/pop-up menus that are a bitch to navigate if you can't see well or
have poor coordination, and more.  The blind also have a need for more
productivity and utility software written specifically with them in mind;
the market is large enough now that, while it might not be much of a blip on
Microsoft's radar screens, it's more than enough for small companies and
cottage industrialists to make decent money.  I've met a few people who
write that kind of software for a living, but there's room for more.

I commend you for bringing this issue to wider attention, and I hope you'll
talk more about it in Red Rock Eater.  But I urge you not to get lost in
generalizations about what a vague, unspecified "disability community"
needs, or tangle that up with what you find most useful for yourself.

In any case, thanks for doing something to at least start people thinking
about these issues!

http://www.syndicomm.com/esmay

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

Date: 7 Mar 1997 12:09:01 GMT
From: [email protected] (Matt Welsh)
Subject: Trusting the software vendor (Re: Atkinson, RISKS-18.85)

> ... you trust the retailer to sell you only legitimate product ...

It's interesting that Microsoft should defend Authenticode with this
analogy, when in fact Microsoft itself has been known to distribute CD-ROMs
with viruses. Given that I can't even "trust" Microsoft software obtained
through traditional distribution channels, by what stretch of belief am I
supposed to concede that Authenticode will solve this problem for
non-traditional channels?

M. Welsh, Cambridge Computer Laboratory

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

Date: 7 Mar 1997 12:24:05 GMT
From: [email protected] (Matt Welsh)
Subject: "Rich" computing versus security (Re: Atkinson, RISKS-18.85)

>Users want and demand a rich computing experience. ...

It seems that it would be worthwhile in the course of this discussion to
step back a bit -- instead of merely attacking or defending Authenticode,
why don't we look at the basic statement used to defend ActiveX?
Paraphrasing, "In order to have a rich computing experience, applications
must forgo some degree of security."

This is a contentious statement. A great deal of work has been done in both
the academic and industrial computing communities to develop computing
environments which enable 'sandboxing' of code and still provide a 'rich
computing experience' - e.g., flashy graphics, I/O device and network
access, and the like. Although with the advent of Java we are starting to
see these ideas in the mainstream, they're not particularly new.

It is far easier to verify and trust my Java Virtual Machine implementation,
for example, than it is to verify and trust every ActiveX control which comes
my way. In the former case we are basing our trust on the developers of
the computing environment - in the latter, upon every software developer
who ever writes or has a hand in every ActiveX control we use. In the
former case, the security of the system can be verified and is enforced
through technical means; in the latter, only through social and legal ones.
I know which one of these I'd rather employ.

M. Welsh, Cambridge Computer Laboratory

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

Date: Fri, 07 Mar 1997 11:29:56 -0500
From: "Wayne K. Gerdes" <[email protected]>
Subject: Re: ActiveX security: The other side (Rath, RISKS-18.87)

Having done a proposal for development of a worm/agent based software
distribution system similar to ActiveX or FTP inc's CyberAgent I have done
some serious thinking about the security problems.  A truly useful piece of
software must have access similar to a standard user account, or at least a
captive account.  Java's sandbox model is wonderful if the idea is to
provide graphics using the local machine's CPU power.  It is, however, very
difficult to perform useful work with such a system, where useful work is
defined as, say word processing involving references to active objects and
saving files locally.  A more scientific example might be performing
calculations as part of a distributed computation and forwarding the results
to some arbitrary destination.  Another example might be querying a series
of remote databases and forwarding the results.  These examples require the
ability to address arbitrary hosts, require disk storage space, and/or a
vanity of other access and privileges. The primary problem is that Windows
3.1 thru Windows 95 does not have the security features to isolate such
programs.  Under "more advanced" operating systems such as UNIX, VMS, or
Windows NT, to name just a few, it is possible to create a "larger sandbox",
via separate accounts, captive accounts, disk quotas, limiting system calls,
etc.  Note that even this will not eliminate the security problem(s).  It is
always the temptation to install new software with root privilege or
equivalent.  It is almost always possible for hackers to find some OS bug to
exploit.  As readers of this digest know, even well intentioned programs
often corrupt data, crash machines etc.

The next element of the security problem, is the surprisingly high quality
of web distributed software. Despite the many security concerns of down
loading and executing some arbitrary piece of software written by Unknown,
most people do it and the worst thing that usually happens is that it
crashes. AS Mr. Rath notes, most people want to "just get on with it".
Security warning messages about "Should this program be allowed to access
the disk?" or "Accept this cookie?" quickly become annoying and get turned
off.  Under these circumstances the current digital certificate and code
signing is a reasonable approach.  What the current system does lack is
degrees of trust.  It might be reasonable to require a very large bond
before issuing a AAA certificate and a small one for a BBB certificate.  Web
sites could be established to rate the reliability of new software.
Something like Cancel Moose could be developed to chase down and deactivate
certificates belonging to errant software.  Instead of downloading
certificates they might be implemented as active objects stored at well
known web sites.  This would make the process of revoking them MUCH easier.
Looked at from this view point ActiveX vs Java can be seen as sort of
large scale beta testing of "the REAL solution".

Wayne K. Gerdes [email protected] (757)864-1520 (AST, Data Systems)
Flight Electronics Tec. Div, Systems Integration Branch MS 152D

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

Date: Fri, 7 Mar 1997 17:10:47 -0500 (EST)
From: Fritz Schneider <[email protected]>
Subject: Lab monitoring (Re: Fraudulent use of e-mail addresses, RISKS-18.87)

       Just a quick response to Andrej Panjkov's article regarding a bad
experience he had with e-mail forged in his name.  After relating his
situation, Mr Panjkov gives the following advice:

> Lessons: monitor undergraduate computers carefully.  At the very least,
> register users.  And use PGP.  Perhaps, we should all periodically sweep
> the web to see where our names are ending up?

       Although in theory I agree with all of these suggestions (ignoring
the impracticality of the last), I question the wisdom of assuming that
misuse of technology such as the net will be perpetrated by the younger
generation.
       There is no reason to necessarily suppose that older (graduate)
students are any more ethical than their younger (undergraduate)
counterparts.  In fact, it seems to me that the BIGGEST risk comes from
those with more education, skills, and experience.  Therefore if one can
only monitor one lab but not both, it would be more prudent to keep an eye
on those with the resources to carry out the most destructive acts.
       I am, however, not convinced that mere "monitoring" of a computer
lab can prevent forged e-mail...
       The Risk here:  1. Assuming that age/education is inversely
proportional to ill intent.

 Fritz Schneider [ [email protected] ]

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

Date: Fri, 7 Mar 1997 04:48:27 GMT
From: [email protected] (David Lesher)
Subject: Risks of crying wolf

I am in Maryland [301], but the local calling area extends across DC [202]
into Virginia[703]. Within that area (which also includes parts of 410 and
soon will have 240 and 443), calls are 10D, with a leading "1" not
necessary. (Rather; without it, you are assured the call is not toll.)

So I tried to call 703 715 xxxx, in the Vienna area.  But I got an
intercept, telling me that THAT number was now in the 540. (540 was
split from 703 last year, with Risks of its own after Bell sent
postcards to the WRONG group of customers...)

Now, AFAIK, no part of 540 is DC-Metro. And 715 did not move. But I gave it
a try, and sure enough, Bell decided "540-715X" was a 301 #, (Gaithersburg,
local to me) but one out of service. (With no "1" it knew better than to try
540-715-xxxx.)

Now, 715 is *still* in 703. So that intercept is bogus. But look who likely
gets wrong numbers from believing it: 540-715 if/when it's created, and 301
540-715x.

The Risks? Well, believing the error message may do you more harm than
good. And as the sparse NPA space turns increasingly dense, others won't
have the benefit that I received; that of the wrong number I dialed being
idle.

Did Arthur C. Clarke see THIS coming, too ;-?

[email protected]  (301) 56-LINUX

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

Date: Fri, 7 Mar 1997 09:24:45 GMT
From: [email protected] (Jonathan Bowen)
Subject: Moonlighting on safety-critical systems

Below is a possibly worrying message which I received recently. (Name and
contact details are blanked out.) Who takes the responsibility if things go
wrong?

Jonathan Bowen, Univ. of Reading, Department of Computer Science, Whiteknights,
PO Box 225, Reading, Berks RG6 6AY, UK http://www.cs.reading.ac.uk/people/jpb/

>Date: Thu, 6 Mar 1997 19:05:30 +0000
>From: xxxxxxxx <xxxxxxxx>
>To: [email protected]
>Subject: wanted

>Would it be appropriate for you to [post] this opportunity on your system?

>  WANTED - Moonlighter with mixed signal simulator and formal verification
>  tools to modify a circuit for a medical device.  Reply confidentially to
>  FAX xxx xxx xxxx.

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

Date: 6 Mar 1997 18:54:32 GMT
From: [email protected] (Carol Biesecker)
Subject: The SEI Conference on Risk Management

The SEI Conference on Risk Management:
 Managing Uncertainty in a Changing World
April 7-9, 1997, The Cavalier Hotel, Virginia Beach, Virginia

For the most current information about the SEI Conference
 on Risk Management and other SEI events, visit our Web site at
 www.sei.cmu.edu/products/calendar.html

For additional information about the conference, contact
SEI Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Phone, Voice Mail, and On-Demand FAX
412 / 268-5800
E-mail: [email protected]
World Wide Web: http://www.sei.cmu.edu

The keynote speakers are
Dr. Paul G. Kaminski, Undersecretary of Defense Acquisition and Technology
General Alton D. Slay, USAF (ret), Slay Enterprises, Inc.
Timothy Lister, The Atlantic Systems Guild, Inc.
Five half-day tutorials are being offered during the morning of Monday, April
 7, 1997.
Two panel sessions are planned for the afternoon of Tuesday, April 8, and
 the morning of Wednesday, April 9.
A special track is planned for invited program managers to talk about
 their risk management experiences. This track starts Monday afternoon,
 April 7, 1997, and runs in parallel with two more tracks, Acquisition/Risk
 Management in Practice and Theory, Models, and Lessons Learned.

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

Date: Fri, 07 Mar 1997 09:02:55 -0600 (CST)
From: Les Pourciau at UMem <[email protected]>
Subject: The Ethics of Electronic Information in the 21st Century

THE ETHICS OF ELECTRONIC INFORMATION IN THE 21st CENTURY
September 26-28, 1997

The University of Memphis {Libraries & Information systems & Linder Center
 for Urban Journalism & Division of Research and Graduate School & Marcus
 Orr Center for the Humanities & Cecil C. Humphreys School of Law &
 Fogelman College of Business and Economics }

Fogelman Executive Center, The University of Memphis, Memphis TN, U.S.A.
http://www.people.memphis.edu/~operations/fec_list.htmlx
Additional Memphis Web Site: http://www.memphistravel.com
Abstracts due by 25 April 1997.  [Check website for details.]

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

Date: 15 Aug 1996 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
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 18.88
************************

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.