[1228] in RISKS Forum
RISKS DIGEST 18.07
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Thu Apr 25 19:57:26 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Thu, 25 Apr 96 16:56:31 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Thursday 25 April 1996 Volume 18 : Issue 07
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. *****
Contents:
Former Oracle worker charged with perjury: bogus e-mail (PGN)
A reminder about letter bombs in MSW6.0 [name withheld by request]
AOL censors British town's name! (Clive Feather, Rob Kling)
Re: Swedish court fines parents for son's overly long name (Viiveke F?k,
Gunnar Pettersson)
Computers and Social Unrest (Carl Wittnebert)
When the Clock Strikes 2000 (Edupage)
Re: MCI recommending bad security practices (Peter Scott)
Society and the Future of Computing '96, 16-19 Jun 1996, Snowbird, UT
(Jeffrey Johnson)
CERT (sm) Advisory CA-96.09, Vulnerability in rpc.statd (CERT)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 23 Apr 96 17:58:50 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Former Oracle worker charged with perjury: bogus e-mail
Adelyn Lee had won a $100K out-of-court settlement for wrongful termination
from Oracle in February 1995, claiming that she had been fired for refusing
to have sex with Oracle president Larry Ellison. She had apparently used as
evidence a piece of e-mail from her boss VP Craig Ramsey to Ellison,
confirming that Lee had been terminated as per Ellison's request. To make a
long story short, San Mateo County Deputy District Attorney Paul Wasserman
said that their investigation has now come to the conclusion that Ramsey
could not have sent the e-mail (because he was driving in his car at the time
according to cell-phone records) and that, as Ramsey's executive assistant,
Lee knew his passwords (and indeed had been responsible for changing them for
him periodically). Lee has now been charged with felony perjury for lying
and sending false e-mail. [Source: *San Francisco Chronicle*, 20 Apr 1996,
D1-2]
What are some of the conclusions for RISKS readers (not new)?
1. Don't believe e-mail FROM: headers accurately represent the sender.
2. Don't believe the content of e-mail, whether or not the headers
are correct.
3. Don't share your passwords overtly with anyone, or let someone else
be responsible for your passwords.
4. Don't use covertly compromisible reusable fixed passwords; how often
you change them is more or less irrelevant.
5. Use one-time nonreusable authentication tokens instead of fixed passwords.
6. Even if you use PEM, PGP, stronger-crypto e-mail, or whatever, you
cannot ensure authenticity, because of untrustworthy operating systems
and untrustworthy users.
7. Beware of trying to use e-mail as nonrepudiatable court evidence.
8. HOWEVER, don't believe that cell-phone records are valid as court
evidence; they too could be bogus or altered. If someone drags you
into court, find someone who can demonstrate how easily those records
could have been altered!
9. Etc., etc., etc.
------------------------------
Date: Tue, 23 Apr 96 17:58:50 PDT
From: "[name withheld by request]"
Subject: A reminder about letter bombs in MSW6.0
Today I got e-mail from Agptacek@aol.com. I have never received e-mail from
this account before. I have no idea who it is. All I got was the message
below --- "Pls. find file attached." --- plus a Microsoft Word 6.0 file.
Now, anybody who has been following the stuff with MSW6.0 knows that
executable code can be hidden in MSW6.0 files. Perhaps code to delete my
files. Or give me a new virus. [Or a nasty Trojan horse.]
Do you trust e-mail that anybody sends you?
>From: Agptacek@aol.com
>Date: Wed, 24 Apr 1996 01:02:03 -0400
>To: ***********
>Subject: Discovery Records
>MIME-Version: 1.0
>
>Content-ID: <0_18723_830322121@emout07.mail.aol.com.30083>
>Content-type: text/plain
>
>Pls. find file attached.
>
>Content-ID: <0_18723_830322121@emout07.mail.aol.com.30084>
>Content-type: application/applefile;
> name="Discovery";
> X-Mac-Creator="4d535744";
> X-Mac-Type="5736424e"
>
>Attachment converted: Asher:Discovery 1 (W6BN/MSWD) (00008B8A)
------------------------------
Date: Wed, 17 Apr 1996 15:28:52 +0100 (BST)
From: Clive Feather <cdwf@cityscape.co.uk>
Subject: AOL censors British town's name!
[Clive forwarded to RISKS an long item from the Computer underground Digest,
Thu Apr 11, 1996, Volume 8 : Issue 29, ISSN 1004-042X, from Doug Blackie
<STEELBEAT@aol.com> that relates an experience Doug had in trying to
register with AOL. He entered his name "Blackie" and his home town
"Scunthorpe", and found that AOL's (indecency-filtering) registration
program would not accept that combination. After various discussions with
the AOL folks in Dublin, he discovered that he could register properly if
he entered the town as "Sconthorpe". As a result of this curious situation,
AOL has announced that the name of the town will henceforth be known as
"Sconthorpe". The entire saga is documented in the Scunthorpe Evening
Telegraph (final edition) of Tuesday, 9 Apr 1996, issue number 30111,
printed and published by Grimsby and Scunthorpe Newspapers Ltd., Telegraph
House, Doncaster Road, Scunthorpe, DN15 7RE, UK. The article was provided
on-line by David G. Bell <dbell@zhochaka.demon.co.uk>, and was included as
a part of Doug Blackie's message. PGN Abstracting.]
------------------------------
Date: Thu, 25 Apr 1996 11:10:22 -0700
From: kling@ics.uci.edu (Rob Kling)
Subject: Re: AOL censors town's name!
[The previous item contributed by Clive Feather touches on some further
serious issues relating to the effectiveness, propriety, and risks
involved in filters that attempt to censor on the basis of linguistic
strings; as other examples, side-effects of filtering "couples"
(RISKS-17.79) and "xxx" (SurfWatch, RISKS-17.81) have been noted in recent
RISKS postings.
Rob Kling is a member of the ACM Committee on Computers and Public Policy,
the umbrella organization in ACM for RISKS. He had the following comments
upon seeing the above message; his comments address just a few of the RISKS
issues raised. PGN]
There is a lot of info regarding Scunthorpe obtainable via Alta Vista.
This is a real city and its integrity deserves respect, even if it is
not exactly a place well-known to people in the US. [For example, see
http://www.computerprint.co.uk/scunthorpe/travel.html and
http://www.computerprint.co.uk/scunthorpe/history.html .]
I can imagine that there might even be some people with the last name of
Scunthorpe. The willingness of AOL (or other services) to excise identities
in the name of "decency" raises big issues of genuine decency in my view.
Rob Kling
------------------------------
Date: Wed, 24 Apr 1996 08:52:41 +0200
From: viiveke@isy.liu.se (Viiveke F?k (?= a letter UNIX can't handle))
Subject: Re: Swedish court fines parents for son's overly long name
The law in question states that parents should report the name they have
chosen for their children within a specified time after birth (three months
I think). The authorities in their turn has a rule saying that they should
not allow registration of names that are likely to cause harassment or other
obvious drawbacks for the child, like giving a girl what is traditionally
exclusively a boy's name and vice versa. Another recent case was when
parents were not allowed to name their girl Ikea (a constructed name for a
fairly well-known furniture company) and an older example was when another
girl could not be named Veranda (which means exactly the same in Swedish).
What has this got to do with computers and risks? The parent's choice of
name in this case is a protest against bureaucracy in general, one part of
which is that the authorities have indeed a limit on how many characters
that they register for each child. (The row of letters is as impossible to
pronounce in Swedish as it is in English. Albin is of course a perfectly
valid name here too.)
As for computers and real risks, this is an international question about
assumptions of name structure and their use in design of computer systems.
We often even can't handle our own in Sweden. Swedes for example typically
have from one to three first names, and they choose themselves which one
that they use daily. That choice is reported, but many computer systems do
not register it. Normally it is the first "first name", but not
necessarily. Which means that there are mix-ups, when for example a
computer sends a letter to George Thomas Smith addressed to "George Smith",
and that happens to be what the father is not called (he uses his second
name Thomas) but it also happens to be what the son (Andrew Charles George
Smith) actually is called. This happened in my husband's family, and guess
how much trouble there was when the son tried to report that he was moving
to a new address... As for myself, I sometimes give in and register my
second "first name" as "middle name" when travelling, so that passport
authorities do not complain that I do have a "middle name" and should fill
it in. But if you come to Sweden and marry someone here, it is very likely
that you can not register that child's middle name, because it is
"offensive" as a first name, and we only register first and family names.
Viiveke F=E5k, Department of Electrical Engineering, Link=F6ping University
S-581 83 Link=F6ping Sweden +46 13 281722 Viiveke@isy.liu.se
[Incidentally, Albin's would-be given name (noted in RISKS-18.06)
had one occurrence of the putatively heinous "xxx". Perhaps we
will all someday have to be identified by multilingually and
transnationally filtered globally biunique identifiers -- to
accommodate our computer systems. (Note that Internet addresses and
phone numbers are unique if globally qualified, but are not biunique
-- because they may be shared by multiple personalities). PGN]
------------------------------
Date: Thu, 25 Apr 1996 16:59:09 +0000
From: Gunnar Pettersson <gunnar.pettersson@powrd.demon.co.uk>
Subject: Re: Swedish court fines parents for son's overly long name (R-18.06)
The law that was broken is the Swedish 'Name Law' (SFS 1982:670) and the
authority which deals with its implementation is the Swedish Patent &
Registration Office.
Not having seen the detailed judgement in this case, I would guess that the
law was seen to have been broken in at least two ways. First a technical
reason: as your correspondent surmises, the name would have been regarded
as far too unmanageable for inclusion in the computerized Civic
Registration data held on all Swedish citizens. Secondly, and perhaps more
importantly, the law explicitly prohibits forenames "which can cause
offence, or may lead to any inconvenience for the bearer, or is for any
other reason obviously unsuitable as a forename".
As far as the meaning of the name 'Brfxxx...' is concerned, I would have
thought it is to be found precisely in its lack of meaning. And, whatever
one thinks of a law like the Swedish one, what about the poor kid himself?
Cases like this one tend to prove very little about the law itself, and much
more about the pretty warped attitude some people have towards their
offspring...
The Swedish name law, on which most other Nordic name laws are based, is
nonetheless unusually restrictive as far as choosing and changing names are
concerned. However, it should be pointed out that practically every other
country, with the exception of the UK and parts of the US, have *some* form
of restriction on names: e.g. Germans can't change their names to Hitler;
French forenames must be taken from saints and/or antiquity; etc. etc.
In Nov 1992, I wrote and presented a talk on BBC radio, "Names Never Hurt
You", which deals with the social and political aspects of name laws, with
particular emphasis on Sweden. If anyone would like a transcript, please
e-mail me.
------------------------------
Date: Thu, 25 Apr 1996 04:09:05 -0700 (PDT)
From: Carl Wittnebert <cewit@wco.com>
Subject: Computers and Social Unrest
A potentially earthshaking risk of using computers is currently being
discussed at the highest levels of the U. S. government. The risk involves
human skill obsolescence, a growing wage gap between skilled and unskilled
workers, and possible social unrest. The phenomenon may underlie the themes
of economic nationalism and protectionism that have surfaced during the
current Presidential campaign.
The *Wall Street Journal* devoted a front-page column to the topic on 22 Apr
1996. It quoted Federal Reserve Board Chairman Alan Greenspan as saying,
"Human skills are subject to obsolescence at a rate perhaps unprecedented in
American history." It went on to quote George David, chief executive officer
at United Technologies Corp., who believes that 18 million U.S. workers are
"at risk" because their jobs are "prone to automation."
Upheaval in the nature of work--in manufacturing in the 1980's, and now in
the service sector--has been discussed for some time, usually under the
assumption that additional jobs would be created to replace the ones lost to
machines. Increasingly, the question is arising as to just how much the new
jobs are going to pay.
------------------------------
Date: Tue, 23 Apr 1996 17:34:05 -0400 (EDT)
From: Edupage Editors <educom@elanor.oit.unc.edu>
Subject: When the Clock Strikes 2000 (Edupage, 23 Apr 1996)
The Gartner Group in Stamford, Connecticut, says the federal government will
spend about $30 billion to modify a massive number of computer programs in
which years were coded simply as two-digit numbers (without identifying the
century) and which will have to be fixed so that they can correctly calculate
things like benefits payments. It is also estimated that by the time the
year 2000 comes around only 70% of government computer programs will have
been modified to deal with the problem. (*Computerworld*, 22 Apr 1996 p1)
[See RISKS-17.82 for global estimates of something around half a trillion
dollars, also from the Gartner Group. PGN]
------------------------------
Date: Wed, 24 Apr 1996 09:33:51 -0700
From: pjscott@euclid.Jpl.Nasa.Gov (Peter Scott)
Subject: Re: MCI recommending bad security practices (McDaniel, RISKS-18.06)
> For some strange reason MCI is recommending you to do exactly the opposite
> of what good security practices would proscribe! Not only do they suggest
^
Now there's an example of a misspelling-type RISK [reversing the meaning!].
Peter Scott, NASA/JPL/Caltech Peter.J.Scott@jpl.nasa.gov
------------------------------
Date: Thu, 25 Apr 1996 10:06:56 -0700
From: Jeffrey.Johnson@Eng.Sun.COM (Jeff Johnson)
Subject: Society and the Future of Computing '96, 16-19 Jun 1996, Snowbird, UT
Society and the Future of Computing '96
June 16-20, 1996
Cliff Lodge
Snowbird, Utah
http://www.lanl.gov/SFC
Sponsor: USACM. Contact Rick Light, Los Alamos National Lab, MS B294,
Group CIC-7, Los Alamos, NM 87545, phone 505/667-0744, e-mail
rxl@lanl.gov, Web: http://www.lanl.gov/SFC/96/sfcHome.html.
This conference provides a multidisciplinary forum to articulate novel
research directions that advance computer science in ways that are truly
beneficial to society. Participants will share, explore, and demonstrate
the responsible use of advanced scientific computing and National
Information Infrastructure (NII) Program technologies for the benefit of
diverse communities.
The conference structure includes keynote speakers, panels of invited
speakers in which attendees and the panelists engage each other in open
discussions of the issues, interactive poster presentations, debates, and
workshops. The intent is to share ideas in a multidisciplinary environment
for mutual enrichment and learning, ultimately to affect the directions of
computer science research and applications for the benefit of all. The
conference Web site includes the preliminary conference agenda and will
continue to provide the latest information as the conference design unfolds.
Keynote speakers:
Tom Landauer, U. of Colorado (Boulder): "Computers, Usefulness,
Usability, Productivity, and Happiness"
Laura Breeden, formerly of of US Commerce Dept. NTIA: "Whose
Voice is Heard? Listening to the Computer and Communications
Revolution"
Bill Wulf, University of Virginia: "Information Technology
is the Lever, But Where Shall We Stand?"
Panels:
Creating the Future: Computer Industry Research Lab Heads
Rick Light, Moderator
Working in the Networked Economy: Issues
Gary Chapman, Moderator
Working in the Networked Economy: Opportunities
Phil Agre, Moderator
Contrasting Images of the Future
Allan Kuchinsky, Moderator
The European Information Society (live from Europe)
Terry Bynum, Moderator
If Anyone Can Publish, Who Will Edit?
Karen Coyle, Moderator
On the Internet, No One Knows You're a Dog
Brenda Allen, Moderator
Government On-Line: Report Card and Futures
Charles Brownstein, Moderator
Workshops:
Shneiderman: "The Durango Declaration Continued: Toward
a Snowbird Conference Statement"
Cisler, Uncapher, Press: "Implications of the Net for Industrialized
Countries, Developing Nations, and Indigenous Cultures"
Epstein: "Emerging Realities, Virtual and Otherwise"
Meyer: "Anthropology and Computer Technologies"
------------------------------
Date: Wed, 24 Apr 1996 14:25:09 -0400
From: CERT Advisory <cert-advisory@cert.org>
Subject: CERT (sm) Advisory CA-96.09, 24 Apr 1996, Vulnerability in rpc.statd
The CERT Coordination Center has received reports of a vulnerability in
rpc.statd (rpc.statd is also known as statd on some systems). As of the
date of this advisory, we have received no reports of this vulnerability
being exploited.
If exploited, this vulnerability can be used to remove any file that the
root user can remove or to create any file that the root user can
create.
Section III and Appendix A contain information from vendors. Appendix B
contains an example of a possible workaround.
As we receive additional information relating to this advisory, we will
place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.09.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
I. Description
rpc.statd, also called statd, is the NFS file-locking status monitor. It
interacts with rpc.lockd, also called lockd, to provide the crash and
recovery functions for file locking across NFS.
NFS is stateless, which means that NFS clients and servers can be
rebooted without a loss of file integrity due to NFS. In contrast, NFS
file locking is stateful. To achieve this stateful nature in a stateless
environment, rpc.lockd must work with rpc.statd to add state to file
locking.
To understand what rpc.statd does, it is first necessary to understand
what rpc.lockd does. rpc.lockd processes lock requests that are sent
either locally by the kernel or remotely by another lock daemon.
rpc.lockd forwards lock requests for remote NFS files to the NFS server's
lock daemon using Remote Procedure Calls (RPC).
rpc.lockd then requests monitoring service from the status monitor
daemon, rpc.statd, running on the NFS server. Monitoring services are
needed because file locks are maintained in the NFS server kernel. In
the event of a system crash or reboot, all NFS locks would normally be
lost. It is rpc.statd that adds stateful file locking.
When an NFS server reboots, rpc.statd causes the previously held locks
to be recovered by notifying the NFS client lock daemons to resubmit
previously granted lock requests. If a lock daemon fails to secure a
previously granted lock on the NFS server, it sends SIGLOST to the
process that originally requested the file lock.
The vulnerability in rpc.statd is its lack of validation of the
information it receives from what is presumed to be the remote rpc.lockd.
Because rpc.statd normally runs as root and because it does not validate
this information, rpc.statd can be made to remove or create any file that
the root user can remove or create on the NFS server.
II. Impact
Any file that root could remove can be removed by rpc.statd. Any file
that root could create can be created by rpc.statd, albeit with mode 200.
III. Solution
The general solution to this problem is to replace the rpc.statd daemon
with one that validates the information sent to it by the remote
rpc.lockd. We recommend that you install a patch from your vendor if
possible. If a patch is not available for your system, we recommend
contacting your vendor and requesting that a patch be developed as soon
as possible. In the meantime, consider whether the information in
Appendix B is applicable to your site.
Vendor Information
------------------
Below is a summary list of the vendors who have reported to us as of the
date of this advisory.
Patch information and other details are in Appendix A of this advisory
and reproduced in the CA-96.09.README file. We will update the README
file as we receive more information.
If your vendor's name is not on this list, please contact the vendor
directly.
Vendor Status
------ ------------
Apple Computer, Inc. vulnerable - A/UX version 3.1.1 and
earlier; AIX 4.1.4 for the Apple
Network Server
Berkeley Software Design, Inc. not vulnerable - BSD/OS
Cray Research, Inc. vulnerable - Unicos version 9.0 and
higher
Data General Corporation vulnerable - DG/UX R4.11
Digital Equipment Corporation vulnerable - UNIX (OSF/1) V3.0 through
V3.2d; ULTRIX V4.3 through V4.5
Harris Computer Systems Corp. vulnerable - all versions of NightHawk
CX/UX and PowerUX
not vulnerable - all versions of
NightHawk CX/SX and CyberGuard CX/SX
Hewlett-Packard Company vulnerable - 9.X and 10.X
IBM Corporation vulnerable - AIX 3.2 and 4.1
NEC Corporation some systems vulnerable
NeXT Software, Inc. vulnerable - versions before 4.0;
will be fixed in 4.0
The Santa Cruz Operation, Inc. not vulnerable - SCO UnixWare 2.x.;
SCO OpenServer 3.0, 5; SCO Open Desktop
2.x, 3.x; SCO NFS 1.x.x.
Silicon Graphics, Inc. vulnerable - all versions of IRIX except
6.2
not vulnerable - IRIX 6.2
Sony Corporation vulnerable - NEWS-OS 4.2.1, 6.0.3, 6.1,
and 6.1.1
Sun Microsystems, Inc. believed to be vulnerable - SunOS 4.x
and Solaris 2.x
The CERT Coordination Center thanks Andrew Gross of the San Diego
Supercomputer Center for reporting this problem and Wolfgang Ley of DFN-CERT
for his support in responding to this problem.
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident
Response and Security Teams (FIRST).
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890 USA
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
http://www.cert.org/
ftp://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
cert-advisory-request@cert.org
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
[Appendices removed for RISKS.]
------------------------------
Date: 18 March 1996 (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) 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 <risks-request@csl.sri.com> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for unabridged version of RISKS information]
CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution. Diversity is welcome, but not personal attacks. [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Particularly relevant contributions may be adapted for the RISKS sections
of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review.
* Submissions: By submitting an item that is accepted for publication
in RISKS, the author grants permission for unlimited public distribution
and redistribution in electronic or other form.
* Reuse: Blanket permission is hereby granted for reuse of all materials
in RISKS, under the following conditions. All redistributed items must
include the Risks-Forum masthead line. All reuse must be accompanied by
the following statement:
Reused without explicit authorization under blanket permission
granted for all Risks-Forum Digest materials. The author(s), the
RISKS moderator, and the ACM have no connection with this reuse.
As a courtesy, reusers of individual items (as opposed to forwardings of
entire issues) should notify the authors, and should pay particular
attention to any subsequent corrections.
RISKS ARCHIVES: "ftp ftp.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://ftp.sri.com/risks
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
PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
see the unabridged INFO file at RISKS-Request (send one-line message INFO
to risks-request@CSL.sri.com as noted above).
------------------------------
End of RISKS-FORUM Digest 18.07
************************
