[1465] in RISKS Forum
Risks Digest 20.34
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed Apr 28 21:46:07 1999
From: RISKS List Owner <risko@csl.sri.com>
Date: Wed, 28 Apr 99 18:43:10 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Weds 28 April 1999 Volume 20 : Issue 34
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 <URL:http://catless.ncl.ac.uk/Risks/20.34.html>
and at ftp.sri.com/risks/ .
Contents:
Virus infects computers worldwide (Edupage)
A genuine sighting of a virus -- for once (Nick Brown)
Sex aid give holiday flight a shaky start (Frank Markus)
A Supreme Indecency (Monty Solomon)
Bar says e-mail OK for transmissions (Monty Solomon)
You'd think they'd know better... (T Bruce Tober)
A man charged with counterfeiting bank ATM cards (Chiaki Ishikawa)
What's DejaNews up to? (Richard M. Smith)
Dodgy automatic address book resolution (Samuel Liddicott)
Re: GUIDs and Melissa (Russ Cooper)
REVIEW: "Great Misadventures", Peggy Saari (Rob Slade)
Open Source Software at 1999 USENIX Annual Conference (Jennifer Radtke)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 28 Apr 1999 12:41:33 -0600
From: Edupage Editors <edupage@franklin.oit.unc.edu>
Subject: Virus infects computers worldwide
The Chernobyl virus yesterday attacked more than 600,000 home, office, and
government computers around the world, causing an estimated hundreds of
millions of dollars in damage. The virus, which struck on the 13th
anniversary of the Chernobyl nuclear explosion and is named for the
disaster, is believed to have its roots in Taiwan. Windows 95 and Windows
98 files are attacked by the virus, which tries to erase the hard drive and
prevent the computer from being booted. However, no large-scale system
failures have been reported. In the United States, reports of 2,328
infected computers at 228 locations were made to the Computer Emergency
Response Team at Carnegie Mellon University. The most severely impacted
country appears to have been South Korea, where as many as 300,000 computers
were affected by the virus. The virus may have damaged as many as 15
percent of all computers in South Korea, and could cost the country $250
million, according to a South Korean news agency's quotes of industry
experts. In Turkey, computers were affected at an airport, a military
academy, the state-run radio and television station, and several banks.
Electronics engineer Mustafa Ucoklar says Turkey was caught unprepared and
the country had not taken notice of warning signs. (*The Washington Post* 28
Apr 1999; Edupage, 28 Apr 1999)
------------------------------
Date: Tue, 27 Apr 1999 09:20:40 +0200
From: BROWN Nick <Nick.BROWN@coe.int>
Subject: A genuine sighting of a virus -- for once
I dropped into my friendly neighbourhood computer dealer last night to find
not one but two guys standing there with their PCs. Both with the same
symptom - CIH/Chernobyl had trashed their BIOS. For once, a virus really
struck ! That's two in one day in Molsheim, France (pop 8,000).
One of the PCs was from the shop itself, and the owner was obviously a
hacker. He took it in reasonable spirits, although round here he'll
probably be $75 down for a new BIOS chip. The other was from a local
hypermarket, seven months old. I suggested to the owner that he take it
back to the shop under warranty. This kind of store can't do proper
after-sales for software problems, of course, but they might be persuadable
that a completely black screen at startup could be a broken motherboard.
In fact, it would be interesting to see what various countries' consumer
laws make of "my BIOS was trashed by a malicious program, and my PC no
longer boots". PC stores (and corporate support desks) already have quite
enough people expecting them to fix problems caused by screwing around with
OS files, but how responsible can someone be for the care of their BIOS
chip?
The RISK ? Well, apart from the obvious virus-related ones, there's the
problem of getting repairs under warranty in those grey areas between "the
system broke" and "you broke the system".
Nick Brown, Strasbourg, France
------------------------------
Date: Sun, 25 Apr 1999 06:26:07 -0400
From: "Frank Markus" <fmarkus@pipeline.com>
Subject: Sex aid give holiday flight a shaky start
A pilot made an emergency landing when a suspect device was detected on a
jet packed with British holiday makers -- but the threat turned out to be a
sex-aid vibrator.
The A-300 Monarch Airbus was two hours into a flight from Goa when the crew
became suspicious about a piece of hand luggage. The pilot, Captain Dave
Johnson, radioed a bomb alert and was ordered to divert to Bombay.
The plane, carrying British-based passengers and crew, was taken to an
isolated handling bay where 369 people were evacuated.
Bomb disposal experts boarded the plane and examined the suspect baggage and
identified the device as a battery-powered sex vibrator.
A Monarch Air spokeswoman applauded Capt Johnson's actions. "We are looking
into the incident to find out how it got on board," she said. The passengers
later continued to Gatwick.
I initially found this story in rec.travel.airlines on Usenet. I followed
the links in that message to the actual article (above, Tuesday April 20,
11:01 AM). The next message posted was from an airline ramp agent:
"Actually, this kind of thing happens way too often.
I used to work for a major airline as a ramp agent, and I'd put the
number at 2-3 times per year, per airline.
What happens is a bag (usually checked though) gets jostled, and
vibrator switches on, bag starts buzzing or humming, employees alert
security, and then the real fun begins.
"Our SOP used to be offload pax, have them claim baggage on ramp, then
swoop in on suspicious bag. have pax reveal source of buzz, worst
embarrassment of life ensues, in front of planeload of angry, delayed
strangers. It was ALWAYS the best part about working the ramp. And this
should serve as a cautionary note, pack the batteries separate if
traveling with a vibrator."
I love this story. It has everything that is required for an urban legend
but it is true. The original story is still available at:
http://www.yahoo.co.uk/headlines/19990420/london/newsstory133839.html
[I thought maybe the "vibrator" was related to the vi editor,
since "vi" is s*x in Roman numerals. PGN]
------------------------------
Date: Wed, 28 Apr 1999 10:57:32 -0400
From: Monty Solomon <monty@roscom.com>
Subject: A Supreme Indecency
Congress tried to make it a felony to say anything "indecent" online
"with intent to annoy" another person. The Supreme Court has just
decided the appeal in the case testing the law.
It had to be the shortest Supreme Court decision on the merits of a
First Amendment issue ever: "The judgment is affirmed." ApolloMedia
Corp. v. Reno, No. 98-933 (April 19, 1999).
http://www.lawnewsnetwork.com/opencourt/stories/A939-1999Apr27.html
------------------------------
Date: Wed, 28 Apr 1999 10:50:33 -0400
From: Monty Solomon <monty@roscom.com>
Subject: Bar says e-mail OK for transmissions
The American Bar Association has given its seal of approval to the use
of e-mail to transmit client documents.
Under most circumstances, a lawyer does not violate a client's
confidentiality by transmitting documents via unencrypted electronic mail,
the ABA Standing Committee on Ethics and Professional Responsibility
concluded in an ethics opinion announced last week.
http://www.lawnewsnet.com/stories/A953-1999Apr27.html
------------------------------
Date: Sun, 25 Apr 1999 13:13:34 +0100
From: T Bruce Tober <octobersdad@reporters.net>
Subject: You'd think they'd know better...
...or maybe not. I mean, it is Microcrap we're talking about here, viz this
article from Woody's (Woody's Office Watch), and if there's anyone more
pro-Microsoft it's only Bill G himself,:
(Read the complete story http://www.wopr.com/ )
TRUST NO ONE [...]
Microsoft has in the past released virus infected documents on their web
site and by other means. WOW has had to publish warnings several times.
Sadly it's happened again. Anyone visiting
http://www.microsoft.com/uk/business_technology/dns/ecommerce/financial/case.htm
to find out more about MS Exchange and E-commerce got more than they
bargained for when they downloaded any of the case study documents. All
were infected with W97M/Marker.C virus! Apparently no-one at Microsoft
checked the documents before making them publicly available [...]
Bruce Tober, <octobersdad@reporters.net>, <http://www.crecon.demon.co.uk>
Birmingham, UK, EU +44-121-242-3832 soon at <http://www.star-dot-star.co.uk>
------------------------------
Date: Thu, 29 Apr 1999 04:43:00 +0900 (JST)
From: Chiaki Ishikawa <Chiaki.Ishikawa@personal-media.co.jp>
Subject: A man charged with counterfeiting bank ATM cards
Lately about a dozen people whose account reside in two Japanese banks found
their money withdrawn by unknown third party. Police began investigating
and found, from the video tape recording of the ATM machines where
withdrawals took place, a man seemed to have used fake bank ATM cards and
withdrew the money from ATM machines in Tokyo area.
Last week, the police arrested a man and charged him for the theft.
But how did this man find about the existence of the bank account and that
the man found the password or PIN? It turns out that the man worked for a
software company that subcontracted the reservation system maintenance for a
city-operated resort facility from an NTT group company. All the people
whose money was stolen made a reservation to the city facility at least
once.
The city resort facility takes reservation from its citizens with advance
partial payment. The hitch is that when the applicant cancels the
reservation, the advance payment is returned to the applicant's bank
account. For this purpose, the city office records the bank account
information as well as other personal information such as telephone number,
address, etc. in the database. All these reservation and cancellation work
seems to be done via computer terminal.
The culprit who works at the company that manages the host computer for the
reservation system obviously had access to the database of the reservation
including the bank account (no encryption that keeps the maintenance
operator to look inside?). So he could concoct a new ATM card by recording
the information onto a magnetic-strip card using a magnetic card writer.
Now the second big question is how he figured out the PIN. (The card itself
no longer carries PIN on itself.) Well, it seemed easy to him. Since he
had access to the personal information such as telephone number, address,
etc., he seemed to make educated guesses and obviously he succeeded. Sigh...
In the same article, some banks were quoted as thinking of making it
possible for customers to change the PIN regularly. (I am not sure if this
works well. If someone picks up bad password, will the person pick up good
password next time? There may be human risks here, but am not sure.) For
that matter, PIN for bank ATM cards here in Japan are only 4 digits!
Shoulder-surfing certainly is possible.
Also, I just learned today that the culprit stole other people's bank
cards in trains and so forth so that he could overlay the stolen bank
account information on these cards to try his guessed PINS. Any
physical checking done by the card reader itself seems to have been
thwarted by the culprit's using otherwise genuine ATM cards. However,
I don't know if any such checks are done by the card readers and cards
used today in Japan. Maybe the culprit was very cautious. Police
reportedly found fake credit card as well at the culprit's home, so in
that case, nice-looking holograph, etc. was necessary for
counterfeiting.
A few risk lessons from this incident:
Private database with sensitive information should be encrypted so that only
the appropriate user can access its contents. The night-shift operator who
do backup can carry a duplicate copy, etc.. Also, proper auditing of access
to the database could deter such criminals. In this case, the city office
could use a PC for terminal and use plain text information on that terminal
alone and could store the encrypted information at the host computer managed
by the company where the culprit works. (Sure, the search against the
stored data record might be an issue here. But by storing the name in plain
text and the rest in encrypted from, it should pose no big problem IMHO.)
ATM cards should be hard to fake in the first place. The bank officials
were quoted in an Asahi shimbun article as saying that making counterfeiting
like this impossible is very difficult technically.
I wonder if adding some information on the card, such as the md5 checksum of
the concatenation of the closely kept secret master bank seed string + the
ordinary infomration on the card such as the branch number, account number,
holder's name, etc. could make the counterfeiting more difficult. Unless the
counterfeiter knows the secret seed string it becomes impossible to fake the
ATM. I guess such scheme would make the counterfeiting very difficult. But
the bank people may not want to upgrade all the ATMs across the whole of
Japan at once, or it may be that the ATM card used today may not hold all
the md5 digits or even reasonable length of it capacity-wise. But probably
they'll be forced to upgrade the security anyway by the social pressure in
not too distant future. I was very surprised about this counterfeting being
so easy myself.
Also, as has been said million times, don't use the obviously easy to guess
PINs based on your telephone number, birth date, etc.. I am not sure if the
database in question contains the birth date for the purpose of the
reservation, but since the success rate seemed to have been high, it
could. But if so, I will add another lesson here.
Don't collect unnecessary personal information. It will leak out
or be abused in some way or the other. (Chiaki's law a la Murphy's law.)
Will computer IC card solve these counterfeting problems in the future?
Chiaki Ishikawa <ishikawa@personal-media.co.jp.NoSpam>
Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051
------------------------------
Date: Sun, 25 Apr 1999 15:21:14 -0500
From: "Richard M. Smith" <rms@pharlap.com>
Subject: What's DejaNews up to?
One of my favorite Web sites is DejaNews, the search engine for Usenet
newsgroup messages. Yesterday I discovered a new "feature" of DejaNews
which I don't understand.
It seems that when a newsgroup message containing URL's is displayed, the
DejaNews server is silent changing the links to be routed through the
DejaNews servers. This new feature allows DejaNews to track when a person
clicks on a Web site link in a newsgroup message. You still get to the Web
site, you just go through the DejaNews servers first. My understanding is
that the new feature was added a couple of months ago.
Here is a quick example of what DejaNews is up to:
Original link: http://www.yahoo.com
Tracking link: http://x12.dejanews.com/jump/http://www.yahoo.com
Apparently the DejaNews servers simply redirect your browser to the real URL
after recording where you clicked. In the newsgroup message itself, the
original link is shown, not the tracking link.
An easy way to defeat this tracking mechanism is to manually copy the link
in the message text to the location or address window of your browser.
I ran a simple experiment and found that a Web site will still get the
referring URL which is the URL of the newsgroup message. So one thing that
DejaNews is not trying to do is block Web sites from knowing where a click
came from.
Pretty obviously, DejaNews knows a lot about me already by my searching
habits. Why do they now also need to know what Web sites I'm visiting?
What is being done with this information?
Pretty odd if you ask me. What I can't figure out is what DejaNews is up to
here. Does anyone have any ideas?
Richard M. Smith <smiths@tiac.net>
[Added note: It gets more interesting. DejaNews is also tracking
e-mail addresses. When one clicks on an e-mail address in a newsgroup
message, it first goes thru the DejaNews server before being redirect as a
mailto: URL. DejaNews ends up know who and when someone is sending e-mail
to. This is just plain weird.]
Here is more info from comp.security.misc:
donoli wrote:
> Exactly. Since they are chaining the URL, they get credit for bringing
> users to the second site.
Yep, Web sites with high click-thru rates get called first by their friendly
DejaNews ad rep!
Maybe the next step here for DejaNews is to somehow figure out how to charge
Web sites for click thru's. Toll booths on the Internet? For example, maybe
DejaNews only highlights links for Web sites that have DejaNews
accounts. Each click-thru then costs a dime.
Why DejaNews went through all of the trouble to also track e-mail makes no
sense at all. It's just plain rude. I've asked their privacy people and PR
people what's going on. Hopefully they'll get back to me today.
BTW, According to Junkbusters.com, the hotbot search engine also does the
same trick for Web sites. They are tracking click-thru's in search
results. None of the other major search engines (AltaVista, Yahoo, Lycos,
and InfoSeek) appear to be doing this.
Richard
------------------------------
Date: Mon, 26 Apr 1999 09:42:19 +0100
From: "Samuel Liddicott" <sam@campbellsci.co.uk>
Subject: Dodgy automatic address book resolution
I work at Campbell Scientific.
It's not surprising that the managing directors has a last name "Campbell".
(Lets pretend his first name is Bill)
I have IE5 and Outlook 98. In my address book is a local employee who
shares the same first name as the overseas director. (Let's pretend it is
Bill Prescott)
In an e-mail message I typed:
Bill Campbell
as the recipient, which my address book foolishly resolved to "Bill Prescott
<bill@campbellsci.co.uk>
Doh! Just because there is a Bill in my address book with campbell in his
e-mail address!
The risks? Expecting technology to abide by my definition of sensible. I
thought I was typing a full name, the computer in its attempt to "do the
right thing" was a little too eager. I was expecting the address book to
fail to resolve, and that it would be picked up by the LDAP server.
The even worse risks? That "Bill Campbell" would work until "Bill
Prescott", a distinctly different name appears in the address book.
Finally, in an effort to make software "do the right thing", it is worth
evaluating when this might turn out to be a "very wrong" thing.
Sam Liddicott <sam@campbellsci.co.uk>
------------------------------
Date: Mon, 26 Apr 1999 23:08:06 -0400
From: Russ <Russ.Cooper@rc.on.ca>
Subject: Re: GUIDs and Melissa (Baum, Risks 20.33)
>What's the point of a "Globally Unique ID" that isn't unique?
With all due respect, this isn't "Microsoft's one", its the OSF's definition
of how to create GUIDs. Copy-and-modify puts your GUID on the modified
document (over-writing the previous GUID), whereas cut-and-paste puts other
content in a document with your GUID.
The GUID wasn't intended to uniquely identify the document, only the
OS/Application installation it was created/last modified on.
For those that forget, NT 3.1 (from which all this GUID stuff stemmed for
MS) was largely based on OSF/DCE. Arguments aside, they did implement the
GUID creation process according to DCE spec.
Russ - NTBugtraq moderator
------------------------------
Date: Tue, 27 Apr 1999 08:42:19 -0800
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Subject: REVIEW: "Great Misadventures", Peggy Saari
BKGRTMSA.RVW 990318
"Great Misadventures", Peggy Saari, 1999, 0-7876-2798-4, U$99.00
%A Peggy Saari
%C 27500 Drake Road, Farmington Hills, MI 48331-3535
%D 1999
%G 0-7876-2798-4
%G (0-7876-2799-2 0-7876-2800-X 0-7876-2801-8 0-7876-2802-6)
%I The Gale Group/Gale Research Inc.
%O U$99.00 248-699-4253 fax: 800-414-5043
%P ~800 p.
%T "Great Misadventures: Bad Ideas That Led to Big Disasters"
Let us start with some cliches. Life is a hard teacher: she gives the test
first, and the lesson afterwards. Good judgement comes from experience:
experience comes from bad judgement. Those who do not learn from history
(or History 205) are doomed to repeat it. We learn far more from failure
than we do from success. And, finally, learn from the mistakes of others:
you will never live long enough to make them all yourself.
If there was ever a book concept made for the RISKS-FORUM Digest library
(aside from PGN's own) it is this: great boneheaded ideas from the past. In
this junior edition, four volumes divide that topic into exploration,
science and technology, military, and society.
Unfortunately, while the essays provide decent canned histories of the
events, they make lousy lessons. All of the material is presented at the
same level of very rough detail, rather than sketching in a background and
then concentrating on a specific mistake. A number of decisions in any
chapter may be identified as errors, but there is little commentary on why
the action was wrong and contributed to the disaster in question. Why did
this endeavour, intended to promote safety, ultimately spell catastrophe?
If this person or institution was motivated by greed or ambition, at what
point did the driving force behind development become a destructive power?
While there is a lack of analysis overall, a particular failing is the lack
of examination of options that might have changed the outcome for the
better.
In the Reader's Guide starting each volume, the point is made that a
calamity had some positive result, usually in terms of a reform or
improvement. Relatively few of the stories, however, tell of any such
correction. In both the Apollo 13 and Bre-X articles, in fact, the text has
to admit that we do not know for sure what the causes of the problems were,
and therefore no lesson can be drawn from them at all.
Of greatest interest to the largest number of readers of this series will be
the article on the Year 2000 problem, otherwise known as the millennium bug
or Y2K. Perhaps the kindest thing that can be said about this essay is that
it will become academic in less than a year. The situation is blamed on an
"error" (with no mention of the widely used standard), although the next
paragraph states that it should not be called a "bug." Although Peter de
Jager has worked tirelessly to bring the issue to the attention of the
public, it is not true that nobody knew about it before his 1993 article. I
have never seen any microwave oven that cared what the date was, and it is
rather beyond the bounds of probability that an aircraft would shut down in
flight because it felt miffed at being too long without a checkup. An
entire section of the article confuses the predicament with the unrelated
issue of maintaining archival records as generations of storage hardware and
media pass by. The entire disaster is ultimately laid to the blame of
"negligent" computer developers.
There are a number of sidebars, generally giving a biography of involved
characters, and illustrations. The biographies sometimes seem at odds with
either the essays of which they form a part, or oddly placed in proximity to
more detailed accounts, and the figures, where placed in a piece, provide
little explanatory support. The military section, for example, has numerous
battle maps where the order of a campaign is extremely difficult to follow.
(Yes, I know: war is messy.) Some of the diagrams, as originally produced,
were probably supposed to be in colour, since the keys cannot, in the black
and white version, distinguish between items of opposed significance. Much
material is duplicated between pieces, but even that can be confusing at
times. Many terms are explained in article after article, and the
explanations are not always consistent. A musket will be defined as a
"shoulder gun" in one essay, a "rifle" in another, and a "gun like a rifle"
in a third. Not a great difference, but confusing. (The index does not
assist in clarifying matters: there are lots of entries for people, but
almost none for things.)
The cachet of disaster might make this an inviting set for promoting study
of history in a rather "dates of the kings of England" manner. The events
are isolated, the details are scanty, and the analysis almost doesn't exist.
I doubt that students would learn much of either history or judgement from
these books.
I should add, in view of the topical relation to the Risks Digest, that
PGN's book is not only cheaper and *way* more accurate, but it's also more
fun to read.
"Computer-Related Risks", Neumann, 1995, 0-201-55805-X, U$24.75
And it's possibly also time to mention Lauren Wiener's book again as well:
"Digital Woes", Wiener, 1993, 0-201-62609-8, U$22.95/C$29.95
copyright Robert M. Slade, 1999 BKGRTMSA.RVW 990318
rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: Tue, 27 Apr 1999 16:11:59 GMT
From: jennifer@usenix.ORG (Jennifer Radtke)
Subject: Open Source Software at 1999 USENIX Annual Conference
[Item abridged for RISKS. PGN-ed]
*** Registration Savings until 3 May 1999 ***
Top developers, systems administrators, and other UNIX gurus get the why as
well as the how-to at the reknown USENIX Annual Conference. The USENIX
Conference takes place June 6-11, 1999, in Monterey, California. Programs
for the tutorial and technical sessions, including the FREENIX track, and
associated events are online. Please go to
http://www.usenix.org/events/usenix99
The FREENIX track is devoted to high-level technical discussion of
open-source software. USENIX has also provided a grant to the OpenBSD
development project to support a new release. It will be distributed for
free at the conference. USENIX is helping to ensure that the development
process for open source software will continue to be characterized by
intense yet healthy competition.
The refereed papers are on topics of especially high interest: management
of resource systems, file systems, virtual memory systems, storage systems,
security, web server performance and O/S performance. The Invited talks
concentrate on the extremely practical; topics include: UNIX/Open System &
Y2K, IP Multicast, e-mail Bombs, IPv6, IP Telephony.
John Ousterhout, creator of Tcl/Tk and leading figure in the open source
world will deliver the conference keynote. His attention is on a
fundamental shift in software development to integration applications --
created by coordinating and extending existing applications, protocols,
frameworks, and devices.
24 tutorials are being offered over three days, with Eric Allman, Tom
Christiansen, Peter Galvin, Evi Nemeth, and Marcus Ranum among the
instructors. Courses range over systems administration, security, Linux,
high availability, kernel internals, Perl, performance tuning, network
programming and configuration, and more.
------------------------------
Date: 23 Sep 1998 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
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 <risks-request@csl.sri.com> 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 <risks-request@pica.army.mil> (Dennis Rears).
.UK users should contact <Lindsay.Marshall@newcastle.ac.uk>.
=> 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 risks@CSL.sri.com 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 19" for volume 19]
or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
PostScript copy of PGN's comprehensive historical summary of one liners:
illustrative.PS at ftp.sri.com/risks .
------------------------------
End of RISKS-FORUM Digest 20.34
************************
