The RISKS Digest
Volume 18 Issue 09

Wednesday, 1st May 1996

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

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
Info on RISKS (comp.risks)

Breaking Java security restrictions with Javascript

"Stephen.Anderson" <stephen@theplanet.net>
Wed, 1 May 1996 12:30:13 +0000 (GMT)
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


More on Java security

Peter Hughes <peter@livepicture.com>
Wed, 1 May 1996 12:43:29 -0700
    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)


Cambridge University systems hacked!

David Alexander <dave_ale@online.rednet.co.uk>
Mon, 29 Apr 1996 10:19:01 +0100
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


File permissions 705

"Mordechai T. Abzug" <mabzug1@gl.umbc.edu>
Tue, 30 Apr 1996 00:22:29 -0400 (EDT)
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


Libel writ served by e-mail

Andrew Martin <apm@cs.uq.oz.au>
Wed, 1 May 1996 15:19:41 +1000 (EST)
[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.


X-Image-URL e-mail header line

"Andrew Dalke" <dalke@ks.uiuc.edu>
Tue, 30 Apr 1996 00:47:41 -0500
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


Internal e-mail addresses don't work

John Gilliver <john.gilliver@gecm.com>
Tue, 30 Apr 1996 15:50:44 +0100
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]


File your tax return on the Web!

Jakob Schiotz <schiotz@nils.wustl.edu>
Fri, 26 Apr 1996 13:13:48 -0500
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


Australian court emulates Swedes (re: Gong, RISKS-18.06)

Ashley Robertson <ashley@cs.murdoch.edu.au>
Tue, 30 Apr 1996 11:07:43 -0800
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]


Re: Warning! My [...] let me [act] (Bailey, RISKS-18.03)

Geoffrey Cooper <geof@devices.com>
Thu, 18 Apr 1996 11:00:46 -0700
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.


Correction: The RISK of attributing error to malice (RISKS-18.08)

Paul R. Potts <potts@cancer.med.umich.edu>
Tue, 30 Apr 1996 12:40:30 -0400
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


Re: The RISK of attributing error to malice (Potts, RISKS-18.08)

"Randal L. Schwartz" <merlyn@teleport.com>
Tue, 30 Apr 1996 08:14:54 -0700 (PDT)
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)


Odds of an accident for the Challenger

Michael Perelman <michael@ecst.CSUChico.EDU>
26 Apr 1996 01:58:33 GMT
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


Children on the Internet: A Forum, Chicago, 18 May 1996

"David E. Sorkin" <7SORKIN@jmls.edu>
Tue, 30 Apr 1996 20:07:19 CST
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]


UNABRIDGED Info on RISKS (comp.risks), subscriptions, etc.

<RISKS-request@csl.sri.com>
1 April 1996 (no fooling!) (LAST-MODIFIED)
 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]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.

Please report problems with the web pages to the maintainer

x
Top