[1230] in RISKS Forum
RISKS DIGEST 18.09
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed May 1 17:22:43 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Wed, 1 May 96 14:21:03 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Weds 1 May 1996 Volume 18 : Issue 09
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. *****
****************** including periodic PRIVACY info update *******************
Contents:
Breaking Java security restrictions with Javascript (Stephen Anderson)
More on Java security (Peter Hughes)
Cambridge University systems hacked! (David Alexander)
File permissions 705 (Mordechai T. Abzug)
Libel writ served by e-mail (Andrew Martin)
X-Image-URL e-mail header line (Andrew Dalke)
Internal e-mail addresses don't work (John Gilliver)
File your tax return on the Web! (Jakob Schiotz)
Australian court emulates Swedes (Ashley Robertson)
Re: Warning! My [...] let me [act] (Geoffrey Cooper)
Correction: The RISK of attributing error to malice (Paul R. Potts)
Re: The RISK of attributing error to malice (Randal L. Schwartz)
Odds of an accident for the Challenger (Michael Perelman)
Children on the Internet: A Forum, Chicago, 18 May 1996 (David E. Sorkin)
UNABRIDGED Info on RISKS (comp.risks), subscriptions, etc.
----------------------------------------------------------------------
Date: Wed, 1 May 1996 12:30:13 +0000 (GMT)
From: "Stephen.Anderson" <stephen@theplanet.net>
Subject: Breaking Java security restrictions with Javascript
I'm unaware of whether this point has been raised: under Netscape 2.01 and
Atlas, there is a hole in Java vs. Javascript security that allows an Applet
to (amongst other things) contact a host other than that it was loaded from.
As Netscape allows use of "javascript:" URLs, it is possible to construct a
Javascript string in a Applet, then execute it by a call to showDocument().
This Javascript is *not* subject to the same security restrictions as the
Applet.
There are only three immediate risks I can think of:
1. People can end up reading pages they didn't expect or have any wish
to (though this is a risk with Javascript more than with Java, Java offers
an extra layer of concealment)
2. On a related note, people can end up running Applets they didn't
expect to, from different hosts, and these Applets may be able to
compromise security by communicating with each other.
3. Any Javascript security holes are also available to Java
Stephen Anderson, Planet Online : The White House, Melbourne Street, Leeds
LS2 7PS UK. +44 (0) 113 2345566 Stephen.Anderson@theplanet.net
------------------------------
Date: Wed, 1 May 1996 12:43:29 -0700
From: Peter Hughes <peter@livepicture.com>
Subject: More on Java security
It seems to me that no end is in sight to the security holes in
Java. In addition, I have been hearing that Java (and net access in
general) will soon become more deeply integrated into desktop OSs. Just
how bad could this get? Is there a way that uncontrolled or malicious Java
applets could propagate themselves about the net? Examples:
* A Java applet that runs server code, propagating itself from its own server?
* An applet that inserts copies of itself into a server on a machine that
is also used to run a browser?
* An applet that runs compiler code, creating an application of the
author's choosing on the target machine?
* An applet that attaches itself to Java-enabled applications or their
documents (a la Word macro virii), perhaps then using file sharing to
propagate itself?
I can think of other scenarios that are not specific to executable
applets, such as the exploitation of security holes on the net. (The Morris
worm is an example of such). Given how few users take security seriously
(or understand its implications), how likely is an event that causes massive
damage?
The folks that designed Java took all this and more into account,
but the continuing bugs show that the propagation of executables of this
type carries an inherent RISK. The community is to be commended for
scrutinizing Java.
Pete
(I turned off Java, and I don't run Word 6)
------------------------------
Date: Mon, 29 Apr 1996 10:19:01 +0100
From: David Alexander <dave_ale@online.rednet.co.uk>
Subject: Cambridge University systems hacked!
The following article was in Saturday 27th April (UK) Daily Mail newspaper:
Start>
Cambridge computer chaos as hacker hits secret files
A worldwide hunt has been launched for a computer hacker who accessed
sensitive research information at Cambridge University. Confidential files
were broken into using the Internet. Now up to 10,000 academics and students
are being forced to alter their passwords as the university's computer
experts try to plug the leak. Many of the files belong to top research
scientists and contain commercial, academic and medical information.
Richard Stibbs, Director of computer science studies at the university said:
"The hacker could come from anywhere in the world. The potential damage to
Cambridge University and beyond is enormous. Fortunately no files appeared
to have been tampered with, but we are asking everyone to check very
carefully."
The alarm was raised when a network security system which links universities
detected a rogue program in the Cambridge computer. The hacker is thought to
have gained access through the university's E-mail system, the Ethernet
[sic]. Experts are trying to trace when he broke into the system - which is
being replaced to prevent any similar lapses - and find out where the calls
came from. If caught, the culprit could face up to 5 years in jail.
<End
The usual RISKS apply, plus the risk of a panic replacement of the e-mail
system. How do you know that the replacement is more secure...at least you
know the strengths and weaknesses of the old one, and could probably patch
it.
The other significant RISK is that of determining the location and identity
of the hacker. Speaking as an 'ex Cambridge man' I know the physical layout
and and structure of some of their systems. Until about 4 years ago I could
have walked into one of several sites and access the system. In the early
80s (ah, lost youth), several of my friends would use the Engineering Dept
terminals for all-night MUD sessions over JANET. I only say 'until recently'
because I have moved 100 miles away. The same RISK must apply to almost any
academic site, but somewhere like Cambridge, where the 'Town and Gown' are
inextricably linked, with University and College buildings spread right
across the city, make security a nightmare to enforce.
David Alexander, Camberley, England Dave_Alexander@online.rednet.co.uk
------------------------------
Date: Tue, 30 Apr 1996 00:22:29 -0400 (EDT)
From: "Mordechai T. Abzug" <mabzug1@gl.umbc.edu>
Subject: File permissions 705
Under IRIX 5.3 (and perhaps other Unix variants), if someone 'chmod's a file
or directory to allow world access but to deny group access (i.e., 705),
then members of the user's group can't access the file. I don't know why
this should be, but assuming it makes sense, I've found a way around it,
even though I only belong to one group and can't 'newgrp': I made a symbolic
link to the file and put it in my web directory. Many 'httpd's (including
the one here) allow sym links to files/ directories outside the user's web
directory, and many httpd runs as user nobody or guest. Presto! Access to
the Mail directory of a friend who thought he was being quite clever. Of
course, I immediately showed him what I had done, and warned him to use 700,
but I didn't have to. . .
Mordechai T. Abzug
http://umbc.edu/~mabzug1 mabzug1@umbc.edu finger -l mabzug1@gl.umbc.edu
------------------------------
Date: Wed, 1 May 1996 15:19:41 +1000 (EST)
From: Andrew Martin <apm@cs.uq.oz.au>
Subject: Libel writ served by e-mail
[I suppose the only new risk here is that a court is seen to be believing
some rather flimsy evidence.]
`The Electronic Telegraph' [Web Edition of Major UK Newspaper],
by Robert Uhlig, 1 May 1996
In a ground-breaking case, lawyers have used the Net to enforce a British
court order overseas.
THE INTERNET has for the first time been used to serve a legal injunction
outside the UK, arguably establishing a precedent allowing the global
computer network to be used as a medium for distributing legal documents, in
the same manner as a fax machine. The development could also spell an end
to the freedom of speech enjoyed in hundreds of specialist news groups on
the Internet, where users discuss a wide spectrum of matters ranging from
the complexities of rival computer operating systems to libellous
speculation on celebrities' sexual practices.
The media and entertainment law firm Schilling and Lom in London received
threats, via e-mail, from an individual in Europe who claimed he was
planning to disseminate libellous material about one of its clients over the
Internet. "The e-mail contained the sender's two Internet addresses," said
Jonathan Coad, a libel partner at the firm. "When an injunction was
obtained against him, we persuaded Mr Justice Newman to grant us leave ex
parte to serve an order via these e-mail addresses. "We have to prove that
the defendant received the injunction, and used the 'return receipt'
capability of e-mail to prove that the defendant had seen the injunction on
his computer screen." Mr Coad added that the defendant also acknowledged
separately that he had received the injunction.
[...another lawyer] pointed out that there was still doubt over which
nation's laws applied if someone made a libellous statement on a global
medium such as the Internet. "Courts will have to move with the times and
there are a number of modern judges who are willing to make the move," he
said.
------------------------------
Date: Tue, 30 Apr 1996 00:47:41 -0500
From: "Andrew Dalke" <dalke@ks.uiuc.edu>
Subject: X-Image-URL e-mail header line
I just received e-mail with a header line I have never seen before,
> X-Image-Url: ftp://ftp.somewhere.else/pub/images/face.tiff
It appears to replace the 'X-Face' header as the URL was an image of the
sender's face.
The risks are similar to those of web browsers, but ones I hadn't
expected from an e-mail message. Two are:
1) If the URL is accessed when I read my mail, by looking at the server
logs the sender knows many things, including when I read my mail and the
machine I use to do so.
Imagine if mail handled by an anonymous remailer did not strip out this
header. The (supposedly) anonymous receiver checks e-mail, the mail reader
contacts the originator's site, and the sender knows at least the machine
the recipient uses, and probably has a good guess as to the identity.
2) Inappropriately designed mail readers might not offer a "Stop" button
to stop the transfer of large images. If the mail message proper is
displayed after the image is downloaded, it might take a long time to
transfer the image, while the mail itself is just a few lines longs.
Andrew Dalke dalke@ks.uiuc.edu
------------------------------
Date: Tue, 30 Apr 1996 15:50:44 +0100
From: John Gilliver <john.gilliver@gecm.com>
Subject: Internal e-mail addresses don't work
In RISKS 18.08 appeared:
: From: Andy Piper <andyp@wrath>
: The RISKS? Don't make assumptions about how your intended audience will view
I was going to discuss this privately with the poster (basically, although
it is to some extent a valid point, the practice of assuming fixed-spacing
fonts for news - so that, for example, ^s come out right - is quite
widespread); however, I noticed where I would be sending it. I suspect this
is an address which works well internally, but would fail if I tried to use
it.
I'm sure it is an old RISK, but obviously still needs mentioning! {The
software I use at home [Turnpike] won't allow me to send to an address
without an @ sign, and at least one dot after it, which must be both
preceded and followed by at least one character, which would have stopped me
sending the reply - but of course doesn't help anyone actually wanting to
contact Andy. [Perhaps that was the intention (-:!]}
J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW,
Essex, CM2 8HN, UK. +44 1245 242133 john.gilliver@gecm.com
[Yes, it is indeed an old risk, but still prevalent. I am always astounded
at how many e-mail messages I cannot answer for this reason! PGN]
[Plus, there are now more cases where there are large internal networks,
so people may be increasingly under the impression that it does work (as
they may spend some time e-mailing internally before venturing into the
big wide world outside, which maybe they didn't as much before). JPG]
------------------------------
Date: Fri, 26 Apr 1996 13:13:48 -0500
From: Jakob Schiotz <schiotz@nils.wustl.edu>
Subject: File your tax return on the Web!
Last year I moved from Denmark to the United States, so I have just had the
"pleasure" of filing my tax returns in two countries. This has made me
appreciate the efforts the Danish authorities have made in recent years to
make the process easier. Basically, almost everything they need to know has
already been reported to the authorities by the employer(s), the bank etc.
Then they send you a tax return form with the relevant numbers printed on
them, and you are then supposed to check them, correct any wrong numbers
(unlikely) and add any info they do not have (more likely).
This year they have gone a step further: you can call a specific number and
use you touch tone phone to file, or you can file on the Web at
http://www.tastselv.toldskat.dk/ (in Danish). To file you need your CPR
number (similar to the US social security number) and a 7-digit individual
security code printed on the form. You can then fill out the form and
submit it. If you make a mistake it can be corrected the same day, but if
you discover it later you have to contact the local tax authorities. This
means that a manual override system is in place, IMHO a good thing.
I am not a lawyer, but there must be some legal RISKS here. If I try to
cheat how are they going to prove that it was me? And even if they know, is
filling a form on the Web has any legal value? I don't sign anything, can
typing a code that presumably only I know be legally equivalent to signing a
document?
A more worrying RISK is that somebody actually do mess with other peoples
tax returns. They don't use encrypted transfers, so sniffing the security
code should at least in theory be trivial. It may be easier to get the code
by social engineering, especially if the victim has no experience with
computers and passwords ("Hello, it's the tax department. Due to a computer
error some of our records have been lost, would you please tell us the
numbers printed on the front page of the tax return form we sent you?").
An even more scary situation is that someone actually breaks into the
machine running the web server. The requirement that any corrections must
be made the same day may actually be an example of good risk management. If
the info is transferred from the web server to another computer, and if that
other computer only accepts to amend a filed return on the same day the
original was filed, then the damage from a hacker will be limited to the
returns filed that day (although if that day is April 30, the last day to
file, the damage may still be considerable).
Finally, we should also consider the risk of typos. Whom do you trust the
most to get the numbers right? Yourself, who will be directly affected by
an error? The OCR program "reading" your handwriting? Or maybe the (tired)
clerk that has to manually type in the numbers on the forms where the
handwriting is too illegible? This is (IMHO) a point in favor of the
type-it-yourself service.
Jakob Schiotz, Dept of Physics, Washington University, St. Louis, MO 63130
+1 (314) 935 4968 schiotz@howdy.wustl.edu Fax +1 (314) 935 6219
------------------------------
Date: Tue, 30 Apr 1996 11:07:43 -0800
From: Ashley Robertson <ashley@cs.murdoch.edu.au>
Subject: Australian court emulates Swedes (re: Gong, RISKS-18.06)
A similar situation has occurred here in Western Australia. New parents of
a baby boy were unable to give their child an ancestral name because of the
accents on some of the characters. The name was not offensive or difficult
to pronounce. The reason given was that the computer system of the Registry
of Births and Deaths could not accept the name because it was not a standard
ASCII character.
The solution was not as easy as removing the accents because that
substantially changes the pronunciation of the name. The child remains
unnamed!
Ashley Robertson, Murdoch University, WESTERN AUSTRALIA +(619) 360 2101
ashley@babbage.cs.murdoch.edu.au http://www.cs.murdoch.edu.au/~ashley
[I suppose you could try to name a child something like
Ju-umlaut-rgen or He-aigu-le-grave-ne? (with or without the
hyphens, according to your taste after rereading RISKS-17.95). PGN]
------------------------------
Date: Thu, 18 Apr 1996 11:00:46 -0700
From: Geoffrey Cooper <geof@devices.com>
Subject: Re: Warning! My [...] let me [act] (Bailey, RISKS-18.03)
In RISKS-18.03, Rob Bailey writes that a human operator is an intrinsic part
of a system in which he or she operates. Therefore, the human operator must
share the blame if the system fails.
This is true; Since the human is part of the system, the strengths and
weaknesses of the human must be taken into account in "good" system design,
just as must be done for any other system component.
In the original design of the manual typewriter, there was a problem with
the operator hitting the keys too fast; this caused mechanical jams. The
problem was solved by the addition of the QWERTY keyboard encoding, which
slowed down the typist by alternating the key locations between his two
hands. This is was an appropriate design for the human component, even if
it does not excuse us from still using QWERTY today.
We bristle when the media leaps to blame the operator; we must similarly
bristle if we leap to blame the machine. The RISKS we seek are in the
combination of the two, when the interface with the machine confuses or
confounds the operator and encourages mistakes.
For example, an airplane that is willing to touch down without the landing
gear deployed is not necessarily a bad system design, since:
- the pilot has procedures to prevent this from happening, including
licensing to ensure that the pilot understands these procedures.
- the pilot may need to land the plane in this way in an emergency.
Conversely, an autopilot that automatically limits the pilots steering
requests to avoid damage to the airplane might indeed be a bad system
design. The human component might correctly need to damage the airplane in
a sharp turn in order to save the lives of the passengers.
- Geof Cooper, Compact Devices, Inc.
------------------------------
Date: Tue, 30 Apr 1996 12:40:30 -0400
From: potts@cancer.med.umich.edu (Paul R. Potts)
Subject: Correction: The RISK of attributing error to malice (RISKS-18.08)
In the paragraph where I wrote:
>I haven't explained the duplicate copies on the remote machine or why the
>message was seen earlier, but this isn't necessary in order to convince me
>that this "forgery" was really an accident.
the text should have read "why the message wasn't seen earlier."
^^^^^^
Since the mail program automatically opens windows holding unsent outgoing
mail when it is launched, the question was why the staff member did not see
the message the morning after it was written, when she fired up her computer
and launched the mail program.
There are lots of possible reasons: maybe she hadn't really shut down her
computer and didn't re-launch the mail program the next morning, or maybe
she simply didn't notice the mail message, or maybe the mail program didn't
open the window for some reason.
I jumped to the conclusion that perhaps the file's creation date had been
faked by resetting the Macintosh system clock, obviously failing to apply
Occam's razor to the various hypotheses. I'm confident that our moderator
can come up with an appropriate pun here, perhaps something about shooting
the mail-message(r) or a close shave that cuts both ways : )
"Paul R. Potts" Technical Lead - Health Media Research Lab
University of Michigan Comprehensive Cancer Center potts@cancer.med.umich.edu
------------------------------
Date: Tue, 30 Apr 1996 08:14:54 -0700 (PDT)
From: "Randal L. Schwartz" <merlyn@teleport.com>
Subject: Re: The RISK of attributing error to malice (Potts, RISKS-18.08)
And such an unfounded witch-hunt can even further lead to criminal
convictions, as it did in my case. For details, see the website
http://www.lightlink.com/fors/. If you are web-challenged, you can
get the executive summary by writing to my reply-bot at
fund@stonehenge.com (the content will be mostly ignored).
I urge everyone with system administration responsibilities to be
aware of this case, and to share the information with others.
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
<merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
------------------------------
Date: 26 Apr 1996 01:58:33 GMT
From: michael@ecst.CSUChico.EDU (Michael Perelman)
Subject: Odds of an accident for the Challenger
I have heard that just before the Challenger flight, NASA issued a reports
of the odds of an accident. Does anybody know of a source? What were the
odds?
Michael Perelman, Economics Department, California State University
Chico, CA. 95929 michael@ecst.csuchico.edu
------------------------------
Date: Tue, 30 Apr 1996 20:07:19 CST
From: "David E. Sorkin" <7SORKIN@jmls.edu>
Subject: Children on the Internet: A Forum, Chicago, 18 May 1996
The John Marshall Law School Center for Informatics Law, in association with
the Illinois Privacy Council, announces the following conference:
CHILDREN ON THE INTERNET: A FORUM FOR PARENTS AND EDUCATORS.
Saturday, May 18, 1996, 8:30 am-5:30 pm, at The John Marshall
Law School, 315 South Plymouth Court, Chicago, Illinois.
The purpose of The Forum is to explore the benefits of the Internet and
online services and to learn about risks as well, so that informed parents
and educators can cooperate with service providers so as to enjoy the
advantages of the Internet while avoiding the negatives. Panelists will
demonstrate Internet resources available for children; will discuss the
potential for commercial manipulation of children, invasions of privacy,
access to objectionable materials, and other risks; and will suggest
appropriate roles and responsibilities of parents, educators, and
institutions in minimizing these risks.
The registration fee of $40 includes continental breakfast, lunch, and
conference materials. Registration deadline: May 13, 1996. Space is
limited.
For more information, call the Center for Informatics Law at (312) 987-1419,
or e-mail privacy@jmls.edu. Information about the Forum is also available
on the World Wide Web at http://www.jmls.edu/conf/ipcforum/.
-- David E. Sorkin (7sorkin@jmls.edu)
-- Associate Director, Center for Informatics Law, The John Marshall Law School
[I wonder if there are any three-generation families of RISKS
readers? I know there are a bunch of two-generation families. PGN]
------------------------------
Date: 1 April 1996 (no fooling!) (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: UNABRIDGED Info on RISKS (comp.risks), subscriptions, 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.09
************************
