precedence: bulk
Subject: Risks Digest 20.16
RISKS-LIST: Risks-Forum Digest Friday 15 January 1999 Volume 20 : Issue 16
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.16.html>
and at ftp.sri.com/risks/ .
Contents:
Another premature data release (PGN)
NSA says Furby is a national security risk (Bruce Martin)
Man crashes car as 50 pagers ring simultaneously (Geoffrey Leeming)
16-yr-old Irish girl's crypto system (PGN)
Over-reliance on technology (Pat Place)
The risks of a first failure (Bertrand Meyer)
If at first you don't succeed, breaking-in's no crime in Norway (Edupage)
Viruses and Rocket Science (Henry Spencer via Tom Evans)
Smurf denial-of-service attack on OZEMAIL (Mich Kabay)
Y2K in Swiss hospitals (Debora Weber-Wulff)
1 Apr 2001 flaw in Windows (PGN)
Quicken 1999 bug (James S. Vera)
A good Y2K bug (Lenny Foner)
Utilities and Y2K: not to worry (Ken Knowlton)
Y2K testing tools (Craig Raskin)
Java Security (Gary McGraw)
REVIEW: "Maximum Security", Anonymous (Rob Slade)
REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 13 Jan 1999 08:12:17 -0800 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Another premature data release
The Department of Labor Statistics has once again accidentally released data
a day early, this time with the Producer Price Index. Whereas last time
(RISKS-20.05) it was "a human failure", this time it was attributed to a
``software programming error''. As usual, the problem has been corrected,
and won't happen again. [Source: *San Francisco Chronicle*, 13 Jan 1999,
front page of the business section, PGN Abstr.]
------------------------------
Date: Wed, 13 Jan 1999 13:15:00 -0500
From:
[email protected]
Subject: NSA says Furby is a national security risk
On 13 Jan 1999, CNews (www.canoe.ca) carried the AP news story about a U.S.
national security risk posed by the stuffed toy sold under the name of
Furby. For the uninitiated, Furby was the hottest-selling toy of the Xmas
'98 season. Resembling furry gremlins [and apparently being sued therefor],
Furbies are bristling with audio, infrared, and touch sensors, allowing them
to interact with people and with others of their kind.
Detailed information on the capabilities (intended or not) of the average
Furby can be found at: www.homestead.com/hackfurby. Among their repertoire
of tricks, these toys have the apparent ability to mimic human speech in
parrot-like fashion, and therein lies the risk.
According to no lesser authority than the National Security Agency, these
toys were being brought into top-secret areas at Fort Meade by government
employees, where the little devils (the toys, not the employees) could
easily be exposed to classified information which they might later repeat
to foreign agents.
Furby is now "machina non grata" at Fort Meade, and transgressors are to
report to their Staff Security Office for guidance on this matter. A Capitol
Hill source is quoted in the Washington Post of 13 Jan 1999 as saying they
feared "that people would take them home and they'd start talking
classified."
The risk of U.S. national security resting in the hands of adults who play
with children's toys during office hours is left as an exercise to the
reader.
Bruce Martin, Toronto
[The manufacturer insists that the memory cannot be altered, and
that the furbies cannot learn from their environments. However,
because Furbies are programmed to react to responses, there is always the
question of whether there might be a preprogrammed Trojan horse recording
their choices, and providing a nifty covert channel. Until recently, if
you brought viewgraph transparencies into the agency to give a talk, it
was nontrivial to get them out again -- because they were photographic
media. Presumably, similar thinking goes into NSA's Furby policy. PGN]
------------------------------
Date: Fri, 15 Jan 1999 11:27:39 -0100
From:
[email protected]
Subject: Man crashes car as 50 pagers ring simultaneously
A man in the Ukraine bought 50 pagers as presents for his staff. While
driving home, they all rang at the same time. He was so distracted that he
crashed into a lamp post, within 100 meters of his office. Of course,
each one said simply, ``Congratulations on a successful purchase!''
[Source: Yahoo News via Reuters, 15 Jan 1999; PGN Abstr.]
------------------------------
Date: Wed, 13 Jan 1999 08:20:21 -0800 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: 16-yr-old Irish girl's crypto system
Sarah Flannery, 16, in Blarney, County Cork, Ireland, has designed a crypto
system (called Cayley-Purser). ``She is considering publishing her findings
rather than patenting as she does not want people to pay for her
discovery.'' Source: Audrey Magee, *The Times*, London, 13 Jan 1999;
Edupage, 14 January 1999, PGN Stark Abstr. TNX to Lindsay Marshall]
According to some technical discussions on the net, the scheme is based on
2x2 matrices, and appears to be 10 times faster than RSA, but with much
longer keys, and apparently with security comparable to RSA for comparable
modulus sizes.
I'm not sure from the articles I've seen whether the reporters are
more surprised by Sarah's age or her gender. But there seems to be
general astonishment that she could come up with a crypto algorithm. On
the other hand, RISKS readers know that lots of people have come up with
crypto algorithms. If this one is really good, that *is* special.
That she wants to keep it open is even more special. PGN
------------------------------
Date: Tue, 12 Jan 1999 09:07:19 -0500
From:
[email protected] (Pat Place)
Subject: Over-reliance on technology
In answer to Jordin Kare's TROFF problems (RISKS-20.14), Glen Turner
(RISKS-20.15) suggests the use of a text editor displying different
syntactic components using different textual properties (colour, font, and
size being the common variables).
I'm sure that XEmacs and other editors of that sort do their best, however,
with a language such as TROFF, where everything can be changed including the
escape character and the control line characters (.ec, .cc, and .c2), unless
the editor contains a TROFF interpreter sooner or later it will be confused.
Although, XEmacs' best attempt may be good - we shouldn't rely on it
for accuracy - the best solutions to Jordin Kare's problems are
1) understand the tool you are using (the nroff/troff user manual is
invaluable here)
2) proof-read carefully everything you produce.
Pat Place
[email protected]
------------------------------
Date: Wed, 13 Jan 99 11:14:53 PST
From:
[email protected]
Subject: The risks of a first failure
A cute little bug on
http://www.dejanews.com (but please don't try this
except possibly on a test group):
Successfully post an article through DejaNews (after registering as a user)
You get an article number <nnnn> to be used if you want to cancel
Change your mind (L'uomo e` mobile)
Go to the cancellation page, include nnnn as the article number
(You are not only fickle but careless, and didn't notice
that you are supposed to put in the angle brackets too.)
It finds your article
Confirm cancellation by clicking the appropriate button
You get a message stating that this is not a valid article number
Realize your mistake (the forgotten angle brackets)
Try cancellation again, this time including the brackets
It finds your article
Confirm cancellation
You get a message to the effect that this article appears to have been
cancelled already!
As far as I know there is no way after that to cancel the article
(but I haven't contacted Dejanews about it).
The reason I mention this small apparent bug is that it is representative of
an interactive system risk that one encounters all too frequently. It arises
for a kind of "transaction", in the broad sense of the term, that a system
accepts to carry out at most once. If, however, an attempt fails and is
rejected by the system, it may have been registered in the same way as a
successful attempt, so that later on the system may believe that the
transaction has already taken place, and reject any further attempt,
resulting for the user in a Catch-22 situation.
The more general design principle is: if you reject an operation after it
may already have affected the information in your system, make sure that the
rejection process brings the information back to a consistent state.
(I am not writing: "... that it restores the information to its original
state", because that may be impossible; even if possible it may be
undesirable, e.g. we may want to keep a record of failed attempts. What we
don't want is partial success leading to an inconsistent database.
Obviously the use of invariants and other Design by Contract principles
helps in defining and enforcing "consistent" states.)
People designing transaction processing systems in the strict, conventional
sense are well aware of the risk and the principle, but I think we would all
benefit if it were known and applied much more broadly.
Bertrand Meyer, Interactive Software Engineering, Santa Barbara
<
[email protected]>,
http://eiffel.com
------------------------------
Date: Thu, 14 Jan 1999 11:52:05 -0500
From: Edupage Editors <
[email protected]>
Subject: If at first you don't succeed, breaking-in's no crime in Norway
The Supreme Court in Norway has ruled that it's not a crime to try to break
into someone else's computer system, because people should expect others to
try to invade their systems, and take measures to protect themselves. There
is a crime, ruled the court, only if the system is actually breached. The
case developed out of an attempt by a computer security company to break
into the University of Oslo's computers through the Internet, to contribute
to a feature story by the Norwegian state broadcasting network. Apparently
the security company mapped holes in the university's computer security, but
did not break in, tamper with, or steal any information. (*USA Today*,
13 Jan 1999; Edupage, 14 January 1999)
------------------------------
Date: Fri, 15 Jan 1999 19:03:18 +1100
From: Tom Evans <
[email protected]>
Subject: Viruses and Rocket Science
The following is lifted directly from Henry Spencer's summary of AW&ST
posted to sci.space.news:
Date: 1999/01/06
>From: Henry Spencer <
[email protected]>
Subject: space news from Nov 16 AW&ST
As if Sea Launch didn't have trouble enough, now its computers (as well as
those of some other Boeing projects) have come down with a massive virus
infection. The viruses apparently spread via documents about Sea Launch
export compliance, which were widely distributed to staff in the wake of the
project's recent government problems. Boeing had few defences in place, and
was slow to act because the viruses initially seemed harmless.
Full article available as:
http://x7.dejanews.com/getdoc.xp?AN=429551406.1&CONTEXT=916023969.559415504&
hitnum=1
Tom Evans <
[email protected]>
------------------------------
Date: Thu, 14 Jan 1999 09:47:48 -0500
From: Mich Kabay <
[email protected]>
Subject: Smurf denial-of-service attack on OZEMAIL
According to an article by Tim Barlass in the Daily Telegraph of Australia
(12 Jan 1999, p. 9), someone has launched a sustained smurf
denial-of-service attack on Ozemail, an important Australian Internet
service provider. E-mail service has been disrupted for users in Sydney. A
company spokesperson said they were trying to track down the perpetrator and
were considering installing filtering software to prevent future attacks.
[Note from MK: a "smurf" attack uses widely-available software written by
criminal hackers to send ping packets with forged origination in the
headers to a (usually major) corporate network's broadcast address. Every
device -- perhaps hundreds or thousands -- sends a reply packet to the
forged originator address. That system thus receives a flood of packets,
often overloading its TCP/IP stacks and resulting in denial of service.
See the article by Michael Dillon in ASK THE INFRA EXPERT (Internet World:
Apr 20, 1998) for a more detailed explanation.]
M. E. Kabay, PhD, CISSP / Director of Education
ICSA, Inc. <
http://www.icsa.net>
------------------------------
Date: Thu, 14 Jan 1999 14:22:58 +0100
From: Debora Weber-Wulff <
[email protected]>
Subject: Y2K in Swiss hospitals
I heard about this from an informant, took quite some searching to find the
little notice hiding on the pages in the NZZ (Neue Zuercher Zeitung, 7 Jan
1999) usually reserved for reporting celebrity divorces, plane crashes and
natural disasters. An on-the-fly translation:
The hospitals in the canton Waadt spent the 1st and 2nd of January 1999
fighting with the computer problems that are expected for the year 2000.
Except for the University Hospital in Lausanne, the computer systems for
admitting patients in all of the hospitals of the canton were down for 36
hours. Specialists were able to fix the problem, according to a spokeswomen
for the hospitals in the newspaper "24 Heures" (24 hours) on Wednesday. The
reason for the system crash is the fact that it was programmed to compare
something with the date a year in the future. This was programmed in 6
digits as "01.01.00". The system interpreted this as 1 Jan 1900.
Source: Year-2000 computer problem in Waadtlaender hospitals Lausanne,
http://archiv.nzz.ch/books/nzzmonat/0/8466081T.html]
Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin
FB Informatik, 13353 Berlin, Germany
http://www.tfh-berlin.de/~weberwu/
[Waadt's New? PGN]
------------------------------
Date: Thu, 14 Jan 1999 18:12:12 -0800 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: 1 Apr 2001 flaw in Windows
Windows (95,98,NT) systems apparently suffer from an off-by-one-week glitch
on the daylight savings time cutover in 2001, shifting on 1 Apr rather than
8 Apr. An updated library program will solve the problem. [Source: John
Markoff, *The New York Times*, 14 Jan 1999; PGN Abstr, via Dave Farber and
others.]
------------------------------
Date: Tue, 12 Jan 1999 16:44:39 -0800
From: "James S. Vera" <
[email protected]>
Subject: Quicken 1999 bug
Another 1999 bug, Intuit's Quicken'99 fails with a "divide by zero"
message when a transaction dated in January 1999 is recorded in the Auto
category and its "Home and Car Center" is opened. See
http://www.intuit.com/support/quicken/faqs/win2/1913.html
James S. Vera | Internet | Voice: +1.415.725.0256
Stanford University |
[email protected] | FAX: +1.415.725.7398
------------------------------
Date: Wed, 13 Jan 1999 01:59:00 -0500
From: Lenny Foner <
[email protected]>
Subject: A good Y2K bug
> January 1, 2000
> Re: Vacation Pay
> Dear Valued Employee:
> Our records indicate that you have not used any vacation time over the
> past 100 year(s). As I'm sure you are aware, employees are granted 3
> weeks of paid leave per year or pay in lieu of time off. One additional
> week is granted for every 5 years of service.
> Please either take 9,400 days off work or notify our office and your next
> pay cheque will reflect payment of $8,277,432.22 which will include all
> pay and interest for the past 1,200 months.
> Sincerely, Automated Payroll Processing
------------------------------
Date: Mon, 11 Jan 1999 20:49:06 EST
From:
[email protected] (Ken Knowlton)
Subject: Utilities and Y2K: not to worry
I quote from a 10 Jan 1999 article in *The Boston Globe* on utilities' Y2K
readiness:
Typical is one filing from Notheast Utilities: "NU has found nothing
that cannot be repaired or replaced and be made Year 2000 ready in time,"
it states.
They don't get it: the devil is in the gotchas not found.
------------------------------
Date: Wed, 13 Jan 1999 14:58:28 -0500 (EST)
From: Craig Raskin <
[email protected]>
Subject: Y2K testing tools
I am currently involved with doing y2k testing at a client site. I have
spent numerous hours looking for tools which can be used for building test
suites. Unfortunately, I have not been able to find very many tools which
are worthwhile.
A lot of the available tools appear to have been built by individuals who do
not fully grasp the underlying concept of the machines and operating systems
which they are trying to test.
I have written some c code which should cause alerts with testing software
that checks for possible y2k problems. When compiled and checked under
microsoft based platforms, these binaries easily slip by testing
programs. When compiled and checked by Sun's own y2k testing tools, these
binaries also slip by.
Since Sun's tools are based on shell scripts, I was able to go in and find
the problem. The script works fine under the Sparc editions of the operating
system but returns false information when run under the Intel x86
version. This is due to the 'dump' command having differing output between
the OS versions. This slipped by the engineers at Sun.
Out of necessity, a lot of people are now doing system testing for the first
time in their careers. The risks are obvious. How many systems have been
checked and certified with buggy tools? Have individuals involved with
testing first checked that their test suites will actually work? Do they
even know how? We will find out soon enough.
------------------------------
Date: Wed, 13 Jan 1999 22:35:54 -0500 (EST)
From: Gary McGraw <
[email protected]>
Subject: Java Security
Ed Felten and I are pleased to announce the publication of a completely
revised and expanded new book, a follow-on to our original 1996 book "Java
Security: Hostile Applets, Holes, and Antidotes" (better known as Java
Security HA HA among readers in the know). The new book "Securing Java:
Getting down to business with mobile code" is published by John Wiley & Sons
(1999). Physical copies are available now. In addition to the physical
book, Ed and I decided to make the entire text available for free and
unlimited Web access. The URL is:
http://www.securingjava.com
The risk here is that nobody will buy the physical edition ;-)! Help
us mitigate that risk, making the Web experiment a success. Ah
publishing in the 90s.
The book covers the risks presented by mobile code systems including
Java 2 and ActiveX and is an in depth treatment of these complex issues.
RISKS readers will probably appreciate the tone.
Enjoy!
Dr. Gary McGraw, Vice President, Reliable Software Technologies
http://www.rstcorp.com
------------------------------
Date: Mon, 11 Jan 1999 09:59:59 -0800
From: "Rob Slade, doting grandpa of Ryan and Trevor" <
[email protected]>
Subject: REVIEW: "Maximum Security", Anonymous
BKMAXSEC.RVW 981025
"Maximum Security", Anonymous, 1998, 0-672-31341-3,
U$49.99/C$70.95/UK#46.95
%A Anonymous
%C 201 W. 103rd Street, Indianapolis, IN 46290
%D 1998
%E Mark Taber
[email protected]
%G 0-672-31341-3
%I Macmillan Computer Publishing (MCP)
%O U$49.99/C$70.95/UK#46.95 800-858-7674
http://www.mcp.com
%P 829 p. + CD-ROM
%T "Maximum Security, second edition"
Rather loudly promoted on the net these days, the major selling point of
this book is that it was written "by an experienced hacker." Supposedly one
who spent some time as a guest of Uncle Sam for fiddling bank machines.
(Some of what we are told about the author does not fit with the contents of
the book, but then, as an old professional paranoid, I may be unduly
suspicious.) Leaving aside questions of morality and definitions of the
term "hacker," let us merely observe that these people are the gnostics.
They are the devotees of the hidden, esoteric, and arcane knowledge. Such
knowledge, of course, is cheapened and weakened by being revealed. Which
may explain a certain reticence on a number of points in the first edition
of the book. The introduction to that edition made it fairly clear:
Anonymous assumed that if you did not work diligently at his direction you
did not deserve to secure your system. One could almost feel his glee at
the expectation that thousands of sysadmins around the world were wracking
their brains and flooding Usenet with discussions of the significance of his
clues to the vital encrypted message he had hidden on the CD-ROM.
The riddle, and that attitude, seem to have been removed from this second
edition. The author tacitly admits that the first was a bit of a kludge: he
says that it was written in haste. He also states that the second edition
is more "solution oriented." It could hardly have been less. Be that as it
may, the book is, as the author states, essentially completely rewritten.
It has been much improved in the process, moving up from truly awful to
merely mediocre. The new version provides a good deal of reference
information, although assessing the quality of that information is left as
an exercise to the reader.
The section on viruses is an overview of the book in miniature. The hype
has been toned down, and the explanation of how viruses work is much more
reasonable. However, it still insists that "destruction" is the major
characteristic of a virus. (There is, later, an admission that "[m]ost
viruses do not actually destroy data.") We are treated to the old myth that
virus researchers write viruses as a kind of job security. While a general
background to viruses is provided, there is no discussion of protection
options. However, there are more listings of antiviral programs and
resource sites than there are for virus creation programs. Many topics
within the text have lists of books and Web sites for further study, and
there is one for viruses that includes three of the four tomes recommended
by the VIRUS-L FAQ. Unfortunately, it also contains some lesser works, and
there are no annotations to the bibliography.
Part one is simply two chapters of introduction to the book. A somewhat
limited overview to security concepts is given in part two, concentrating on
the Internet. Chapters look at the Internet, TCP/IP basics, hackers and
crackers, targets, possibilities of fights over the net, and very brief data
security primer. Various types of security and attack software are outlined
in part three. There is consideration of malicious software, security
weakness scanners, password crackers, trojans, network packet sniffers,
firewalls, and audit software. Part four looks at specific operating
systems: Windows, UNIX, Novell, VMS, and Macintosh. Two chapters look at
very basic security requirements in part five. Network based attacks are
discussed in part six, reviewing levels of attack, spoofing, telnet,
scripting languages and extensions, and hiding of identity. Different types
of resources and references are contained in appendices. (I was
disappointed in the loss of a chapter on laws in various countries until I
found it had been moved back here.)
If you don't know security, this book is probably not going to teach it to
you. On the other hand, if you work with security, you may find that some
of the resources listed here are things that you want to explore. For the
novice it isn't altogether reliable, but for the professional it is at least
worth looking at.
copyright Robert M. Slade, 1998 BKMAXSEC.RVW 981025
[email protected] [email protected] [email protected] [email protected]
Robert Slade's Guide to Computer Viruses, 0-387-94663-2 (800-SPRINGER)
------------------------------
Date: Fri, 15 Jan 1999 08:18:30 -0800
From: "Rob Slade, doting grandpa of Ryan and Trevor" <
[email protected]>
Subject: REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare
BKY2KNSH.RVW 981030
"Year 2000 in a Nutshell", Norman Shakespeare, 1998, 1-56592-421-5,
U$19.95/C$29.95
%A Norman Shakespeare
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 1998
%G 1-56592-421-5
%I O'Reilly & Associates, Inc.
%O U$19.95/C$29.95 800-998-9938 707-829-0515
[email protected]
%P 336 p.
%T "Year 2000 in a Nutshell: A Desktop Quick Reference"
*Can* the Year 2000 problem be put in a nutshell? (Please?)
And isn't it just a tad late to be starting this? (On the other hand,
Nutshell books *are* generally worth waiting for.)
Part one is a general overview of the situation. Chapter one starts with a
rather exaggerated doomsday scenario, including concerns that have already
been seen, and thus have been addressed. At the same time, it ignores the
"upstream" multiplier effect of supplier and infrastructure failures.
However, it does go on to note needs and concerns for management of the
potential failures. Management and budgeting considerations are expanded in
chapter two. Legal questions are addressed in chapter three, in a somewhat
generic fashion. Some standard planning models and assumptions are given in
chapter four. A little technical information in chapter five may help with
calculations for dates and windowing or packing solutions. Chapter six
looks at the desktop PC; which is interesting in view of a very heavy COBOL
and IBM mainframe and mid-range emphasis elsewhere (as well as a few PC
related goofs in the doomsday scenario). Unfortunately, some of the
information is missing and some is wrong in regard to the desktop. There is
no mention of a "cold rollover" test for the CMOS/system date, and the
statement about Excel's date interpretation is incorrect. (I have confirmed
this in my own testing.) On the other hand, the warning about internally
developed applications is quite important.
Part two provides some forms and checklists to help organize a Year 2000
project, including triage, inventory, and a project template. There are
about a hundred pages of COBOL references and tutorial in part three. Date
functions get extensive listings in part four with attention to general
types, COBOL, PL/1, MVS LE, Visual Basic, and C. There is a conceptual look
at code scanners in chapters eighteen and nineteen. An appendix lists Web
sites for Y2K vendors, tools, and other resources.
Was it worth waiting for this? I'm not sure. There is little wrong with
the information, but neither is this a cut and dried quick fix that you
might expect from the Nutshell series. An unrealistic expectation in the
case of the disaster of the century, admittedly, but there you are. Still,
with the big iron emphasis, and the big project orientation, the material is
this work seems to be coming later than it would have been necessary to
start these kinds of projects. There is relatively little in the volume for
small businesses depending upon desktop machines, and almost nothing on
fallback plans for non-compliance in the supply chain. The material is fine
as far as it goes, but it doesn't go as far as it needs to at this late
date.
On the other hand, it's no worse than any of the others.
copyright Robert M. Slade, 1998 BKY2KNSH.RVW 981030
[email protected] [email protected] [email protected] [email protected]
Find virus, book info
http://victoria.tc.ca/int-grps/techrev/rms.html
------------------------------
Date: 23 Sep 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 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.16
************************
