precedence: bulk

precedence: bulk
Subject: Risks Digest 19.89

RISKS-LIST: Risks-Forum Digest Monday 27 July 1998 Volume 19 : Issue 89

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.89.html and at
ftp.sri.com/risks/ .

Contents:
Students given wrong degree after computer error (Bruce McAdam)
Senate votes to ban Internet gambling (Edupage)
IBM de Mexico pays Mexico City for failed database system (Edupage)
PacBell phone mail outage (Craig Partridge)
A 4-digit PIN truncation (Eddie Sullivan)
Re: Yorktown dead in water after divide by 0 (Tim Bradshaw, Phil Edwards)
Re: German train accident (Bob Frankston)
Y2K OK on Wall Street (Edupage)
No Y2K insurance for household electrical items (Jonathan Pritchard)
Re: Y2K contingency plans (Joe Bednorz)
REVIEW: "Personal Medical Information", Ross Anderson (Rob Slade)
REVIEW: "Windows NT Security", Charles B. Rutstein (Rob Slade)
Re: REVIEW: "Windows NT Security", Charles B. Rutstein (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 23 Jul 1998 13:58:14 +0100
From: Bruce McAdam <[email protected]>
Subject: Students given wrong degree after computer error

Ten days after hearing that she had received a 2:1 degree (the
second-highest grade available), a University of Edinburgh student (Jennifer
McLellan) was told that the degree result was wrongly calculated and that
she had actually received a 2:2 (the third-highest grade available). This
caused her to lose a job offer and have her plans for the future thrown into
considerable disarray.

According to *The Daily Telegraph* (23 Jul 1998, page 1), a total of four
students were originally given the wrong degree classification, a mistake
the University attributed to "an error made in transferring degree marks to
a computer spreadsheet". It is yet known whether this was caused by human
error.

Bruce J. McAdam, Postgraduate Student, The Department of Computer Science,
The University of Edinburgh

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

Date: Sun, 26 Jul 1998 13:08:21 -0400
From: Edupage Editors <[email protected]>
Subject: Senate votes to ban Internet gambling (Re: RISKS-19.27,63)

The Senate voted 90-10 Thursday to ban Internet gambling, extending the
existing federal prohibitions on interstate gambling via telephone or wire.
A companion bill is moving through the House. Approximately 140 Web sites
offer gambling, and more than $600 million was wagered online last year on
sports alone, according to the Justice Department. Sponsoring Senator Jon
Kyl (R-Ariz.) says without the ban, the revenues could balloon to $10
billion in the next couple of years. "If we don't stop this activity now,
the money that is generated by this kind of illegal activity is going to...
become so influential in our political process that we will never get it
stopped." The legislation would exempt "fantasy" or rotisserie sports
leagues, in which participants bid on rosters of professional athletes to
create "fantasy" teams, and money is exchanged based on the players'
statistics. (*Los Angeles Times*, 24 Jul 1998; Edupage, 26 July 1998)

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

Date: Sun, 26 Jul 1998 13:08:21 -0400
From: Edupage Editors <[email protected]>
Subject: IBM de Mexico pays Mexico City for failed database system

IBM de Mexico, the Mexican unit of the International Business Corporation,
will pay Mexico City $37.5 million in cash and products to resolve a dispute
over a failed database system. Three IBM executives face trial on charges
of a conspiracy to defraud the city, which had purchased the system without
competitive bidding in 1996. An IBM executive says, "In any complex
systems-integration project, technical issues will arise, and we've always
been 100% committed to resolving them... This civil agreement allows us to
continue to work together with this customer." The rules of commerce have
changed markedly since opposition parties began to gain power and challenge
the corruption that had often been a normal part of doing business. (*The
New York Times*, 24 Jul 1998; Edupage, 26 July 1998)

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

Date: Sun, 26 Jul 1998 12:57:39 -0700
From: Craig Partridge <[email protected]>
Subject: PacBell phone mail outage

PacBell suffered a multi-hour failure of its phone mail system for
subscribers in California yesterday (Saturday, 25 July 1998).

I've gotten two accounts of the problem. Last night, when the outage
was still on-going (and affected subscribers in my area), the people answering
the PacBell service number stated the outage was "statewide" and due to
"a cable cut." Today's SF Examiner reports that the outage was localized to
the Bay Area and due to a failed software upgrade.

Craig Partridge [email protected] or [email protected]

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

Date: Mon, 27 Jul 1998 18:03:55 -0400
From: Eddie Sullivan <[email protected]>
Subject: A 4-digit PIN truncation

I've discovered an interesting problem with bank teller machines. At least
with my BankBoston ATM card, only the first four digits of the personal
identification number are relevant. I have a five-digit PIN, and I've tried
typing just the first four, and I've also tried the first four plus an
incorrect fifth digit. In both cases, the machine was more than happy to
fork over money. I've tried it in BankBoston and USTrust ATM's.

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

Date: 23 Jul 1998 13:26:55 +0100
From: Tim Bradshaw <[email protected]>
Subject: Re: Yorktown dead in water after divide by 0 (Crawford, RISKS-19.88)

The Yorktown problems are particularly worrying because they're very
reminiscent of problems the British navy suffered a hundred years or so ago.

In the second half of the 19th century, continuing into the first world war,
the British navy became extremely dependent on extremely elaborate flag
signalling, with a resulting centralisation of command in the flagship, and
increasing unwillingness and inability of individual ships' commanders to
display initiative.

The signalling system made possible elaborate & impressive peacetime
maneuvers, but was liable to failure under battle conditions where smoke
could obscure signals, and the whole signalling system -- including the
human parts of it -- operating on the exposed bridge of the ship was
extremely vulnerable.

Because officers were trained to obey signals regardless, and not to act
without them, a failure in the signalling technology could be very severe.
There are (perhaps contentious) examples of this at Jutland in 1916 where
the failure to send, receive, or correctly interpret signals, and the
failure to act on initiative were noticeable problems for the British.

The technology is different, but the reliance on a particular technology,
with no apparent backup, seems to be the same. If a warship uses a computer
system for its essential functioning that should be backed up by alternative
systems, including manual ones. People need to be trained in the use of
those backup systems and willing to use them. They also need to be willing
to decide that the computer system is wrong and override it even when it is
functioning.

Tim Bradshaw, System Manager, Artificial Intelligence Applications Institute,
University of Edinburgh

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

Date: Thu, 23 Jul 1998 15:36:54 GMT
From: [email protected] (Phil Edwards)
Subject: Re: Yorktown dead in water after divide by 0 (Crawford, RISKS-19.88)

Thereby hangs a tale.

The "Smart Ship" initiative being piloted aboard the Yorktown is only part
of a general migration to NT; US naval bases are currently piloting "Smart
Base". The aim is to put in place a seamless service-wide operating
environment. (Source: *Government Computer News*, 20 Apr 1998).

This is in line with the current issue of the US Navy's Information
Technology Standards Guidance (ITSG), approved in May 1998, which describes
NT as "the de facto standard client-server computing technology". The ITSG
endorses NT 4.0 as the standard OS for networks and standalone PCs; factors
in its favour include functionality, performance and the C2 security rating
of NT 3.5. (Source: *Government Computer News*, 29 Jun 1998. And yes, I
realise the part about NT 3.5 doesn't follow).

This itself follows from the "IT-21" strategy put forward a year
earlier. This was summed up by its chief advocate, Admiral Archie Clemins,
in the following seven principles:

- If the boss doesn't use it, don't buy it.
- We must integrate the tactical and nontactical.
- We must stay common with industry.
- We must drive everything to a single PC.
- We must use commercial off-the-shelf (COTS) products for almost
everything we do.
- We must have seamless transition from shore to sea.
- We cannot allow stovepipes to develop within our C4I architecture.

(Source: *US Naval Institute Proceedings*, May 1997. There is a cogently
sceptical discussion of Clemins' proposals (with the wonderful title
"Beware of Geeks bearing Gifts") in the April 1998 issue).

In practical terms, Clemins has stated, this means migrating as much as
possible from Unix to NT. (Source: *Federal Computer Week*, 14 Apr 1997)

To sum up: the Yorktown debacle is IT-21 in action - or, to be scrupulously
fair, in pilot.

Interestingly, the US Navy's system integration problem reported by Jim
Horning in RISKS-19.86 also has an IT-21 element. Quoting from the original
story (from *Wired News*, 16 Jul 1998):

The problem is with neither individual system, but rather with the way
they interoperate, or work with one another. The problem is compounded by
the a new Commercial Off-The-Shelf (COTS) display system also running
aboard the vessels.

A Navy official said that COTS is more challenging than expected --
although the Navy has the license to use the COTS software, they don't
have access to its source code. Such code would allows the specialists to
"get under the hood" of the software and might help them identify the
conflicts.

'COTS', as we've seen, translates as 'market-leading commercial software, as
used by VPs of civilian businesses, running on NT'. Unfortunately the
acronym seems to have baffled the Wired reporter - "COTS is more challenging
than expected" is a story in itself.

Risks? I'll fall back on British understatement and say that there is
a distinct chance that software and hardware which is
(a) purchased off the shelf
(b) designed for civilian applications
(c) tailored for the specific requirements of higher management and
(d) brought to market in a relatively immature state
may not perform consistently to military specifications.

Phil

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

Date: Mon, 27 Jul 1998 12:00 -0400
From: [email protected]
Subject: Re: German train accident (RISKS-19.80,81,83)

On the plane back from Europe (Lufthansa appropriately enough), I sat next
to a German engineer (actually, chemical and running a company, but that's
beside the point) and asked him about the train crash. He said that the
wheel had been off the tracks for 5km and the magnitude of the problem was
due to having a switch track just before a bridge. Similar accidents had
occurred in France but in less damaging locations. The solution is to track
the behavior of the wheel (or the proximity to the track) with sensors to
discover the problem early. This sounds even better than periodically
checking the wheel since it will catch the actual problem as soon as it
occurs even if there were a separate cause for a wheel problem.

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

Date: Thu, 23 Jul 1998 16:46:03 -0400
From: Edupage Editors <[email protected]>
Subject: Y2K OK on Wall Street

A ten-day-long test by the Securities Industry Association's Year 2000
project found no problems during a simulation involving 29 brokerage firms,
all major stock exchanges, and the corporations that conduct trades for
them. Project manager Leslie Tortora hopes that the success of the project
will encourage a similar effort by telephone companies, and says: "People
are feeling good. An enormous amount of energy and preparation has gone
into making this successful." (*The New York Times*, 23 Jul 1998; Edupage,
23 July 1998)

[Excuse my using Edupage so extensively in this issue. John Gehl &
Suzanne Douglas do a marvelous job of summarizing many topics, and
their last two issues just happen to hit RISKS paydirt. To subscribe to
Edupage: send mail [email protected] with the message:
subscribe edupage <your name>.
If you have subscription problems, send mail to [email protected].
PGN]

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

Date: Wed, 22 Jul 1998 11:41:04 +0100
From: Jonathan Pritchard <[email protected]>
Subject: No Y2K insurance for household electrical items

I just heard on the radio that all UK insurance companies have decided not
to pay out any household claims arising from y2k issues affecting household
items. Considering a lot of people own TV, Video, Hi-Fi all of which have
date sensitive internals it seems as though a lot of people may be out of
pocket come 1/1/2000. I'm not an expert on the internal systems of
household appliances, but I would have thought particularly videos will
encounter problems due to their reliance on clocks for recording programs.
There is also an increasing trend towards integrating TV/Video functions and
on screen menu functions rather than the older analogue (Y2K compliant!)
switches.

The risks? Integrating date dependent functions (video programming) with
other things (tuning via menu systems) just to get it all on the same remote
control. Also a risk is expecting companies / insurance agents to honour
claims for "malfunctioning" equipment.

Jonathan Pritchard, Lucent Technologies

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

Date: Thu, 23 Jul 1998 09:31:44 -0500
From: Joe Bednorz <[email protected]>
Subject: Re: Y2K contingency plans (RISKS-19.88)

Rob Bailey in RISKS-19.88 adds hard data to Frankston's observation that
preparations are not being made to handle unexpected problems on 00-01-01.
(Apparently, what few bureaucrats admit the problem are not willing to say
it can't be completely solved in advance.)

My counter-argument (to the bureaucrats, not my esteemed fellow
Risks-contributors) is as follows:

1) No release of a new version of software has ever gone completely
smoothly. Even if no new internal bugs are introduced (ha!),
unexpected external conflicts will arise (incompatibility with
other software, incorrect user responses to interface changes, etc.)

2) The more changes are made (between previous versions & a new
release), no matter how small, the more unexpected problems there
will be, and the harder they will be to find.

(These are from experiences at a critical site running 24/7. After
too many call-outs on weekends to fix bugs in new releases, we
implemented a policy that production releases ready after twelve
noon on Thursday must be delayed until the following Monday.)

3) 00-01-01:00:00 will be the equivalent of the world's biggest
release of new software in history. *Every piece of code*
will be run for the first time under real-world y2k conditions
*simultaneously*.

4) Even if every application tested perfectly individually under
y2k conditions (ha!), unexpected slight changes of operation would
cause major, perhaps massive, disruption.

The solution? Continue finding and fixing as many y2k problems as possible,
but be sure to have extra (massive?) support available on 00-01-01:00:00 to
fix critical problems.

Joe Bednorz <[email protected]>

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

Date: Fri, 24 Jul 1998 09:57:48 -0800
From: Rob Slade <[email protected]>
Subject: REVIEW: "Personal Medical Information", Ross Anderson

BKPRMDIN.RVW 980508

"Personal Medical Information", Ross Anderson, 1997, 3-540-63244-1,
U$45.00
%E Ross Anderson [email protected]
%C 175 Fifth Ave., New York, NY 10010
%D 1997
%G 3-540-63244-1
%I Springer-Verlag
%O U$45.00 800-777-4643 fax: 201-348-4505 [email protected]
%P 250 p.
%T "Personal Medical Information: Security, Engineering, and Ethics"

The papers contained in this work were presented at a conference held in
Cambridge, UK, in June of 1996. Those attending were from medical, legal,
activist, legislative, and data security backgrounds. Most of the material
comes from the UK and German experience.

The first paper examines the purpose and ownership of medical information:
does the data belong to the patient or the NHS (National Health Service) and
what implications does ownership have on policy regarding health
information. This question is complicated by the requirement for aggregated
details in order to provide the proper quality of service. In Germany, a
"smart" card is being developed for patient information and billing purposes
and the debate and various options for the card is described in the second
essay. Chapter three looks generically (and in rather jargon laden manner)
at the distinctives of medical information systems. During rationalization
of the medical information systems of the German Democratic Republic (GDR,
East Germany) and the Federal Republic of Germany (West Germany) the value
of a central repository for cancer information was noted, along with the
danger of invasion of privacy in such consolidated systems. The possibility
of a distributed information system in which patient information is held
locally, but made available for non- identifying epidemiological research is
discussed in paper four. The review of the use of information systems by
general practitioners, in chapter five, is general and anecdotal, rather
than analytical.

The British Medical Association (BMA) has produced a policy paper on the
security and confidentiality of patient information. The sixth essay takes
issue with aspects of the BMA paper with particular respect to acute care.
Implementation of the policy in a multipractitioner practice in Yorkshire
is noted in chapter seven. The BMA policy is used as a case study for
medical ethics analysis in chapter eleven. Chapter twenty closes off the
book with an update on the policy.

Paper number eight is a somewhat simplistic view of a confidential patient
information architecture modeled on an ideal patient ward. Unfortunately,
it fails to account not only for real world situations, but also for many
important uses of medical information. Although titularly involved with
risk assessment, chapter nine is essentially a statement of medical ethics
in opposition to the surveillance of patients used by for-profit managed
care operations. With the introduction of information technologies,
wholesale modification of institutions and systems is being undertaken,
often with untoward consequences. The aim of essay ten is to propose a
model for re-engineering that makes responsibility central to the enterprise
in order to avoid confidentiality problems. While the many see patient
information as primarily business related, chapter twelve looks at the needs
for data as a resource for research and treatment. Electronic commerce
tools are used to ensure confidentiality of patient information transfer in
paper thirteen. Similarly, public key encryption is examined for the
establishment of confidential auditing of medical payments in essay
fourteen. Chapter fifteen is a very brief case study of the use of smart
cards for medical data. The philosophical review of medical ethics in
chapter sixteen has only tenuous connections to technology. Only an
abstract is included for presentation seventeen. Chapter eighteen is a
review of privacy policy in the United States. Nineteen is a case study
from New Zealand.

While the quality of the papers is uneven, the variety of viewpoints is
extremely valuable. Although there is a significant bias in favour of
patient confidentiality, some of the needs for sharing of information are at
least raised.

copyright Robert M. Slade, 1998 BKPRMDIN.RVW 980508

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

Date: Wed, 22 Jul 1998 10:53:22 -0800
From: "Rob Slade" <[email protected]>
Subject: REVIEW: "Windows NT Security", Charles B. Rutstein

BKWNTSEC.RVW 980510

"Windows NT Security", Charles B. Rutstein, 1997, 0-07-057833-8,
U$34.95
%A Charles B. Rutstein
%C 300 Water Street, Whitby, Ontario L1N 9B6
%D 1997
%G 0-07-057833-8
%I McGraw-Hill Ryerson/Osborne
%O U$34.95 800-565-5758 fax: 905-430-5020 [email protected]
%P 332 p.
%T "Windows NT Security"

Windows NT provides a number of tools and functions for securing the system
and workstation. Security is also going to mean different things to
different people and work environments. This book will help users and new
administrators make the system more secure, but there is much ground left
uncovered.

Chapter one is a basic overview of the NT security architecture. There are
some, but relatively few, specifics. The material also tends to give
Microsoft the benefit of the doubt in a number of areas. For example, the
fact that the source code for NT is not available is held in many quarters
to be a potential security risk, since the system cannot be fully examined.
While nobody can deny Microsoft's right to withhold the source for business
reasons, the author dismisses this security argument as "completely without
merit." The User Manager application is covered in chapter two. While all
functions are mentioned, not all implications are fully explained. While
implying that it is the case, the author stops short of stating that if
access rights are denied by one control they will not be granted because of
others. Coverage of file and file system security, in chapter three, is not
very clear. The material on viruses is technically sound, but not
necessarily immediately helpful. Event logs are discussed briefly in
chapter four but probably deserve more space. Chapter five not only looks
at the Registry itself, but lists a number of keys to be set. Again, the
brief discussions do not provide full information on the implications of
these choices. Although all the topics in chapter six do have to do with
network security, they are otherwise rather randomly grouped. Not all the
sections even have to do with NT. Also, there is, again, some not
altogether justified promotion of Microsoft, and some questionable
recommendations. (The suggestion to rename the administrator account is
fairly standard, but the renamed account may still be vulnerable to attack
because of identification of the security ID.) Chapter seven looks at RAID
(Redundant Array of Inexpensive Disks) and UPS (Uninterruptible Power
Supplies) and it is surprising that it doesn't mention backups. Remote
Access Service (RAS) is reviewed in chapter eight, but while recommendations
are made the full significance of the advice is not given. Generic advice
on Internet service provision is given in chapter nine. Not all of the
guidance makes a lot of sense, such as the discussion of passwords in regard
to anonymous ftp accounts.

The book does cover a lot more security ground than most general NT
administration texts. Some convoluted areas of NT security are explored to
a certain extent, and there are a number of helpful pieces of information.
Security, however, is a complex undertaking, and requires a more thorough
and rigorous background understanding than this book provides.

copyright Robert M. Slade, 1998 BKWNTSEC.RVW 980510

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

Date: Thu, 23 Jul 1998 13:19:38 -0800
From: "Rob Slade" <[email protected]>
Subject: Re: "Windows NT Security", Charles B. Rutstein (RISKS-19.89)

Boy, did that [the above review] ever open a can of worms! I cannot recall
any review that has generated this much response, this fast.

Sorry to those who did not get a personal response, and thanks to the
majority of you for your kind words about the reviews, but there were just
too many of you, mostly asking the same question. Almost all of you wanted
to know of an NT security book that I could recommend.

Well, I am sorry to disappoint you, but *I'd* like to know of an NT security
book that I could recommend. I haven't found one yet. (For those incipient
authors who are experts in the field, and have about a year to give to the
task, there is an apparent market niche.)

The reason for this lack may lie in a number of areas. As one correspondent
implied, many think that "NT security" is an oxymoron. I note that while
there are a variety of NT security resources out there, and there have been
a few attempts to start one, there is no really good NT security FAQ
available yet. There are a number of sites with exploit information, and
there is one vendor that tries to sell you an NT security file, but the
closest I've seen to a good FAQ was a recent "top ten" list of things to do
to make NT marginally more secure than it is when it ships.

I suspect that part of the problem lies in the design of NT itself, which
does not make security provisions straightforward to implement, but it may
also be simply bad luck in the selection of authors who have attempted to
address the issue so far. Of the number of NT security books I've reviewed
to date, I still haven't found a definitely good one, let alone anything to
the standard of Spafford and Garfinkel.

Just to reiterate, here are the titles I've reviewed so far:

<p><a href="bkpwntsg.rvw"> "PCWeek Microsoft Windows NT
Security"</a>, Nevin Lambert/Manish Patel, 1997,
1-56276-457-8, U$39.99/C$56.95/UK#36.99 - good introductory
or non-specialist guide, but there are holes

<p><a href="bkwntscg.rvw"> "Windows NT Security Guide"</a>, Stephen
A. Sutton, 1997, 0-201-41969-6, U$29.95/C$41.00 - too vague
for users, lacking detail for administrators

<p><a href="bkwntsec.rvw"> "Windows NT Security"</a>, Charles B.
Rutstein, 1997, 0-07-057833-8, U$34.95 - reasonable range,
but has gaps and lacks analysis

Normally, if I were recommending texts on security in the UNIX field, I
would also include works on system administration. However, in the NT
arena, while some admin authors have tried to cover the topic it is just too
big to handle as a subsection of a larger work.

[email protected] [email protected] [email protected]

For back issues:
AV contacts : http://www.victoria.tc.ca/techrev/mnvr.html
list, reviews,: http://www.victoria.tc.ca/techrev/quickref.html
review FAQ and: http://www.victoria.tc.ca/techrev/avrevfaq.html
AV tutorial : http://www.victoria.tc.ca/techrev/mnvrcv.html
http://csrc.ncsl.nist.gov/virus/virrevws/
ftp://ftp.cs.ucr.edu/pub/virus-l/docs/reviews
Viral Morality: http://www.bethel.edu/Ideas/virethic.html
PC Security: http://www.victoria.tc.ca/techrev/mnvrrvsc.html
Book reviews: http://www.victoria.tc.ca/techrev/mnbk.html
http://www.victoria.tc.ca/techrev/review.html
http://www.webwaves.com/books/slade
ftp://x2ftp.oulu.fi/pub/books/slade
http://mag.mechnet.com/mne/books/reviews/slade/
gopher://gopher.technical.powells.portland.or.us:70
http://www.utexas.edu/computer/vcl/bkreviews.html

[After considerable out-of-band discussion, the consensus seems to be
that Rob is correct: There are no good books on Windows NT security.
But perhaps that is because there is no real Windows NT security?
Let's hear it for open-source software, and hopefully, eventually,
really good open-source security, subjected to serious scrutiny. PGN]

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

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.89
************************