Subject: RISKS DIGEST 17.42
RISKS-LIST: Risks-Forum Digest Weds 25 October 1995 Volume 17 : Issue 42
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:
Near-miss Russian atomic sub blow-up (Chen Drori)
DejaNews [Deja vu all over again] (Simson L. Garfinkel)
The UPS and downs of SCSI disks and embedded interpreters... (Peter da Silva)
Comments on AFATDS artillery control software (Eric Remy)
Risks of digital video (Craig DeForest)
Marketry Redux (Simson L. Garfinkel)
Re: Presidential Black Hawk helicopter crash [Name withheld, JdeBP)
NCSA FireWallCon '96 (Mich Kabay)
Privacy Digests (PGN)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 25 Oct 1995 11:14:17 +0300
From: Chen Drori <
[email protected]>
Subject: Near-miss Russian atomic sub blow-up
Sometime during the middle of September, I saw a report on CNN on a
barely averted atomic explosion of Russian nuclear submarines: Under the
communist regime, the Russian army was supplied with electricity, benzine,
gas, raw materials, and all other "necessary" materials that did not require
special attention, such as high-tech programs and "exotic" high-cost needs.
Since the collapse of communism, though, and the arrival of privatization,
the soviet administrative structure was changed, and now the army has to pay
for these services out of the military budget. This means that now also the
army gets an electric, gas, and what-not bill.
I am not clear on this, but it sounds reasonable, and fits well with
the story (If anyone knows better, please correct me), but as far as I
understand, when in dock, a nuclear submarine relies on outside power to run
all its needs, including the reactor cooling systems.
Enter our story: In a Russian military base, in the south of Russia,
I don't remember the exact site, a Russian base commander was forced to send
armed troops to the nearby power plant to force the local power company to
turn the juice back on at gunpoint.
The power company shut off the military's power supply on account of
the huge unpaid bill (I think it was somewhere in the order of $ 2-3
million). The sub's cooling systems failed, and the reactors began to
overheat. A nuclear explosion was closely averted.
I know there are a few flaws in the story, such as why didn't the
subs start cooling on internal power, and why did the company not give any
notice before shutting off the current (which would have sent the military
screaming at them, but then again they might have thought the power company
would never do such a thing), but that's roughly the way it was reported on
CNN.
Chen Drori, Haetzel 12, PO Box 7219, Yehud, 56214 Israel
[email protected]
Tel: 972-3-5360711 Fax: 972-3-5360711
[Relevance? Schmelevance. This item is worth including. It reminds us
that many of our problems with technology are outside of the system. PGN]
------------------------------
Date: Tue, 24 Oct 1995 19:09:53 -0400
From:
[email protected] (Simson L. Garfinkel)
Subject: DejaNews [Deja vu all over again]
Internet Services Accused of Privacy Violations
[This appeared in *The Boston Globe*, 23 Oct 1995.]
(C) 1995, Simson L. Garfinkel
Simson L. Garfinkel, Globe Correspondent
An Internet service that catalogs and indexes messages from electronic
bulletin boards is drawing criticism for possibly violating the privacy of
the network's users. DejaNews Partners taps into the Usenet global
electronic bulletin board network, makes a copy of every message, and stores
and indexes them for easy public retrieval. The service has quickly become
the fastest and most powerful way for savvy Internet users to find answers
to questions, locate lost friends, or even take the pulse of the wired
public.
Executives at San Antonio-based DejaNews seem perplexed at the near daily
messages they receive from computer users who complain that what the company
is doing amounts to an invasion of privacy. "When you post to Usenet, it
automatically gets propagated to tens of thousands of computers,'' said
Steve Madre, president of DejaNews Partners. ``So anybody who posted
something to Usenet and then later on has any kind of privacy concerns about
it must have seriously misunderstood what they were doing."
But it's not just DejaNews' archival retrieval system that has some
cybersurfers worried. It is the fact people are unaware their messages are
being archived and, perhaps even more insidious, the program's ability to
form user profiles of people who post messages -- grouping them by the
specific subject matter on which they most frequently correspond.
``No one ever mentioned to me that it was possible to take a different
program and run a search on what you've written,'' says Peter Crone, a local
graphics designer who reads Usenet through his account with The Internet
Access Company, of Bedford. ``Maybe this is as obvious as the sky being blue
to techies, but this is the first I've heard of it.'' According to
Dejanews, Crone posted three articles to the Usenet between July 27, 1995
and September 2, 1995, to the user groups "rec.arts.startrek.current,"
"rec.arts.sf.tv" and "rec.arts.sf.starwars." Thus, simply by looking up
Crone's name on DejaNews, it is possible for anybody on the Internet to
conclude that Crone is a science fiction buff, and that he likes Star Trek
and Star Wars. ``It feels a little like a phone tap or something,'' says
Crone. The Usenet system is divided into more than 10,000 such special
interest ``groups,'' each with their own self-descriptive name, such as
"rec.autos.makers.saturn," for Saturn car lovers, and
"alt.politics.usa.republican," for devotees of the Republican National
Party.
Unlike the World Wide Web, which uses the Internet to move pages of
information when requested to do so by a user, the Usenet is based upon
older technology which actually copies every message to tens of thousands of
computers throughout the world. The typical Usenet server has a billion
bytes of storage, holding hundreds of thousands of messages at a time. To
keep up with the flood of new messages, organizations usually program their
Usenet servers to delete old messages after a few weeks.
But DejaNews follows a different strategy: instead of deleting old messages,
the company archives the messages, becoming a kind of Internet memory bank.
The company hopes to support its free service by selling advertising space.
Using DejaNews, it is easy to search for every message posted on the net on
a particular subject. For example, searching for the name "Warren Buffett"
recently returned a list of 20,862 different messages, most from the Usenet
group "misc.invest.stocks." You can locate an old friend by searching for
all of the messages transmitted over the network that mention the friend's
name.
But DejaNews also has a sophisticated system for retrieving "author
profiles" of the individuals who have posted messages. Using this system,
it's easy to retrieve a list of every group in which a particular person has
posted a message -- or even the messages themselves.
Amy Bruckman, who is a graduate student at the MIT Media Laboratory and sits
on the MIT Presidential Advisory Committee on Privacy, says that her concern
with DejaNews is that most people using Usenet are not aware of the
service's existence.
But Usenet has actually been archived for a long time. Many schools, for
example, have backup tapes containing Usenet messages dating back many
years. Furthermore, says Madere, the National Security Agency and possibly
other law enforcement or intelligence organizations has been
cross-referencing and indexing Usenet for quite some time. "I know for a
fact that they do have a text retrieval database which contains Usenet,"
says Madere. Creating a searchable index of Usenet " was already done for
what people might consider to be sinister purposes," says Madere. "What we
have done is made it searchable for useful purposes."
But Bruckman says that building comprehensive author profiles represents a
further invasion beyond simply allowing searches by keyword. "There are
different levels of invasiveness of technology. Being able to record data is
one level. Being able to correlate it is another. That's why social security
numbers are such a problem -- because they make it easy to correlate large
amounts of disparate data about a person."
More people might start feeling the same way later this year, when DajaNews
starts indexing Usenet groups such as ``talk.abortion,'' in which people
exchange political opinions about abortion, and ``alt.sex.incest,'' where
people trade stories of sexual abuse. Currently, says Madere, DejaNews does
not index any Usenet group whose name begins with the letters alt, talk or
soc, although it plans to do so as soon in the near future. DejaNews can be
reached at
http://dejanews.com/.
[Well, I assume all RISKS contributors recognize that every word they
utter here gets added to the archives, going back 10+ years. That is
certainly an incentive to get your statements correct the first time. PGN]
------------------------------
Date: Wed, 25 Oct 1995 09:03:26 -0500
From:
[email protected] (Peter da Silva)
Subject: The UPS and downs of SCSI disks and embedded interpreters...
[Alan Tignanelli on ATC]
> Because of the frequency of the outages, the FAA is considering UPS.
I'm horrified.
I wouldn't consider leaving a safety-critical computer without some kind of
power failure protection. All our servers here are UPS-protected, and the
worst that can happen is we might lose a day's work if we have to go back
to backups because a disk failed due to an outage. Hell, I've even got an
UPS on my personal computer at home.
Maybe I'm oversensitized because I'm in the real-time industry. Maybe it
really is rocket science... but hey, these guys are *supposed* to be rocket
scientists.
Surely this is a misunderstanding, and they *were* on an UPS and the UPS
went down.
[Martin Minow on diagnostic software]
> My experience, however, is that modern SCSI disks are extremely reliable,
> and there isn't much cost/benefit in doing this: remember, the personal
> computer user community does not -- and should and should not -- need to
> know about technical details within their computer systems. Here, a
> comparison with modern computer-infested automobile control systems seems
> relevant: how often do you want to examine the engine logs?
Whenever I take the car to the garage, I would hope the logs would be
examined. Since a laptop isn't taken to the mechanic, the operating system
should be performing this job for me.
[and Charley Wertz on trojan horses]
> Am I missing something?
I don't think so.
> Does anyone have some good solutions?
Designing languages so they're inherently safe. For example, if there is
no "open file" primitive in the language, it can't be used to modify files.
Sun has a *separate* development going on based on a language called Tcl.
The original version of Tcl had no file I/O of note, it was purely an
extension language. I wrote some file I/O routines, and they have been
pretty much incorporated straight into the language... but they're not
integral to the operation of the interpreter. There's a variant called
Safe Tcl that's dropped back to the extension language model.
See also:
http://minsky.med.virginia.edu/sdm7g/Projects/Python/safe-tcl
And to learn how Tcl can be used in a product, look at:
http://psg.com/~joem/CmdWrite.html
There's also a Tcl web browser:
http://pastime.anu.edu.au/SurfIt/
I have no idea how good SurfIt is... I just ran into it while browsing
the web looking for URLs for this article.
------------------------------
Date: Tue, 24 Oct 1995 17:15:35 -0400
From:
[email protected] (Eric Remy)
Subject: Comments on AFATDS artillery control software (Graf, RISKS-17.41)
David identifies two main risks, both of which I feel are overstated
> AFATDS could give a "fragger" the chance to
> do a lot more damage than he/she could do just using a grenade or gun.
Very few safeguards exist today against a determined "fragger". In my
former job as a tank commander, I could have easily killed hundreds of
people while on a live fire range before my crew could have stopped me.
The only real safeguard you can take for artillery is to have multiple
people work out the solution: this is already done in peacetime on
live-fire ranges.
>Second, there are the problems of unexpected software bugs which could
>misdirect fire or even abend the entire system. Given that the consequences
>of either misdirected artillery barrages or losing artillery support
>altogether could literally be a matter of life or death.
Bugs are always a problem, however, all artillery units currently use
digital fire control computers. The software has been well tested, but I
doubt that it's bug free.
The US Army in general is very good about having backup systems.
Currently, artillery units are equipped with the BUCS- BackUp Computer
System, which looks much like a modified HP calculator. Slower and harder
to use, but still there. In addition, artillery folks are trained in pure
manual tables as well, although I don't know how much they practice with
them.
(For those who are curious, a lot of the live fire exercises Armor units
practice on are in "degraded mode", simulating failure of fire control
computers, stabilization systems, rangefinders, etc.. Very smart, IMHO)
Assuming this is the software that I've read about elsewhere, I'd push
heavily for this to be fielded ASAP. Why? Mainly because it has links
into positioning equipment such as GPS and inertial systems. Getting lost
in the desert/woods is an _enormous_ problem, and trying to direct
artillery fire when either the observer or the arty unit is in the wrong
place invites disaster. I'd feel a lot more comfortable if everyone knows
where they are, even with occasional software bugs- those can at least be
fixed ahead of time.
Eric Remy
------------------------------
Date: 24 Oct 1995 22:18:39 GMT
From:
[email protected] (Craig DeForest)
Subject: Risks of digital video (Markowitz, Re: RISKS-17.41)
Sidney Markowitz <
[email protected]> said:
: ... I have to wonder if [the recent story of a female exec's video
: email blunder] is ... urban myth. [Technical objections deleted]
Mr. Markowitz might be surprised at what can be done with computers made by
his own company. Connectix makes a $99 b/w video camera (the QuickCam) for
MacIntosh. It plugs into the serial port of a Mac, needs no additional
hardware, and comes with a large number of support applications. It can be
used to capture video or still images for attachment to mime encoded email,
or (with Columbia University's "CU See Me") to videoconference over a 14kb
slip or ppp connection. I use mine on a Powerbook 165c.
In fact, a similar event occurred to a friend of mine, the webmaster at
http://www.cliq.com. Cliq is located in one of the bedrooms of a
co-operative house one block from the Haight/Ashbury intersection in San
Francisco, and for a time they ran the "HaightCam", serving live digital
stills of Haight/Ashbury taken with a QuickCam on a Mac iici.
My friend, while prototyping the HaightCam server, left it pointed out from
his desk. His bed was in the background. One Sunday morning I was browsing
the site, and was surprised to find out more than I cared to about his
success at romance. Shortly thereafter, the HaightCam was permanently
mounted where it would point out over the street. <grin>
The point is that, with cheap digital input devices and powerful data
broadcast techniques available to everyone, one never knows when one
is in private and when one's likeness is being broadcast. Video cameras
are not new; the coming ubiquity of live broadcasting digital cameras
is.
(Meanwhile,
ftp://banneker.stanford.edu/pub/incoming/mdi.gif contains
a live image of the SOHO/MDI instrument control room at Goddard Space
Flight Center, where I'll be on Monday 10/30/95. For information
about the SOHO spacecraft, check
http://sohowww.nascom.nasa.gov.)
------------------------------
Date: Tue, 24 Oct 1995 19:09:57 -0400
From:
[email protected] (Simson L. Garfinkel)
Subject: Marketry Redux
Last week, I spoke with Norm Swent, president of Marketry, a Seattle-based
direct mail firm. Swent says that his company is not going ahead with the
e-mail target marketing because there is no way to opt out.
Marketry did not collect the e-mail addresses incidentally. An individual
did. And he is now trying to find somebody else to pay for his services.
By the way --- I've been getting 10 or so advertisements in my mailbox each
week. I guess other people have been as well. The funny thing is, the
return-addresses never work properly. They always want me to send a check to
some PO box somewhere.
------------------------------
Date: Tue, 24 Oct 1995 12:22:31 -0700
From: [Name withheld by request]
Subject: Re: Presidential Black Hawk helicopter crash
I've been following the Black Hawk crash thread with interest. I live
only a couple of miles from the crash site, and this was really big in
our local news. This is not a hoax or urban legend, the crash did
occur.
[DISCLAIMER.... I have no first hand information pertaining to the crash,
however I will summarize the points made in an ongoing series of articles
published in our local newspaper, the Maryland Independent. This series ran
a year or so ago, and my memory may be somewhat faulty. Again, I'm only
summarizing published newspaper reports...]
An amateur archeologist, (Mr. Owens?) was performing exploration of indian
ruins in a remote area in southern Maryland along the Potomac river near
Harry Diamond Research Labs (A highly secure government facility), and he
observed the crash. This individual observed the helicopter hovering
normally just above the tree tops, and then suddenly go down. He was the
first individual at the crash scene (within several minutes of the
incident), and he stated the there were serious cut injuries to the one of
the pilots legs, but that the wound had little or no bleeding, and their
skin had a yellowish cast as if burned, but that there had been no fire. He
also stated that none of the injuries he noted looked as if they would have
been fatal in the short time it took him to reach the crash scene.
Charles County deputies and rescue squad individuals responded and secured
the site, taking photographs. Some time later, military personnel arrived and
confiscated all evidence and requested that all civilian personnel leave the
accident area.
As background, the military allegedly did EMP (Electromagnetic Pulse)
testing at the Patuxent River Naval Air Station in nearby St. Mary's county
Maryland in the early 80's. This testing was supposedly moved but moved to a
location in Woodbridge, Virginia after complaints that this type of testing
was very risky, because the Calvert Cliffs Nuclear Powerplant is only a
couple of miles from PAX river NAS, and concerns of EMI possibly affecting
the plants electronic control systems were realized. (How's that for a
risk?)
After supposedly moving to the Woodbridge facility, the government began
receiving pressure to relocate the facility from Woodbridge, because
civilian aircraft on approach to National Airport (just up the Potomac river
from Woodbridge) were having EMI problems with navigation equipment. It is
believed that this project was then moved across the Potomac river to Harry
Diamond Labs, close to the accident scene. (HD lab has very tight physical
security, and is in a relatively rural area) Historically, HD labs has been
involved in high security defense related research projects. The military
currently states claims that this project has now been relocated to New
Mexico, and will make no comment on the conjecture that it ever was ever
based at Diamond Labs.
The military officially reported that a pin in the helicopter had been
installed backwards, and that was the cause of the crash. However, when
interviewed, the helicopter mechanic stated the pin was not installed
incorrectly, and his supervisor also stated that he was present during the
pin installation and it was performed correctly. Other helicopter mechanical
experts interviewed stated that if this pin was installed "backwards", that
failure should have occurred on the ground during the warm up period within a
minute or two of start up. The Black Hawk had supposedly been aloft for more
than 20 minutes, and had flown across the Potomac river, at least 7 miles
from it's base.
After Mr Owens began questioning official reports blaming the pin
installation as the cause of the crash, the military supposedly became quite
uncooperative with Mr. Owens and others interested in the crash.
Other points noted in the article.
No disciplinary action occurred to the helicopter mechanic who supposedly
incorrectly installed the pin, causing loss of life and aircraft. In a
case where loss of life occurs due to negligence, some type of
disciplinary action usually occurs.
The yellowish cast of the pilots skin and lack of any blood due to
internal coagulation was reported to be consistent with severe microwave
burns.
The attitude of the military pertaining to crash details changed
considerably when the issue of EMP testing as a possible cause of the
crash was raised by Mr. Owens and the families of the individuals lost
in the crash.
----------------------------------------------------------------------------
Date: Sat, 21 Oct 1995 19:14:03 +0100
From:
[email protected]
Subject: Re: Presidential Black Hawk helicopter crash (Coley, RISKS-17.xx)
Although many others have brought several aspects of this report into
question, with the suspicion that it is nothing more than conspiracy
theorising with no substantial base whatsoever, one issue has not been
addressed. To me, it appears to be the most obvious one :
How come an *archaeologist*, only present at the scene of the accident by
chance, seems to know so much about the design of military aircraft and the
investigative procedures used in aircraft crashes ?
In the true spirit of conspiracy theory, should we not assume that since
Mr Owens (assuming that that such a person exists) was so conveniently near
to hand at the time of the accident that he is in some way related to it ?
Could it not be that he is in the employ of the people that *really* caused
the crash, and is masquerading as an innocent bystander who embarks upon a
baseless but nevertheless high-profile crusade about Army helicopters and
EMI, in order to distract attention away from the real cause ?
------------------------------
Date: 25 Oct 95 11:41:33 EDT
From: "Mich Kabay [NCSA Sys_Op]" <
[email protected]>
Subject: NCSA FireWallCon '96
Here is the short form of the current program and registration information
for FireWallCon '96. For the complete and most up-to-date version of this
program, send any message via e-mail to the NCSA infobot using address:
[email protected] .
FireWallCon '96
Stouffer Hotel, Arlington, VA
Jan 25-26, 1996
CONFERENCE OVERVIEW
The Firewall and Internet Security Conference (FireWallCon '96) is NCSA's first
international conference dedicated to the exchange of ideas, policies, and
methodologies for implementing practical Internet security.
FireWallCon '96 will bring together international experts to address the key
issues in this rapidly evolving field. We will also provide a forum where
attendees can exchange in-depth technical information with the major Internet
Security/Firewall product developers.
NCSA Firewall and Internet Security Conference Program (Abbreviated)
Thursday, Jan 25:
9:00 - 10:30 The Electronic Intrusion Threat on the Internet
Moderator: Ted Phillips/Booz-Allen Hamilton
David Slade, AT&T
Steve Branigan, Bellcore
11:15 - 12:00 Identifying System Vulnerabilities
Christopher Klaus, ISS
12:00 - 1:30 Lunch with Keynote TBD
1:45 - 2:30 Introduction to Internet/Firewalls
William Hugh Murray, Deloitte-Touche
3:00 - 3:45 Establishing an Internet Security Policy
Stephen Cobb, NCSA
4:00 - 4:45 Evaluating Firewalls
Tammy Mannarino, National Security Agency
5:00 - Reception
Friday, Jan 26:
9:00 - 10:30 Establishing an Emergency Response Team
Moderator: Alan Fedeli, Manager, IBM CERT
11:15 - 12:00 Viruses and Other Malicious Software on the Internet
Dr. Richard Ford, NCSA
12:00 - 1:30 Lunch with Keynote TBD
1:45 - 2:30 Security on the World Wide Web
Larry J. Hughes, Jr., Indiana University
3:00 - 3:45 Connecting to the Net Securely Without UNIX
Moderator: Charles Rutstein, Price Waterhouse
4:00 - 4:45 Social Engineering: The Non-Technical Threat
Ira Winkler, SAIC
VENDOR TRACKS
In addition to the technical track, there will be two parallel vendor
tracks. Firewall and Internet security vendors will be afforded the
opportunity to make technical product presentations. We anticipate having
20 such vendor presentations. Specific information about these
presentations is not yet available. Up-to-date information about the entire
program may be obtained by sending any e-mail message to:
[email protected]
.. [details omitted for posting on RISKS] ... [TNX! PGN]
For more information about NCSA conferences, courses and services:
WWW:
http://www.ncsa.com
CompuServe: GO NCSA
E-mail:
[email protected] (send blank message)
M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA)
------------------------------
Date: 24 October 1995
Subject: Privacy Digests
Periodically I will remind you of TWO useful digests related to privacy,
both of which are siphoning off some of the material that would otherwise
appear in RISKS, but which should be read by those of you vitally interested
in privacy problems. RISKS will continue to carry general discussions in
which risks to privacy are a concern.
* The PRIVACY Forum is run by Lauren Weinstein. He manages it as a rather
selectively moderated digest, somewhat akin to RISKS; it spans the full
range of both technological and non-technological privacy-related issues
(with an emphasis on the former). For information regarding the PRIVACY
Forum, please send the exact line:
information privacy
as the first text in the BODY of a message to:
[email protected]
You will receive a response from an automated listserv system. To submit
contributions, send to "
[email protected]".
Information and materials relating to the PRIVACY Forum may also be
obtained via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com",
and World Wide Web via: "
http://www.vortex.com".
* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Leonard P. Levine. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
[email protected] and administrative requests to
[email protected].
There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places. If you are very
short of time and can scan only one, you might want to try the former. If
you are interested in ongoing discussions, try the latter. Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.
PGN
------------------------------
Date: 6 September 1995 (LAST-MODIFIED)
From:
[email protected]
Subject: ABRIDGED info on RISKS (comp.risks)
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <
[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
RISKS can also be read on the web at URL
http://catless.ncl.ac.uk/Risks
RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]
------------------------------
End of RISKS-FORUM Digest 17.42
************************
