[1258] in RISKS Forum
RISKS DIGEST 18.37
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Thu Aug 22 20:04:59 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Thu, 22 Aug 96 17:03:47 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Thursday 22 August 1996 Volume 18 : Issue 37
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:
Karpov versus the world via Internet (PGN)
SSN problem hits a Congressman (Stanton McCandlish)
Easy answer on porno? (Tim Barmann via Dave Farber and Stanton McCandlish)
Rich folks embrace digital privacy and anonymous markets (Peter Wayner)
Re: Internet Explorer security problem (Thomas Reardon)
Inability to tinker not confined to hardware (Scott Alastair)
Re: Computer testing of nuclear weapons (Robert Herndon, Mark Stalzer,
Barry Jaspan, Frank C. Ferguson)
Measuring software time to repair (Stu Savory)
Long-running systems (Martyn Thomas)
Call for Participation: SEI Conference on Risk Management (Carol Biesecker)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 22 Aug 96 14:46:39 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Karpov versus the world via Internet
An unusual kind of Internet chess game will be held next week in Finland,
sponsored by Telecom Finland. Anatoly Karpov will be pitted against the
consensus of a collection of on-line participants, estimated to be around
50,000 in number, where after each of Karpov's moves the wannabes get 10
minutes of real time to think, and a Telecom computer will pick the most
popular move. Check out http://www.tele.fi/karpov for details.
What are the risks?
1. What if 100,000 opponents show up and overwhelm the website?
2. Will a dumbed-down consensus result? Can a few master-level players
have any impact over a horde of average players?
3. How can any coherent strategy emerge from such a consensus strategy?
4. Could the resulting somewhat randomized strategy actually be more
effective than a more coherent strategy? (Garry Kasparov had an
interesting time figuring out IBM's Deep Blue strategy, and beat it
with a less coherent approach than he might normally have taken.
See RISKS-17.79.)
5. Could Kasparov hack his way into tele.fi and reprogram the software
so that only HIS move was tabulated? Certainly the organizers could
do that, but it would spoil the fun.
6. Could Karpov use a Finnish anonymizer and then, if he lost, repudiate
the results by claiming it was really Kasparov who was playing?
------------------------------
Date: Thu, 22 Aug 1996 11:35:54 -0700 (PDT)
From: Stanton McCandlish <mech@eff.org>
Subject: SSN problem hits a Congressman
I received a press call this morning asking about Social Security Numbers
and database privacy in general, from a journalist covering a story that
should have happened years ago.
A US Congressman running for Governor of New Hampshire was found to have
two SSNs by local journalists, who ran a story on it. (It's illegal to
obtain 2 SSNs in most circumstances, so one supposes this seemed newsworthy).
After the story ran, it turned out that the other SSN belonged to a teenager,
and that the legislator had been assigned the number (presumably in some
marketing or DMV or other error-prone database) by mistake. Despite the
situation not being the legislator's fault, his chances for election to
the Governor post have been damaged by the bad reportage, possibly ruined.
At this point, I don't have the name of the legislator, nor of the paper
and journalist(s) who reported on this.
Many obvious RISKs that have come up before plenty of times in RISKS:
1) SSNs are not a good system - they are neither truly unique
identifiers, nor is the system even close to immune from errors or fraud.
2) Even "minor" data entry errors in databases of personally identifiable
information can ruin careers and otherwise wreck people's lives, but there's
not really any easy way to detect these errors or to fix them until they
cause a personal, or sometimes far broader, catastrophe.
3) There is no real accountability, even aside from privacy issues. State
laws are scattershot and disparate, affording little privacy protection
and even less recourse when negligence wreaks havoc. They are so
different from state to state that even an industry-generated code of
conduct doesn't arise. At the federal level, it's even worse.
4) Reporting on technical topics, like information held in databases, can
be rapidly screwed up if the reporters do not take care to get the facts,
but simply report what seems obvious on the surface. (C.f. Time's
"Cyberporn" cover story for another infamous example.)
5) Blind trust in technology - "the computer is always right" - can lead to
quite harmful mistakes. It appears that the reporters who jumped on this
story accepted it as a given that the legislator had obtained two SSNs
for some nefarious purpose, and missed the far more likely possibility:
data entry error by a third party.
[This is based on what I've been told about these events and the
reportage of them. I have yet to see the original articles, though I
expect to get them shortly. So, some of this criticism is best considered
hypothetical, until I do have the articles. I cannot, of course, be
certain of the accuracy of the characterization by one journalist of
another and his/her work.]
As for why I say this should have happened a long time ago, this is the
first time I've heard of something like this happening to a policymaker.
Hopefully the nature of the problem will sink in and we'll see some action
to establish accountability and privacy-protection requirements. At very
least, the dismal failure of the SSN may become more apparent to Congress,
who have simply not appeared to grasp the nature of the problems to date.
The new crypto-awareness on the Hill could use a strong booster shot of
general privacy awareness.
Stanton McCandlish Electronic Frontier Foundation mech@eff.org
"http://www.eff.org/~mech/"
[This saga is quite skimpy, but is the best available at the
moment. I hope someone can fill in the details for us. PGN]
------------------------------
Date: Thu, 22 Aug 1996 12:16:18 -0700 (PDT)
From: Stanton McCandlish <mech@eff.org>
Subject: Easy answer on porno? (Tim Barmann via Dave Farber)
[Via Dave Farber <farber@central.cis.upenn.edu>]
>From: Timothy Barmann <tim@cybertalk.com>
Subject: Warning from Family Circle Magazine
Got this amusing/disturbing press release from *Family Circle Magazine*,
apparently to promote an upcoming article. It reads:
>CERTAIN COMPUTER FILE LETTERS INDICATE PORNOGRAPHY: POLICE CHIEF
>
>New York -- Parents can safeguard their children against pornography on
>the internet by watching for files stored on a computer's hard drive or
>diskettes that end in the letters -PCX, -GIF, -GL, TIF, or -JPG, according
>to the current (September 17) issue of Family Circle. "Those are the
>graphic image files that may be pornographic, and parents should know what
>they illustrate," says Police Chief Alfred Olsen, who monitors online
>predators in Pennsylvania.
I'm surprise that TXT was left out, which of course is the format used to
distribute sexually explicit words as well.
Timothy Barmann, *Providence Journal-Bulletin* tim@cybertalk.com
401-277-7369 http://www.ids.net/~tim/ http://www.ids.net/cybertalk/
------------------------------
Date: Tue, 20 Aug 1996 21:18:10 -0400
From: pcw@access.digex.net (Peter Wayner)
Subject: Rich folks embrace digital privacy and anonymous markets
Two items from the recent news:
1) The August 7th edition of the WSJ has a front page story on the divorce
of cellular phone king, Craig McCaw. Here's the salient phrase, "... Mr.
McCaw says in an interview via a wire-line phone to which he entrusts all
sensitive conversations because he is leery of eavesdropping on his cellular
calls." Given that the call was at least partly on the record, I wonder how
he handles his truly sensitive calls.
2) The August 20th edition of the NYT describes the effects of the recent
settlement between NASDAQ and the SEC. The NASDAQ marketplace is essentially
a computer network that links a group of dealers who use the system to make
announcements like "I want to buy Microsoft for 92 dollars/share." A
brokerage firm will often make a profit on the difference and not pass it on
to their customers. If someone breaks the spread, all of the brokers suffer
but the customers generally gain a small advantage. The SEC now has audio
tapes of some dealers using collusion and social pressure to keep the
spreads up between the price the shares are offered to buy and sell.
There is also another market ran by Reuters known as "Instinet" and it is
anonymous. No one knows who is offering to buy and sell shares. If someone
breaks from the pack and starts offering slightly more money for a
particular issue, there is no easy way for the dealers to retaliate. It's
all anonymous. The article suggests that prices are often fairer for the
people who use Instinet. Of course it is only open to big folks like
institutional investors. Presumably it is not truly anonymous and the SEC
could unwind the trades if it wanted to investigate, say, insider trading.
------------------------------
Date: Thu, 22 Aug 1996 15:49:33 -0700
From: Thomas Reardon <thomasre@MICROSOFT.com>
Subject: Re: Internet Explorer security problem (Felten, RISKS-18.36)
>We have discovered a security flaw in the current version (3.0) of
>Microsoft's Internet Explorer browser running under Windows 95. An
>attacker could exploit the flaw to run any DOS command on the machine
>of an Explorer user who visits the attacker's page.
We now post the virus warning dialog on local files (file: urls). We have
always posted it on remote files (http: urls). Note that the root of the
problem is not Java or the browser, but in macro-enabled applications. IE3
has a mechanism to warn users about safety of documents when used with
common macro-enabled applications. We are have updated Microsoft Word such
that by default it will not run macros embedded in documents.
-Thomas
------------------------------
Date: Wed, 21 Aug 1996 15:09:33 +0100
From: "Scott Alastair (Exchange)" <ScottA@logica.com>
Subject: Inability to tinker not confined to hardware
People can't tinker with software either these days ... for example,
there is no programming language supplied with Windows 95.
>From this, a RISK is that a program of any degree of triviality may be seen
by a lay person as miraculous. I wrote a Word for Windows macro to generate
chess board positions out of sheer necessity - I needed pictures for a
magazine article I was writing and no software I had could generate them
easily. I then realised that my macro might be useful to other people. So I
uploaded it to an archive site - and the response was phenomenal, with
emails coming in by the dozen praising what I have done. Yet the macro is
made up of about fifty lines of code, there are no devious tricks and the
algorithm used to generate the chess board from user input is relatively
simple. I am a software engineer; if I was incapable of writing such a macro
I would wonder whether I was fit to be called a software engineer.
Who was it who wrote that "any sufficiently advanced technology is
indistinguishable from magic"? They are right, and they are becoming more
than right.
Alastair Scott <scotta@logica.com>
------------------------------
Date: Wed, 21 Aug 1996 18:12:24 -0600
From: robert.herndon@Central.Sun.COM (Robert Herndon)
Subject: Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)
Frank Ferguson <ferguson@dmapub.dma.org> notes in RISKS DIGEST 18.36 that
the U.S. Department Of Energy has signed a US$94M deal with IBM to develop
a new supercomputer designed specifically to simulate nuclear explosions.
Frank's conclusions, however, don't follow.
The U.S. DOE is almost certainly the worlds' largest consumer of high-speed
computers used for simulation, and has in fact been instrumental in the
funding and development of these computers. Richard Rhodes' books on
the development and construction of the first A and H bombs makes this
abundantly clear, as do many other books on the subject, and others on
other subjects (e.g., Richard Feynman's book that mentions his activities
during WWII). Many U.S. DOE atomic labs already have large supercomputer
centers devoted to simulation.
While the purpose of the computers is to simulate nuclear events, their
intended purpose is not generally to eliminate all nuclear tests. The
computer codes are worth discussion. They are, as a former chairman of
CDC noted in a speech many years ago, the human race's best understanding
of nuclear events. As a result, these codes are highly classified. A
great many complex, coupled, and inter-related phenomena occur during an
explosion. Among them are radiative, particle, and shock phenomena. The
need for models of these phenomena was probably first determined by Hans
Bethe, several years before the first A bomb explosion, and it was also
he who first developed the idea of Monte Carlo (probabalistic) simulation.
While the physics of each individual aspect of a detonation is well
understood, their coupling is very complex. E.g., radiative opacity
is determined in part by temperature, which is affected by radiative
and particle absorption. Many of the constants affecting these
phenomena and their couplings cannot be determined accurately by
a priori computation, and must be measured or approximated.
As a result, the computer models are the only way, other than actually
detonating a device, of accurately estimating the yield and efficiency
of a new design. In complementary fashion, the only way of reliably
improving the accuracy of the simulation codes is fashioning devices
and measurement equipment and testing them. This is in fact done.
Indeed, I have been given to understand by several knowledgeable people
that the purpose of nuclear tests is most often to verify improvements to
the computer models. It is a deep-rooted need of humans to understand
the universe. The codes modeling the detonation of nuclear devices would
appear to be monuments to this (cold-war fear, too, I imagine). The rapid
development of the neutron bomb (er, "enhanced radiation device") would
appear to be a testament to the reliability and accuracy of these codes.
Certainly, the current efficiency of nuclear devices is such that extinction
of the human race can be safely assured, if such a goal is considered
desirable. It becomes perhaps questionable, then, what additional
sophistication in the simulation and design of nuclear devices is intended
to accomplish, beyond satisfying this curiosity.
The risk is slight that the U.S. will design, build, and deploy nuclear
devices that fail to work due to failures of the computer models. Fear
that physical/computer models might not be reliable was definitely
responsible for tests of cruder-than-necessary bombs (e.g., the USSR's
first A and H bombs, and several early U.S. devices (see Rhodes' books)).
The risk seems many orders of magnitude greater that, due to test bans,
the U.S. will spend large sums of money simulating and designing nuclear
devices that it cannot test, manufacture, or deploy. In the absence of
test ban treaties, the risk is that the U.S. will detonate additional
devices to verify the more complex models that the faster computers will
allow (highly probable).
Robert Herndon
------------------------------
Date: Thu, 22 Aug 1996 13:53:13 -0700
From: stalzer@macaw.hrl.hac.com (Mark Stalzer)
Subject: Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)
In RISKS-18.36 Frank C. Ferguson <ferguson@dmapub.dma.org> takes some
issue with the idea of relying on computers to design nuclear weapons.
He writes in part:
>I guess eliminating an actual explosion, or "rapid disassembly" as the Air
>Force labels it, would reduce a lot of risks, wouldn't it? Hmmmm.
>
>I suspect we would soon be building weapons that would never work when the
>real trigger was actually squeezed.
Computers are useful for many simulations related to nuclear weapons
other than designing clever little devices that rapidly disassemble in
spectacular ways. A few examples are:
a. predicting the destructiveness of a particular device with known
characteristics (determined by testing) when used in a particular area.
b. predicting the fallout in various geographic areas and weather conditions.
c. finding out what happens if a device is accidentally smashed, eg.
is unintentionally dropped from a plane (this has happened many times!),
does it blow up or is the bomb stuff contained?
d. performing fusion energy experiments prior to building the apparatus.
e. refining existing designs and exploring completely new concepts.
Many tasks involve taking known weapons and exploring their behavior in
situations where real testing is impossible. Even if the US stopped all
weapons design, there would have to be a lot of simulation just to
explore the capabilities, limitations, and safety related issues of the
current stockpile.
Some WWW references to IBM's and Intel's new machines and their
applications are:
http://www.austin.ibm.com/Cover/Announce.960726/doepress.html
http://www.ssd.intel.com:80/tflop.html
It should be noted that weapons work is just a part of what's planned
for these next generation supercomputers.
Mark Stalzer, mas@acm.org
[Other comments on this topic also received from
"Christopher Duro" <cduro@softkey.com>
nelson@berlioz.nsc.com (Taed Nelson)
Jerry Bakin <bakin@haas.berkeley.edu>.
PGN]
------------------------------
Date: Wed, 21 Aug 1996 15:06:07 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Subject: Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)
I recently pointed out how the plot of the movie _The Running Man_ was
the same as a something suggested here in RISKS. So I cannot avoid
mentioning:
>> to use the new computer ... to determine which country wins a war without
>> actually fighting the war.
The original Star Trek episode "A Taste of Armaggedon" was based on exactly
this premise. There is nothing new under the sun...
Barry
[Noted in greater detail by "Jonathan I. Kamens" <jik@cam.ov.com>. PGN]
------------------------------
Date: Thu, 22 Aug 1996 14:56:43 -0400 (EDT)
From: "Frank C. Ferguson" <ferguson@dmapub.dma.org>
Subject: Re: Computer testing of nuclear weapons (RISKS-18.36)
[In response to Jonathan Kamens noting Star Trek was 30 years ago.]
Actually I think the ancient Chinese were the first. They simply assembled
opposing armies on opposite hilltops while the intermediaries met in the
valley. They decided which army was most likely to win and then they all
returned home.
Frank Ferguson
------------------------------
Date: Wed, 21 Aug 1996 10:03:08 +0200
From: Stu Savory <savory.pad@sni.de>
Subject: Re: Measuring software time to repair
Further to David Holland's comments...
Here (at Siemens Nixdorf Informationssysteme) incoming bug-reports
are classified 1 through 4 in severity level as perceived by the user.
They are also classified according the department responsible for the
code (1 through N). For each of these 4*N classes we have the historical
statistical distributions of (inter alia) bug fix times and bug densities
as well as improvement trends (and some other correlations ;-)
Inasmuch as one is able to predict the future statistically from the past,
we are able to say something like "There is a (50/90/99%) chance that this
bug will be fixed within time T".
I don't think you can do much better than this in the long run. I tried
training a neural net last year, but the prediction accuracy doesn't seem to
be much better (usual statistical test).
Dr. Stuart Savory Dept. of Quality & Customer Satisfaction.
------------------------------
Date: Wed, 21 Aug 1996 10:56:22 +0100 (BST)
From: Martyn Thomas <mct@praxis.co.uk>
Subject: Long-running systems
We have had a request from a client to rerun the training course on how to
start a system we delivered to them. It hasn't stopped for 18 months and
they have lost confidence that they can restart it if they need to do so.
So, it isn't only systems that get patched and warm-booted that lose the
ability to be cold-booted.
Is this a risk arising from delivering high-quality software?
Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel: +44-1225-444700. Email: mct@praxis.co.uk Fax: +44-1225-465205
------------------------------
Date: 21 Aug 1996 20:40:10 GMT
From: cb@SEI.CMU.EDU (Carol Biesecker)
Subject: Call for Participation: SEI Conference on Risk Management
Call for Participation - Software Engineering Institute (SEI)
Conference on Risk Management: Managing Uncertainty in a Changing World
Hotel Cavalier, Virginia Beach, Virginia, April 7-9, 1997
Keywords: acquisition, programs, projects, systems, and software
Note: this is an abbreviated call for participation [and excerpted for RISKS].
For complete information, please see
http://www.sei.cmu.edu/products/risk97
The SEI Conference on Risk Management will provide a forum that brings
together representatives of government, industry, and academic managers.
Practitioners, change agents, and researchers who use and explore risk
management, system development and acquisition will detail the latest
methods, tools, and techniques in the field.
This conference will provide a unique opportunity to
* Increase your awareness
* Advance your knowledge and skills
* Exchange ideas and experiences with experts
* Learn the latest methods, tools, and techniques and best practices
of acquisition, systems development, and risk management
* Find out what's new, what's going on, and what could be useful for you
September 19, 1996: deadline for submitting papers and workshop proposals
For more information about the conference, contact--
SEI Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone 412 / 268-5800
FAX 412 / 268-5758
Email customer-relations@sei.cmu.edu
World Wide Web http://www.sei.cmu.edu
------------------------------
Date: 1 April 1996 (no fooling!) (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from 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. U.S.
users on .mil or .gov domains should contact <risks-request@pica.army.mil>
(Dennis Rears <drears@pica.army.mil>). UK subscribers please contact
<Lindsay.Marshall@newcastle.ac.uk>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
the newly automated <risks-request@csl.sri.com>, with first text line
SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
INFO
gets you this file.
HELP
gives instructions on using the Majordomo listserver in other ways,
although not all are yet implemented for RISKS.
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. By submitting an item that is accepted for publication in
RISKS, the author grants permission for unlimited noncommercial public
distribution and redistribution in electronic and print form.
Diversity of content is welcome, but not personal attacks. PLEASE DO
NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses. Contributions will not be
ACKed; the load is too great; if you feel neglected, send a follow-up message.
**PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
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 can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [yes, VL = volume, IS= issue]
(Please report any format errors to Lindsay.Marshall@newcastle.ac.uk)
RISKS ARCHIVES: ftp://unix.sri.com/risks if your browser accepts URLs, or
ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP;
Issue J of volume 18 is in that directory: "get risks-18.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 17, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
FTP.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.
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 DIGESTS:
* The PRIVACY Forum is run by Lauren Weinstein, with some support from the
ACM Committee on Computers and Public Policy. He manages it as a rather
selectively moderated digest, somewhat akin to RISKS; it spans the full
range of both technological and non-technological privacy-related issues
(with an emphasis on the former). For information regarding the PRIVACY
Forum, please send the exact line:
information privacy
as the first text in the BODY of a message to:
privacy-request@vortex.com
You will receive a response from an automated listserv system. To submit
contributions, send to "privacy@vortex.com".
Information and materials relating to the PRIVACY Forum may also be
obtained from the PRIVACY Forum Archive via ftp to "ftp.vortex.com",
gopher at "gopher.vortex.com", and World Wide Web via:
"http://www.vortex.com". Full keyword searching of the PRIVACY
Forum Archive is available through the World Wide Web access address.
* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Leonard P. Levine. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
comp-privacy@uwm.edu and administrative requests to
comp-privacy-request@uwm.edu.
------------------------------
End of RISKS-FORUM Digest 18.37
************************
