precedence: bulk

precedence: bulk
Subject: Risks Digest 19.86

RISKS-LIST: Risks-Forum Digest Thursday 16 July 1998 Volume 19 : Issue 86

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

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at http://catless.ncl.ac.uk/Risks/19.86.html

Contents:
Navy software problems (Michael Stutz via Jim Horning)
Still more on TWA flight 800, re: Elaine Scarry (PGN)
More Java woes (Edward Felten)
Re: Premature airbagulation (Fernando Pereira)
Virus myths (Lindsay F. Marshall)
More on TACDFIPSFKMI and malicious mobile code (Rachel Chalmers)
How to cite Risks Digest *and* maintain human knowledge (Eran Gabber)
ACM CCCS'98: Preliminary Program and Call for Participation (Gene Tsudik)
REVIEW: "Java Security", Scott Oaks (Rob Slade)
David Brin: Choosing between privacy and freedom? (Warren Monroe)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 16 Jul 98 12:09:00 P
From: Jim Horning <[email protected]>
Subject: Navy software problems

Navy Software Dead in the Water, by Michael Stutz, 16 Jul 1998
[http://www.wired.com/news/news/technology/story/13758.html]

If you think Windows 98 is an upgrade nightmare, consider the task of adding
a new combat system to a Navy cruiser. Last week the US Navy acknowledged
that two prized battle cruisers (the USS Hue City and the USS Vicksburg)
will be out of commission until further notice as engineers try to integrate
new onboard weapons-control systems. "Microsoft comes out with upgrades
every three years, and they crash all the time," said one Navy source, who
spoke on condition of anonymity. "The Navy comes out with upgrades every
five years, but we can't afford for our systems to have any glitches, so we
have to make sure that we get it just right."

The heart of the problem lies with two new systems being built into the
ships. The Aegis Baseline 6 system helps defend the vessels against air
attacks, and the Cooperative Engagement Capability (CEC) system gathers and
shares radar data from multiple ships. Engineers are having trouble getting
the new systems to work with each other and with the ships' legacy software.

[Aegis is written in Ada and C++ and other languages, with the latest
upgrade reaching 8M lines of code, up from 3M. Installation is taking much
longer than expected. The problems are largely in integration and
interoperation, including a new display system, and are compounded by the
Navy not having source code. PGN Stark Abstracting]

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

Date: Wed, 15 Jul 98 15:05:27 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Still more on TWA flight 800, re: Elaine Scarry

There was some discussion in RISKS-19.64,65,66 on Harvard professor Elaine
Scarry's theory ({\it New York Review of Books,} 9 Apr 1998) that the TWA
800 disaster involved High Intensity Radiation Fields. An article in
*Harvard Magazine*, Jul-Aug 1998, p. 11-12, shows a diagram of TWA 800 at
13,700 feet between a P3 Orion overhead at 20,000 feet and a Black Hawk
helicopter and HC-130 aircraft both below at 3,000 feet. The figure also
includes a C-141 and C-10 known to be nearby, and three submarines south of
the crash, each at locations still not released to the public!)

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

Date: Wed, 15 Jul 1998 10:33:47 -0400
From: Edward Felten <[email protected]>
Subject: More Java woes

We have found another Java security flaw that allows a malicious applet to
disable all security controls in Netscape Navigator 4.0x. After disabling
the security controls, the applet can do whatever it likes on the victim's
machine, including arbitrarily reading, modifying, or deleting files. We
have implemented a demonstration applet that deletes a file.

This flaw, like several previous ones, is in the implementation of the
"ClassLoader" mechanism that handles dynamic linking in Java. Despite
changes in the ClassLoader implementation in JDK 1.1 and again in JDK 1.2
beta, ClassLoaders are still not safe; a malicious ClassLoader can still
override the definition of built-in "system" types like java.lang.Class.
Under some circumstances, this can lead to a subversion of Java's type
system and thus a security breach.

The flaw is not directly exploitable unless the attacker can use some other
secondary flaw to gain a foothold. Netscape 4.0x has such a secondary flaw
(a security manager bug found by Mark LaDue), so we were able to demonstrate
how to subvert Netscape's security controls. We are not aware of any usable
secondary flaws in Microsoft's and Sun's current Java implementations, so
they appear not to be vulnerable to our attack at present.

Please direct any inquiries to Edward Felten at (609) 258-5906 or
[email protected].

Dirk Balfanz, Drew Dean, Edward Felten, and Dan Wallach
Secure Internet Programming Lab, Department of Computer Science
Princeton University http://www.cs.princeton.edu/sip

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

Date: Wed, 15 Jul 1998 00:00:47 -0400
From: [email protected] (Fernando Pereira)
Subject: Re: Premature airbagulation

When airbags were pushed on the industry and the public as a risk-free
safety measure, none of the subsequently found dangers and costs of airbags
were taken into consideration in the cost-benefit analysis. In addition to
the problems described in that story, there have been the deaths and
injuries of children and small adults caused by fast-inflating
airbags. Airbags also increase the cost of vehicles, increase their
maintenance costs, and have become an attraction to car-part thieves.
Airbag supporters continue to counter with claims about lives saved by
airbags, but I have never seen estimates of how many of those lives would
have been saved by properly-used seatbelts. The regulatory imposition of
airbags forced the added costs and risks of an automated system on a large
population partly to deal with the deaths and injuries of those unwilling to
use a lower-cost, lower-risk manual system. Besides the standard tale of
unintended consequences --- safety measures creating their own risks -- we
also have here a good example of the risks of pushing sweeping regulatory
and mechanical solutions for problems that have already serviceable
unintrusive solutions, but ones that require a modicum of human care
(cf. keeping inappropriate content away from children, keeping networked
computers reasonably secure, avoiding spam relaying).

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

Date: Thu, 16 Jul 1998 10:02:19 +0100 (BST)
From: "Lindsay F. Marshall" <[email protected]>
Subject: Virus myths

A useful page summarising many virus hoaxes can be found at:
<URL:http://kumite.com/myths/>

http://catless.ncl.ac.uk/Lindsay

[BTW, Thanks to Lindsay for the UK RISKS redistribution. PGN]

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

Date: Tue, 14 Jul 1998 17:22:54 -0700
From: Rachel Chalmers <[email protected]>
Subject: More on TACDFIPSFKMI and malicious mobile code

I wouldn't normally submit my own articles out of a fetching humility on my
part, ho ho. But as it happens these two address questions raised in the
last Risks digest, one on the malicious mobile code consortium, the other on
the TACDFIPSFKMI. So I though I might bring them to your attention. Rachel

1. CONSORTIUM PLANS TO ADDRESS MALICIOUS APPLETS

The International Computer Security Association (ICSA) has formed a
Malicious Mobile Code Consortium to address the threat of hostile ActiveX
controls and Java applets. The list of charter members is an A to Z of
anti-virus and intrusion detection companies, including Advanced Computer
Research, Axent, CA, Cybermedia, Digitivity, Dr Solomon's, eSafe, Finjan,
Internet Security Systems, Quarterdeck, Security-7, Symantec and Trend
Micro, with more companies expected to join. At first glance it seems a
little unfair to lump carefully sandboxed Java, designed to wreak no harm,
with the nightmarish security free-for-all that is ActiveX. Product
development manager Larry Bridwell argues: "Even with the sandbox, - and we
want it to be known that we think Sun has done an excellent job in
considering security - there is occasionally a chink in Java's armor."
Experts beg to differ. "As far as I know, there have been no legitimate
reports of Java viruses written in the wild," says Rob Rosenberger,
webmaster of the Computer Virus Myths home page. "On the other hand, it's
beautifully easy to do it in ActiveX." Rosenberger cites Princeton computer
scientist Ed Felton, founder of the Secure Internet Programming Laboratory,
who says he's never bothered to test the security of ActiveX. "He says he'd
just have to write one virus in it and they'd be done. ActiveX is child's
play." The problem is one of perception: "People see Java and ActiveX as
two ways to get stuff on the internet," Rosenberger explains, "you're
talking about apples and oranges, but people only see fruit. Java poses a
theoretical threat. ActiveX is an actual threat." While Bridwell concedes
that there have been no documented cases of security breaches via Java, he
says he believes such attacks are on their way. "It almost appears that we
are in the infancy of malicious mobile code, just as in the late eighties
we saw the infancy of viruses written in auto-executable code," he
contends. "The problem is that you have increased connectivity and much
larger numbers of people." Even if viruses do start getting written in
Java, how much real harm are they likely to do? Most current viruses - Word
macros, for example - are easily trapped and prevented, causing little more
than a nuisance. Bridwell, however, says the problem is one of scale: "Our
survey shows that something that doesn't cause actual physical damage to
data can still cause thousands of dollars in downtime and associated
costs," he says. The ICSA surveyed IT managers at 300 organizations, each
with a minimum of 500 computers, two LANs and two remote connections. A
single virus attack costs these companies an average of $8,000; in two
instances, an attack cost more than $100,000. Maybe there is a role for the
consortium after all.

2. COMMITTEE SAYS KEY RECOVERY IS TOO HARD

A Technical Advisory Committee charged with developing a Federal standard
for recovering cryptographic keys has told the US Secretary of Commerce of
technical difficulties that will prevent it reporting on time. That's a blow
to government officials - not least FBI director Louis Freeh - who want to
see key recovery made mandatory, so the government can recover encrypted
information and make life difficult for organized crime. This Committee
inherited those expectations from an earlier, failed attempt to mandate key
escrow: the Clipper Chip (CI No 3,395). Reuters says it "obtained" the
letter to Commerce Secretary William Daley. That's a little disingenuous of
the wire service, since the letter is freely available from the NIST web
site along with the incomplete draft of the committee's report. In spite of
having published its work, though, the euphoniously named Technical Advisory
Committee to Develop a Federal Information Processing Standard for the
Federal Key Management Infrastructure, or TACDFIPSFKMI, says in its letter:
"We believe this document is not ready to be released for public comment."
The draft certainly does make fascinating reading. The most recent set of
changes, made by Steve Kent, chief scientist at GTE Internetworking, clearly
alters the emphasis of the document. The word 'standard' is replaced
throughout by 'product'. A passage describing the consequences of not having
key recovery has been softened. The document no longer states that it is
"necessary to ensure" that data can be decrypted by "authorized
parties". Instead, the writers say they want to establish "requirements for
Key Recovery products." The document has is now not so much a detailed
technical standard as a purchasing guide. Kent concurs with this
interpretation: "Most of these [Federal Information Processing Standards]
are used for procurement purposes... Those changes were made by the
committee specifically because we wanted not to make it a policy statement."
So, will the private sector also be required to adopt key recovery?
"Technically a FIPS is just for Federal agencies," says Kent, "in the past,
industry has latched onto some of these even if they are in no way required
to do so." If the key recovery FIPS is ever completed, vendors can expect to
be very strongly encouraged to build their crypto software with a back door
for officers of the law. However as the Committee explained in its letter,
various problems make it unlikely that TACDFIPSFKMI, or as it prefers to
call itself, "Bob", will meet its July deadline. "The technical difficulties
were subtle details," Kent said, citing conflicts between the separate
working groups drawn together only a few months ago. But observers are
skeptical. "It can't be done," says Counterpane Systems' Bruce Schneier,
"but they don't know that." University of Auckland computer scientist and
co-moderator of the sci.crypt.research newsgroup Peter Gutmann agrees: "The
trouble is that what they're trying to do is beyond the state of the art,"
he says. What's more, Schneier believes the Committee with the 12-letter
acronym has been given its impossible job for exactly the wrong
reasons. "The US government has been telling everyone that key recovery is
what industry wants. Whenever industry gets together they say they don't
want it. Then the FBI steps in and says that's not acceptable." Why is Louis
Freeh so anxious to be given the power to recover crypto keys? "We're not
actually sure," Schneier admits, "it's extremely expensive, it's difficult,
and from all that we can establish, encryption is not actually a problem in
Federal investigations. You could hire a few hundred FBI agents for what key
recovery would cost. It's hard to believe that some amorphous technology
that criminals can get around anyway would be better than a few hundred more
FBI agents." Most critics of key recovery say it is another example of
unjustified government surveillance of private life on the pretext of
preventing crime. "Sure, cryptography is open to misuse," says Schneier,
"just like kitchen knives, ladders and the interstate highway systems. Yes,
criminals can use ladders to commit a crime. But I still like having
ladders." Schneier believes the government will never have its way with key
escrow. Gutmann is not so optimistic. "There will be creeping law changes.
First building key recovery in will be voluntary. Then it will be
mandatory," he says. "What makes it hard at the moment is that there is no
infrastructure. In five years, when the infrastructure is there, it will be
just a matter of changing the law." Though the committee's charter does
expire next month, the 22 members have declared themselves ready to carry on
if their country demands. So no Son of Clipper Chip today, but the show is
far from over. As Gutmann says: "The government just keeps sugar-coating the
poison pill by giving it a different name."

Deputy Internet Editor, ComputerWire Inc, 150 Post Street, San Francisco,
CA 94108 (415) 274 8290 http://www.computerwire.com Fax: (415) 274-8281

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

Date: Mon, 13 Jul 1998 18:39:50 -0400 (EDT)
From: Eran Gabber <[email protected]>
Subject: How to cite Risks Digest *and* maintain human knowledge

I recently wrote a paper (together with Avishai Wool), and we included a
citation to RISKS. The referees and the program-committee shepherd insisted
that we replace URLs by ``paper'' citations. That was a problem, since a
few of the citations in the paper where collected from the Web, and some
URLs will probably never be published in the traditional sense.

The program committee (and Peter Neumann) finally agreed that the following
citation is appropriate for RISKS forum:

[Ris98] [email protected] (AIMS / Intel-Info).
Two known GPS jamming cases.
RISKS Forum Digest, vol. 19, no. 74, May 1998.
USENET comp.risks,
Peter G. Neumann, moderator, Computer Science Lab, SRI International,
Menlo Park CA 94025 USA.
Archived at http://catless.ncl.ac.uk/Risks/19.74.html
and ftp.sri.com in directory "risks".

However, this incident raises a more fundamental question: How do we
maintain human knowledge in the age of the Internet? In previous
generations, scholarly publications consisted of printed journals and books,
which were kept in libraries for use of future scholars. Today this method
is mostly replaced by placing the information on your home page or on your
company's Web site. There is a real problem of preserving and referring to
this information in the future, especially as this information may be
modified (and the original is lost), moved, or disappear
altogether. Companies do fail and merge, and today's Web sites may not exist
10 years from now.

Publishing on the Internet is the future, and we cannot ignore it.
We need ways to maintain permanent knowledge in this new age.

My suggestion is that professional societies (like ACM, IEEE and USENIX)
should provide archival services for their own publications and for other
sources of scholarly information (e.g. moderated newsgroups).

The charter of professional societies should change too. They should:
a) maintain the high standards of publications; encourage exchange of
information; support worthy projects and recognize individuals that
advance the human knowledge in the particular field.
b) publish electronic versions of journals (with same refereeing process
as today to ensure quality)
c) organize conferences (with same refereeing process as today to ensure
quality)
d) set standards and influence policies
e) archive society sponsored material, such as conference proceedings,
journals, and other information deemed important (like moderated news
groups).
f) present summaries of the information in readily accessible forms for
an extra fee (either paper copies - like today's journals and
conference proceedings), or a Web pages that resembles the layout of a
printed journal, or other forms.
g) provide permanent storage for unmoderated information provided by
their members. Each member will be allowed to publish a certain
amount of new information per year. This information will stay in the
archive as long as the archive exists.

The revenue of professional societies would decrease, since members would
pay a flat membership fee for an unlimited access to the archives. However,
the expenses would decrease too, since there will be no need for printing
and mailing. Note that the refereeing process is done by volunteers, and it
will not be changed. Another (small) revenue stream will be the surplus from
conferences.

All members of professional societies as well as institutional subscribers
(i.e. libraries) should get a periodic CD-ROM (or another ubiquitous,
capacious, permanent, and cheap electronic medium) containing recent
additions to the archives. This would solve the survivability and
availability of the material for future scholars. The CD-ROM should include
only publications and moderated material, and not unmoderated material
placed by individual members.

The question of CD-ROM longevity and availability of CD players and software
readers in the future is still open.

Eran Gabber, Lucent Technologies - Bell Labs.

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

Date: Thu, 16 Jul 1998 11:08:43 -0700 (PDT)
From: Gene Tsudik <[email protected]>
Subject: ACM CCCS'98: Preliminary Program and Call for Participation

Preliminary Program (edited for RISKS)
Fifth ACM Conference on Computer and Communications Security
San Francisco, California, 2-5 Nov 1998, Sponsored by ACM SIGSAC
For more information visit http://www.research.att.com/~reiter/ccs5

=== Monday, November 2, 1998

Tutorials Core Topics Emerging Topics

9:00-12:30 Cryptography: Theory and Programming Languages and Security
Applications Martin Abadi (DEC Systems Research
Dan Boneh (Stanford Center, USA) and George Necula
University, USA) (Carnegie Mellon University, USA)
13:30-17:00 To Be Determined Authentication Protocol Verification
and Analysis Jon Millen
(SRI International, USA)
=== Tuesday, November 3, 1998

9:00-10:00 Keynote address
Risks and challenges in computer-communication infrastructures
Peter G. Neumann (SRI International, USA)

10:30-12:00 Group key management

Communication complexity of group key distribution
Klaus Becker (R^3 Security Engineering, Switzerland) and Uta
Wille (IBM Zurich Research Laboratory, Switzerland)

Key management for encrypted broadcast
Avishai Wool (Bell Labs, USA)

Authenticated group key agreement and related protocols
Giuseppe Ateniese (USC Information Sciences Institute, USA),
Michael Steiner (IBM Zurich Research Laboratory, Switzerland),
and Gene Tsudik (USC Information Sciences Institute, USA)

13:30-15:30 Anonymity

The design, implementation and operation of an e-mail pseudonym server
David Mazie`res and M. Frans Kaashoek (Massachusetts
Institute of Technology, USA)

Panel: Anonymity on the Internet
Moderator: Paul Syverson (Naval Research Lab, USA)

16:00-17:00 Mobile code security

History-based access-control for mobile code
Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of
California, Santa Barbara, USA)

A specification of Java loading and bytecode verification
Allen Goldberg (Kestrel Institute, USA)

=== Wednesday, November 4, 1998

9:00-10:30 Cryptography

A new public key cryptosystem based on higher residues
David Naccache (Gemplus, France) and Jacques Stern (Ecole
Normale Superieure, France)

An efficient non-interactive statistical zero-knowledge proof
system for quasi-safe prime products
Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele
Micciancio (Massachusetts Institute of Technology, USA), and
Tal Rabin (IBM T.J. Watson Research Center, USA)

Communication-efficient anonymous group identification
Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni
Di Crescenzo (University of California, San Diego, USA)

11:00-12:00 Invited talk
The development of public key cryptography
Martin Hellman

13:30-15:00 Systems

A security architecture for computational grids
Ian Foster (Argonne National Laboratory, USA), Carl Kesselman,
Gene Tsudik (USC Information Sciences Institute, USA), and
Steven Tuecke (Argonne National Laboratory, USA)

Design of a high-performance ATM firewall
Jun Xu and Mukesh Singhal (Ohio State University, USA)

A practical secure physical random bit generator
Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs,
USA) and Ari Juels (RSA Labs, USA)

15:30-16:30 Invited talk
Trust in cyberspace? A research roadmap
Fred Schneider (Cornell University, USA)

=== Thursday, November 5, 1998

9:00-10:30 Protocol design and analysis

A probabilistic poly-time framework for protocol analysis
Pat Lincoln (SRI International, USA), John Mitchell, Mark
Mitchell (Stanford University, USA), and Andre Scedrov
(University of Pennsylvania, USA)

On using public-key cryptography in password protocols
Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo
Krawczyk (Technion, Israel)

Cryptanalysis of Microsoft's point-to-point tunneling protocol
Bruce Schneier (Counterpane Systems, USA)

11:00-12:00 System monitoring

How to prove where you are
Eran Gabber and Avishai Wool (Bell Labs, USA)

Temporal sequence learning and data reduction for anomaly detection
Terran Lane and Carla E. Brodley (Purdue University, USA)

Steering committee chair: Ravi Sandhu, George Mason University
General chair: Li Gong, JavaSoft
Program chair: Mike Reiter, AT&T Labs, Room A269, 180 Park Avenue
Florham Park, NJ 07932-0971 USA, phone: +973-360-8349
For more information, visit http://www.research.att.com/~reiter/ccs5

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

Date: Fri, 10 Jul 1998 11:11:58 -0800
From: Rob Slade <[email protected]>
Subject: REVIEW: "Java Security", Scott Oaks

BKJAVASC.RVW 980520

"Java Security", Scott Oaks, 1998, 1-56592-403-7, U$32.95/C$46.95
%A Scott Oaks [email protected]
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 1998
%G 1-56592-403-7
%I O'Reilly & Associates, Inc.
%O U$32.95/C$46.95 707-829-0515 fax: 707-829-0104 [email protected]
%P 456 p.
%T "Java Security"

As the author notes, security means many different things to many different
people. In the general public, Java security tends to mean browser and
applet security, and the default applet "sandbox." Therefore I feel obliged
to point out that this book is primarily concerned with the programming of
security into systems, and the security APIs (Applications Programming
Interfaces) built into the language to ease that task.

Chapter one looks at the overall security model for Java, and particularly
at the invocations of programs. Basic enforcement and verification is
covered in chapter two. Class loaders, in chapter three, provide the
programmer with a means to specify an almost arbitrary level of security
protection for a program. Chapter four details the workings of the security
manager, again providing the programmer with the ability to set specific
protections. The access controller is new to Java 1.2, is the mechanism
that the security manager now uses to actually permit or deny use of
resources, and the object calls are discussed in chapter five.
Implementation of access and security policies through the class loader and
security manager is covered in chapter six.

Chapter seven looks at the need for authentication over open networks, and
the security provisions of digital signatures. The discussion of
cryptography itself is essentially non-existent since, as Oaks notes, it is
not necessary to understand it in order to use it. Those who wish to test
or implement strong encryption will need to go elsewhere. Implementation of
standard cryptographic protection is via security providers, reviewed in
chapter eight. Some simple message digest implementations are described in
chapter nine. Key management is an important part of cryptography so
chapter ten deals with keys and certificates while chapter eleven reviews
the handling of them. Chapter twelve looks at the functions provided for
dealing with digital signatures. Specifics for encryption are listed in
chapter thirteen.

Appendices deal with security tools, identity-based key management,
resources, and a quick reference chart.

While the book is well written it is not light, and is probably best suited
to those who are well familiar not only with Java programming, but also the
internals of the language. On the other hand, dealing with security is a
great way to learn the internals of a language.

copyright Robert M. Slade, 1998 BKJAVASC.RVW 980520

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

Date: Thu, 09 Jul 1998 13:48 -0700 (PDT)
From: [email protected]
Subject: David Brin: Choosing between privacy and freedom?

This today from "Amazon.com Delivers Cyberculture" (haven't read it yet or
even seen any other reviews, but have ordered it):

"The Transparent Society: Will Technology Force Us to Choose
Between Privacy and Freedom?"
by David Brin
http://www.amazon.com/exec/obidos/ASIN/020132802X

"The Transparent Society" is David Brin's call for what he terms reciprocal
transparency. With the Net and countless other technological wonders eating
away at our privacy, worry about the erosion could cause a backlash of
secrecy-- or at least the illusion of it, because the government, the
powerful, and criminals will find a way to keep their eyes on us. Instead,
Brin asks us to demand accountability and keep the good aspects of
technology by opening windows both ways rather than building walls that
don't really keep anyone out.

Warren Monroe <[email protected]>

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

Date: 31 Mar 1998 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS

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

End of RISKS-FORUM Digest 19.86
************************