precedence: bulk
Subject: RISKS DIGEST 19.35

RISKS-LIST: Risks-Forum Digest  Friday 29 August 1997  Volume 19 : Issue 35

  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:
Prosecution for pager interceptions (Steven Bellovin)
Spy phones trace cheating husbands -- and employees (Mathew)
Book burning on the Web: AOL and columnist sued (Mark Rebuck)
Federal Web Sites Lack Privacy Safeguards (Edupage)
Hacking Risks, Paying for tracking you down (Robert J. Perillo)
Tcl 8.0 Y2K Risk (Lloyd Wood)
Photocopier codes (Marcus L. Rowland)
Oracle web server on Unix and passwords (Dawn Myfanwy Cohen)
Relying on systems maintenance taking place in another time zone
   (Olivier MJ Crepin-Leblond)
Re: Spelling-checker risks (Dave Katz)
Mangled characters in text ("ET")
Re: SET Risks (Tony Lewis, Martin Poole)
Intentional analysis, re: SET Risks (Charlie Lane)
Re: USC 47:227 (Duane Thompson)
Re: Public loo guilty of making nuisance calls (Aaron M. Renn)
Re: Tobacco Deal Could Set Precedent for Would-be Net Censors
   (David T.S. Fraser)
Risks of believing the obvious, though impossible (Sam Lepore, PGN, Sam)
ICDCS-18 call for papers (Diego Latella)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 27 Aug 1997 22:07:22 -0400
From: Steven Bellovin <[email protected]>
Subject: Prosecution for pager interceptions

A New Jersey company has been charged with illegally intercepting and
selling messages sent via a paging service.  The messages -- the content of
which was sold to news organizations -- were intended for delivery to the
offices of various senior New York City officials, including the mayor's
office and various top police and fire department officers.

That alone wouldn't make this a story for RISKS.  What makes it interesting
is why these messages were sent via pager -- the police department
considered them to be too sensitive to broadcast on police radio
frequencies.  After all, anyone with a scanner could hear those messages,
but pager messages are blessed with special pixie dust known as "digital
format".  Besides -- intercepting those messages is illegal, unlike using a
scanner.

The obvious answer is to use cryptography, of course.  But does anyone make
a PGP-capable pager?

[Added note from Steve:]
The NYT story also quotes PGN as saying this is the first such case
[PGN was referring to the first prosecution] he knew of.  Actually, the
hacker community has been doing this for years -- there was a demo at
H.O.P.E. (Hackers on Planet Earth, Aug 13-14, 1994, New York) -- with a
screen displaying all incoming pages in real-time.

 [No surprise there.  That "community" is generally way ahead of the
 would-be "protectors" and users of the computer-communication
 infrastructure.  Incidentally, the name of the company is Breaking News
 Network, a wonderful pun in itself, although Breakin' News Network would
 have been even cuter.  PGN]

 [Moderator's comment on Steve's advice to use encryption: With
 the new legislation to pay medical schools *not* to teach students,
 perhaps we will enter an era when the U.S. Government pays
 cryptographers *not* to do research.  (I know April Fools' Day
 is still 7 months away, but I could not resist.)  PGN]

[A further note from Steve included an article by Amy Westfeldt in *The New
York Times* of 29 Aug 1997 to the effect that BNN denies intercepting the
messages, and blames two disgruntled former volunteers who were released six
months ago.  BNN claims it did not even have the facilities to do the
cloning/scanning.  BNN's attorney accused prosecutors and NYC officials of
targeting BNN because this incident had embarrassed Mayor Giuliani.  A
spokesman for the mayor countered, noting that this was a federal
prosecution, not a city action.  PGN Abstracting]

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

Date: Wed, 27 Aug 1997 10:40:50 -0400
From: mathew <[email protected]>
Subject: Spy phones trace cheating husbands -- and employees

Electronic Telegraph, <URL:http://www.telegraph.co.uk/>, 27th August 1997:

Spy phones trace cheating husbands (By Robert Uhlig, Technology Correspondent)

A MOBILE telephone being developed by British Telecom could soon spell an
end to the deceptions by idle employees, stressed executives and adulterers.
The Mobile Social Alarm or Mosa, currently under development at BT, will be
the first telephone that can send precise details of the caller's location
to the person receiving the call.  Workers will no longer be able to phone
the office pretending to be sick when they are at the beach and movements of
cheating spouses will be exposed because the phone will show the caller's
location to within 30 feet.

According to Don Golding, a mobile applications engineer in charge of the
project, companies will also be able to call the Mosa-phone without their
employees' knowledge to track staff.

What gets me about this story is the gleeful reporting of the fact that
companies will be able to call your phone and trace your exact location,
without your knowledge or consent -- and that this is apparently a
deliberately designed-in feature of the system.  Does Don Golding read
RISKS, I wonder?

mathew <URL:http://www.pobox.com/%7Emeta/>

 [The Southern California ladies will use a Her-Mosa Beach Model.  PGN]

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

Date: Thu, 28 Aug 1997 12:49:27 -0400
From: Mark Rebuck <[email protected]>
Subject: Book burning on the Web: AOL and columnist sued

Sidney Blumenthal, a former advisor to President Clinton, has filed a $30
million defamation lawsuit against cyber-columnist Matt Drudge and AOL.
Normally, I don't get too excited about defamation/slander suits.  However,
the following quote from William McDaniel, attorney for Mr. Drudge, managed
to get my attention:

> [McDaniel said,] "one special aspect of defamation over the Internet is
> that it is difficult to remove the false material" because it can be
> downloaded, printed or stored by any number of readers.

Perhaps I am just being paranoid, but McDaniel's statement sounds similar to
"Darn it, we can't burn books on the Web like we can in the real world!"

(I read about the lawsuit from an AP item in USA Today: www.usatoday.com.)

-Mark Rebuck,  [email protected]

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

Date: Thu, 28 Aug 1997 11:30:29 -0400
From: Edupage Editors <[email protected]>
Subject: Federal Web Sites Lack Privacy Safeguards (Edupage)

OMB Watch, a nonprofit group that monitors government activities, faults the
federal government for its lackadaisical approach to protecting the privacy
of government agency Web site visitors.  "There is no government-wide policy
regarding privacy concerns on federal Web sites...  Agencies collect
personal information about visitors to their Web sites, but fail to tell
them why that information is being collected and what it is being used for,"
says an OMB Watch information specialist.  Nearly half of 70 federal
agencies collect information about their online visitors, but only 11 inform
them how that information will be used.  Three agencies, including the
National Science Foundation, were collecting cookies -- a set of data that
enables the Web server to track a user's patterns and preferences -- but all
three have stopped following the release of OMB Watch's draft report.
(TechWire 27 Aug 1997; Edupage, 28 August 1997)

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

Date:  Tue, 26 Aug 97 12:45 EDT
From: [email protected]
Subject:  Hacking Risks, Paying for tracking you down

Wendell Dingus, a U.S. hacker, was sentenced by a Tennessee federal court in
late May to six months of home monitoring for violations of the amended 1986
Computer Fraud and Abuse Act.  Wendell Dingus admitted to a series of
attacks to gain unauthorized entry into U.S. Air Force and NASA computers
using a Vanderbilt University computer to obtain log-in passwords.

What is interesting about this case is that the damages to meet the $5,000
requirement of the Law were not based on the harm of the hacking, but based
on the cost of tracking and catching the hacker. The court ordered him to
pay $40,000 restitution to the Air Force Information Warfare Center (AFIWC,
San Antonio Tx) for their time and effort involved in tracking him.

According to Airmen at AFIWC, their not paid that much.  It also seems
strange that we are prosecuting people for computer crimes not based on the
damage that they may have caused, but based on the amount of time and money
it takes to track them down or fix the systems to prevent future
unauthorized entry?  When the police arrest a robber or burglar, they are
charged based on how much they stole, not on how much money, time, and
effort it took the police to catch them.

This may be caused by our failure to develop adequate risk models for
determining the true cost of an unauthorized computer access, or the correct
valuation of electronic content?

[Reference Secure Computing, Info Security News, July 1997,
"Hacker Ordered to Pay $40,000 Restitution", page 19]

Robert J. Perillo, CCP       Richmond, VA      [email protected]

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

Date: Tue, 26 Aug 1997 21:09:43 +0100 (BST)
From: Lloyd Wood <[email protected]>
Subject: Tcl 8.0 Y2K Risk

Sun's scripting division has released Tcl 8.0, a fashionable bytecode
compiler reworking of the Tcl interpreter to help Tcl scale better.

Making it compilable required some changes in semantics, but there
were some other changes as well. In particular,

http://sunscript.sun.com/TclTkCore/8.0.html

Notes:

 There are also a few other minor incompatibilities in Tcl 8.0 and Tk 8.0:
 [..] 2.2-digit years are now parsed differently by the clock command to
 handle year 2000 issues better (years 00-38 are treated as 2000-2038
 instead of 1900-1938).

Supporting two-digit years in the first place was risky enough, but this
change is bound to catch a lot of people out.

It looks like the millennium problem may have come early for cutting-edge
Tcl scripters with legacy code.

<[email protected]>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641

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

Date: Wed, 27 Aug 1997 07:50:25 +0100
From: "Marcus L. Rowland" <[email protected]>
Subject: Photocopier codes

I work in a school where the photocopier has a 5-digit key code; each
department has its own code, so that usage can be taken from the correct
budget. We probably have about 30 codes in use. In the course of time I've
had to do work for some other departments, and have been rather surprised to
learn that all of their codes begin with the same two digits, and that in
the _majority_ of cases it is possible to enter another department's code by
transposing two digits, omitting a digit, pressing the same digit twice
instead of once, etc. I also accidentally discovered that "99999" was a
valid but unused account, probably originally used for factory testing and
never closed. Since it wasn't supposed to exist it wasn't checked during the
billing process.

All of the department codes were apparently entered by a representative of
the copier company when the machine was supplied, and have never been
changed. The reason I've been given for leaving the codes unchanged is that
nobody would remember the new codes!

The risks here should be obvious; my department's copying costs last year
exceeded UKP 2000, and will be much higher this year because paper prices
have risen. The temptation to "accidentally" enter the wrong code is
sometimes very strong. In a business environment this form of cheating might
lead to another department's projects going over budget, with effects on
promotion etc. The manufacturers of these machines, and other coded devices,
should surely know that similar codes and unused accounts are likely to
cause problems, and instruct their installation personnel accordingly. And,
of course, sites should check these matters and change the codes
occasionally, not just leave everything to the manufacturers.

Marcus L. Rowland http://www.ffutures.demon.co.uk/

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

Date: Thu, 28 Aug 1997 10:34:33 -0400 (EDT)
From: Dawn Myfanwy Cohen <[email protected]>
Subject: Oracle web server on Unix and passwords

Maybe I'm missing something because I'm kind of new to both Oracle and web
servers, but something strikes me as very wrong here.

When you install the Oracle web server on Unix, the installation guide goes
out of its way to tell you to set the umask to 022.  It then, somewhere
along the way sets up some configuration files which store some Oracle user
names and passwords in plain vanilla ASCII text.  These users correspond to
ones that own applications that should be run off the web server.  In
addition, the admin name and password for the web server itself are stored
in ASCII in these configuration files.  Depending on what exactly you are
doing with the server, your DBA name and password might also appear.

Seems kind of silly to me to go through all the contortions a DBMS goes
through to protect data only to have any old Unix user be able to get access
by just looking up some password.

You could argue that you should keep your database and Unix users on
different machines.  But first of all we don't have that luxury right now.
Second, to my knowledge there was no warning to that effect.  I don't have
time right now to experiment with seeing what breaks if I change the
protection of these files.

I guess the risks here are bad combinations of defaults ... default to store
passwords as ASCII ... default to store files as readable, etc.

--Dawn Cohen

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

Date: Fri, 29 Aug 1997 13:43:39 +0100
From: Olivier MJ Crepin-Leblond <[email protected]>
Subject: Relying on systems maintenance taking place in another time zone

The latest Network Solutions goof bumping NASDAQ off the net (Rodger,
RISKS-19.34) reminded me of Daniel Pouzzner's original post (RISKS-19.25)
describing the events when corrupted .COM and .NET DNS tables were released
at 2:30am EDT.

Obviously the idea behind releasing the files at 2:30am EDT is to minimise
the impact of updates on the geographically local network
population. Computer maintenance tasks are traditionally done at night for
that reason. The trouble with maintaining zone DNS files for the Internet is
that it's always 12 noon somewhere on the Net. So FOOBARS such as the one
described in RISKS-19.25 affected .COM and .NET users in Europe (morning
work) and Asia (daytime work) way more than in the US where most users were
asleep at that time).

It can therefore be argued that the fact that it took 4 hours before
corrected files were released, meant that European users lost 4 hours of
valuable daytime working time, while the error came-through virtually
unnoticed in the US. (apart from all of the e-mail bounces)

That's the RISK of relying on a system whose mission-critical maintenance
work takes place in another time zone.

Olivier MJ Crepin-Leblond, Ph.D. GIH Ltd, London, UK  http://www.gih.com

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

Date: 26 Aug 1997 23:33:17 -0700
From: Dave Katz <[email protected]>
Subject: Re: Spelling-checker risks (Bird, RISKS-19.34)

The piece about "Semper Fi" being corrected to "Semi-pro fiddles" reminded
me of my favorite spell check faux pas.

One of the then-unique characteristics of MTS (the Michigan Terminal System,
a now-extinct o/s for IBM mainframes in the proud academic tradition) was
that it provided a spelling corrector using a Soundex variant--if you
accidentally typed "sigon", it would respond with, "Do you mean 'Signon'?"

After James Duderstadt was named President of the University of Michigan, it
was discovered that if you typed "Duderstadt", the system would respond, "Do
you mean 'dunderhead'?"  I believe it got a new dictionary entry shortly
thereafter.

Although there was no fallout in this particular case, it does underscore
the political risks of unchaperoned spell checkers.

 [Incidentally, several readers responded that it must have been the
 spelled-out "Semper fideles" that was corrected to "Semi-pro fiddles".
 I had assumed that was obvious from context, but apparently should have
 made it more explicit by editing the contribution and spelling it out!  PGN]

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

Date: Wed, 27 Aug 1997 09:41:33 -0400
From: "ET" <[email protected]>
Subject: Mangled characters in text

In RISKS-19.33 and 19.34, I noticed the following text:

B&t.itN      [Barnes and Noble]
B&ytetN
AT&sglyT     [AT and T]

My guess is some interaction with some software in which ampersand is a
reserved character (like in HTML).  From context, it was easy to see that 4
apparently random characters were inserted after the ampersands in question.
I am curious to see what the second- and third-order mangling might produce.

 [Lots of systems and subsystems preempt commonly used characters.  PGN]

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

Date: Mon, 25 Aug 1997 12:28:59 -0700
From: "Lewis, Tony" <[email protected]>
Subject: Re: SET Risks (Svigals, RISKS-19.31)

> The SET process claims to be better than using a credit card on the
> Internet.  However, the SET process has three serious exposures - confirmed
> with IBM and HP/Verifone.  The process does NOT know who is presenting the
> certificate.

The security of SET is based on the authentication that occurs before a
certificate is issued.  Once the cardholder has obtained the certificate,
the cardholder wallet will hold the certificate and the user's password
to the wallet prevents unauthorized access.

> The process does NOT know if merchant employees have
> redirected the certificate through another merchant.

SET payment instructions identify the merchant for whom they were created.
They cannot be redirected to another merchant.

> All of the critical software is directly accessible by the card users,
> merchant employees and bank employees.  Historically, these individuals
> have been the prime source of fraud in credit-card transaction systems.

SET is designed to prevent unauthorized parties from using payment cards
on the Internet.  It protects the transaction data as it flows between
computers.  There is no way that a transaction protocol can protect the
data from illicit use once it has arrived at its intended destination.

> There are more than 50 other card security products available for Internet
> usage.  They are generally simplier, faster, and avoid the SET exposures
> identified above.  Internet transaction users might try the viable
> alternatives.  jerome svigals, [email protected]

While I do not claim to have reviewed every possible means of payment on
the Internet, it is difficult to give any credibility to this claim.

1.  In order to know who is presenting a payment card, the system would need
a foolproof identity system.  Since no such system exists on a worldwide
basis, it is impossible for any of these 50 systems to overcome the first
exposure.

2.  In order to prevent merchant employees from redirecting transactions to
another merchant, the system would have to involve three parties in the
transaction: the cardholder, the merchant and a system to ensure that both
parties are doing business with whom they intend.  Any of these 50 systems
that only involve the cardholder and merchant cannot overcome the second
exposure.

3.  Any general-purpose card security product will have some aspect of the
software available on the user's computer.  Therefore, there is no way to
protect against access by the card user.  Further, unless the card processor
has changed their authorization and clearing systems, any Internet payment
system will continue to go through legacy systems at the acquirer and issuer
so there is no protection against access by the "bank" employees.  I do
expect it is likely that most card security products will protect against
unauthorized access to data by merchant employees, however, that will be
true whether the card security product implements SET or some other
protection mechanism.

In summary, SET does not attempt to address all of the issues raised by
jerome svigals, but his claim that every other product avoids the exposures
he described is questionable.

Tony Lewis ([email protected]), Chief Systems Architect, Internet Commerce
Visa International Service Association

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

Date: Wed, 27 Aug 1997 10:33:06 +0100 (BST)
From: [email protected]
Subject: Re: SET Risks (svigals, 19.34 & Sterling, 19.33)

The concept that Mondex is some sort of panacea for Internet commerce is one
of the more blatant pieces of hype I have yet seen in RISKS, and for one of
the simplest reasons: the number of PCs with smart-card readers.

Yet, SET appears to equally unsuited to the job, for the very reasons cited.

I keep getting the feeling that the only real money that will be made on
the Internet will that that reaped by the snake-oil merchants selling the
latest and greatest commerce system.

Martin Poole  [email protected]

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

Date: Thu, 28 Aug 97 08:58:40 -0700
From: Charlie Lane <[email protected]>
Subject: Intentional analysis, re: SET risks (Svigals, RISKS-19.34 et al)

OK, lots of us are following the technical discussion about secure payment
with interest, but one aspect seems to be missing: the link to the (human)
intentions.

Here's the basic intention of a transaction: I want to make you a bit richer
(money in your account to spend) in return for you making me happier (giving
me something I want).

Now, notice that I'm not essentially concerned about who you are: the point
is that I do want to be assured that the person or organisation I am making
richer is the one that will provide me with a product.  It is the link
between product and payment that is the crux.

What I look for in a transaction is an assured offer of product for payment
(i.e., a validated advertisement) containing an assured route for payment
and an assurance that product will follow.

Unless those concerned with electronic payment tackle the whole intention
transaction from offer to receipt of product, the risks to the public will
remain.

(By the way, intentional analysis is also a big research topic in another
technical area: that of pre-analysing telecoms network services to discover
in advance any unwanted interactions, before large numbers of the public
start phoning help desks to complain.  If you can solve the intentional
analysis of transactions, you might be on the way to solving the wider
telecoms problem).

Charlie Lane

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

Date: Thu, 28 Aug 1997 09:13:29 -0700 (PDT)
From: Duane Thompson <[email protected]>
Subject: Re: USC 47:227 (Kabay, RISKS-19.34)

[...] My uninformed 2-cent comment:

My reading of USC 47:227 seems to support the argument that any unsolicited
e-mail is a violation of the section.  It defines "telephone facsimile
machine" as "equipment which has the capacity ...(B) to transcribe text or
images (or both) from an electronic signal received over a regular telephone
line onto paper."

My computer has that capacity.

Duane Thompson, Materials Management Solutions, Englewood, Colorado, USA
http://ourworld.compuserve.com/homepages/dst   <[email protected]>

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

Date: Tue, 26 Aug 1997 16:15:20 -0500
From: "Aaron M. Renn" <[email protected]>
Subject: Re: Public loo guilty of making nuisance calls

An interesting related incident.  We have a modem bank that sends faxes (not
junk, rest assured) out overnight in batch mode.  Well, during installation,
someone managed to wire two modems to the same circuit (or to cross some
wires or some such similar tragedy).  Since these modems needed do dial out
via a PBX, they had to dial "9" first.  For long distance, the next number
was a "1".  When two fax jobs kicked off at the same time, occasionally the
number sequence would end up as 9911, which dials 9 for an outside line,
then 911!  The police got called to this location every night and were not
amused.  This problem was not identified for quite some time because it was
assumed to be a software bug.  Just goes to show that our wire
infrastructure is not nearly as error free as we would like to think.

 [... A new twist on accidental 911 autodialing!  PGN]

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

Date: Wed, 27 Aug 1997 15:04:22 -0300
From: "David T.S. Fraser" <[email protected]>
Subject: Re: Tobacco Deal Could Set Precedent for Would-be Net Censors

It is important to remember that the deal reached among the various parties
in the tobacco settlement is, ultimately, a deal. As part of the give and
take of negotiation, the tobacco companies voluntarily agreed to this
restriction on their ability to advertise on the net. While it does have
precedential value for contracts and other settlements, it was not
arbitrarily imposed upon the tobacco companies by the government. A
settlement is merely a contract--voluntarily entered into--not to enforce a
claim in court. It is quite different, precedentially and constitutionally,
from a law prohibiting internet advertising of a particular product from a
foreign jurisdiction which is reachable from the jurisdiction in question.

David T.S. Fraser  Caledonia, NS, Canada  [email protected]

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

Date: Wed, 27 Aug 1997 23:48:51 -0700
From: Sam Lepore <[email protected]>
Subject: Risks of believing the obvious, though impossible

There is a risk in believing the obvious because it sounds scientific,
although it is impossible. This in turn can lead to a risk of believing
the impossible will provide you with a safety factor.

I read an article today about a solar study satellite launched into a
gravi-stationary orbit around the Earth at the point where Earth gravitation
and Sun gravitation are equalized - about 1 million miles out. The satellite
is to study solar winds, flares, and particle streams.

The article proclaimed the satellite would "give us a one hour warning of
solar storms that would otherwise not be available so sensitive ground
systems could be protected". It is obvious that the satellite will sense a
storm before it reaches Earth. But unless there is a "new physics" like
there is new math, the speed of light at which solar radiation travels is
relatively close to the speed of light at which radio emanations from the
satellite travel. So if the satellite senses a solar burst and radios its
finding, how is that signal going to get here an hour before the storm?

Oh, and at the commonly referenced speed of light, 1 million miles is
only about 6 seconds out.

Sam Lepore, San Francisco

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

Date: Thu, 28 Aug 97 14:14:34 PDT
From: RISKS List Owner <[email protected]>
Subject: Risks of believing the obvious, though impossible

Perhaps the physics are such that something in that remote environment can
more sensitively detect the early manifestations of the solar activity long
before we can from earth?

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

Date: Thu, 28 Aug 1997 22:41:57 -0700
From: Sam Lepore <[email protected]>
Subject: Risks of believing the obvious, though impossible

Well, that would be the "obvious" part of my title.  Newspapers have a
way of reporting stories without detail so that only enough is explained
to make one think you understand.  I don't.

Sam Lepore, San Francisco

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

Date: Wed, 27 Aug 1997 15:09:00 +0200 (MET DST)
From: Diego Latella <[email protected]>
Subject: ICDCS-18 call for papers

             CALL FOR PAPERS [excerpted for RISKS]
The 18th International Conference on Distributed Computing Systems
         Center of Mathematics and Computer Science (CWI)
                  Amsterdam, The Netherlands
                        26-29 May 1998

The purpose of this conference is to bring together developers and
researchers from universities, industry and government to advance the
science and technology in distributed computing.  The technical areas of the
conference include [many relevant to RISKS, including Mobile Systems,
Internet Applications, Interoperable Systems, Communication Protocols,
Fault Tolerance, Availability and Security, to name just a few.  PGN]

See http://infolabwww.kub.nl:2080/infolab/ .  Papers by 1 Oct 1997 to
Michael Papazoglou ([email protected]), Tilburg Univ., INFOLAB, PO Box
90153, 5000 LE Tilburg, The Netherlands, Phone: +31-13-466-23-49/30-20
Fax: +31-13-466-30-69,

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

Date: 1 Apr 1997 (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
  [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.35
************************

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.