Date: Wed, 24 Apr 96 21:45:42 EST
Errors-To: Comp-privacy Error Handler <owner-comp-privacy@uwm.edu>
From: Computer Privacy Digest Moderator <comp-privacy@uwm.edu>
To: Comp-privacy@uwm.edu
Subject: Computer Privacy Digest V8#034
Computer Privacy Digest Wed, 24 Apr 96 Volume 8 : Issue: 034
Today's Topics: Moderator: Leonard P. Levine
Re: JAVA
Re: JAVA
More about Middle C
More about Middle C
Re: Deja News
McDonald's/Disney Trivia Contest
From Risks: Email Aliases
Golden Key Crypto Campaign
From Edupage: Grateful Med On The Internet
Info on CPD [unchanged since 11/22/95]
----------------------------------------------------------------------
From: peter@baileynm.com (Peter da Silva)
Date: 20 Apr 1996 15:12:09 GMT
Subject: Re: JAVA
Organization: Network/development platform support, NMTI
References: <comp-privacy8.32.11@cs.uwm.edu> <comp-privacy8.33.9@cs.uwm.edu>
Shannon Wenzel <s_wenzel@ix.netcom.com> wrote: JAVA is a language
undergoing continuous evolution and development. Yes, you should
be concerned about current JAVA apps but no more concerned than
about other virus delivery methods.
Yes there is. It's a virus delivery method that can happen without the
user even knowing that there has been code downloaded to his computer.
There's a difference between downloading and unpacking a program and
just clicking on a web link. If you can deliver a virus without
requiring a positive action from the victim you have a significant
advantage. It's like the difference between droplet infections and
STDs.
--
Peter da Silva (NIC: PJD2) `-_-' 1601 Industrial Boulevard
Bailey Network Management 'U` Sugar Land, TX 77487-5013
+1 713 274 5180 "Har du kramat din varg idag?" USA
Bailey pays for my technical expertise. My opinions probably scare them
------------------------------
From: dp@world.std.com (Jeff DelPapa)
Date: 20 Apr 1996 04:06:27 GMT
Subject: Re: JAVA
Organization: Chaos and Confusion
References: <comp-privacy8.32.11@cs.uwm.edu> <comp-privacy8.33.10@cs.uwm.edu>
geosys@digital.net (George) writes: Does JAVA and similar
programming languages pose a security problem or a virus risk? As
I understand it, these languages are a modified "C" which are
downloaded with a web page and then execute on the local (terminal)
computer. What to stop this from implanting a virus? or from
sending information on the system to a remote site? Seems risky to
me.
Kurt J Lanza <klanza@world.std.com> wrote: Me too. The basic idea
seems to be that java code is compiled to a "byte-code" which is
downloaded and executed by a java interpreter on you system. The
interpreter is supposed to stop dangerous things from happening
(assuming all the preferences are set correctly). And if you think
this is safe for the average non-techie user, I have a bridge I
know you'll be interested in. Hope this helps.
The biggest problem with the Java design is that there will be any
number of byte code interpreters out there. (Sun only controls Java the
trademark, there have been announcements of independently developed
Java engines). While Suns may be tested with some rigor, the actions
of the browser writer incorporating it into their code may compromise
it. I am slightly more concerned about what happens when java is a
competitive marketplace, and the press starts benchmarking things.
"Expensive" checks, like array bounds on every reference may be "tuned"
to "get good numbers". Remember the windows video drivers that were
discovered to have special case code for the strings used in one of the
more influential benchmarks? No, such an engine wouldn't (one hopes)
get the Sun trademark of approval, but if such engines become
ubiquitous, the low end vendors will add an engine, but not "waste"
money on passing the trademark tests.
As originally intended (set top box), the design was a reasonable
compromise. There were to be zillions of them, so remote execution was
all but mandatory. The boxes, being hardware would have some barriers
to entry that a strictly software implementation wouldn't have: You
would have a fininte number of sources, rather than the current almost
everyone, and their second cousins. (remeber, the byte code engine
isn't that huge, the number I heard was 40Kb -- something within the
reach of an undergrad without a summer job)
The set top model was to be a broadcast one, with a fairly small,
possibly "trustable" set of sources (like getting a slot on national
TV). Compare that to the web, where any bozo that can afford $10/month
can put up a web page. You can't trust your sources, and there is a
community that takes some delight in defeating signing systems.
Last: the set top box was to be a ram only device. There wouldn't be
much information in the thing to compromise. Java (unless you employ a
"sacrifical" machine) runs on something that has a lot of state, and
while (in theory, but defeated in several of the recent releases, for
example the applet that could send mail with your name (and usual path
details) on it.) the network connectivity is limited, you are allowed
to connect back to the machine that provided the applet, so you do have
a communication path.
Unfortunately I think Sun has built itself a "Square Peg", by forcing a
solution for problem A, onto a problem, where the reality is almost
directly opposite to the original design assumptions. The design Sun
chose would require them to ship a system at the Orange book A2 level
of trust. Since they won't have control over the implementation, they
can't build such a thing. I think the only model that can be "safe" on
the web, is one where the browser is just a remote display, and any
computation must take place on the server. Yes I know, bandwith and
server horespower go thru the roof, but barring the continued
availability of "safe" browsers, the only way I could use the latest
generation is to dedicate a machine, outside the firewall, with only
the browser and the OS installed. (stuff that if trashed, could just
be reloaded from distribution media)
--
<dp>
------------------------------
From: branden@purdue.edu (Branden Robinson)
Date: 20 Apr 1996 04:35:36 GMT
Subject: More about Middle C
Organization: Purdue University
References: <comp-privacy8.33.3@cs.uwm.edu>
James Brady (jlbc@eci-esyst.com) wrote: Ownership of Radio
Frequencies _for_communications_ (the Middle C of FCC) is a
legitimate, method of managing a phenomenon that requires some
technological means to generate and/or receive it. Ownership of
"Middle C" in the audio spectrum is just plain silly since it is a
naturally occuring phenomenon in human speech and various sounds of
nature.
Whoops. I'm sure radio astronomers would be shocked to hear that the
phenomena they have spent their careers studying are not natural.
The technological means argument may hold, but that one doesn't.
Note followups.
--
"Whatever else it does, `SUMP PUMP BACKUP ALARM | G. Branden Robinson
SILENCER SWITCH' is a phrase that not only | Aerospace Engineering
sings, but packs its own rhythm section!" | Purdue University
-- Veronica Sullivan | branden@purdue.edu
------------------------------
From: scott_wyant@loop.com (Scott Wyant)
Date: 22 Apr 1996 13:52:29 -0700
Subject: More about Middle C
<<As for Mr. Sherman's copyright, I suppose if a particular song
had eight bars of nothing but "Middle C" in the melody, it would
pass the test and be subject to an infringement suit which would
probably not net anything of value since such a monotonous song
would not sell a whole lot of copies. I doubt if even Gregorian
chants change notes THAT slowly....>>
Am I the only one who still listens to Neil Young's "Cinnamon Girl?"
The one with the hilariously cool guitar break that consists of the
same note played about 40 times?
--
Scott Wyant
Spinoza Ltd.
------------------------------
From: Stephen Pastorkovich <stpastor@erols.com>
Date: 20 Apr 1996 17:09:41 -0400 (EDT)
Subject: Re: Deja News
melorama@pixi.com (Mel Matsuoka) writes: What I think is much more
of a privacy breach are are services such as MapQuest
(www.mapquest.com), which lets you graphically "zoom in" on the
location of someone by thier street address, and the wpy.net
service (http://wyp.net/info/search/NA.html) which lets you find
anyone by cross-referencing thier phone number, name, street
address, etc. When used in conjunction with each other, the
nefarious applications become apparant.
Nefarios? Or convenient? I'd say the latter, by far. When used in
conjunction with each other, the phone book and the guy at the gas
station who gives directions have nefarious applications, too.
Information can be abused no matter how it is collected.
Anyone using library phone books and gas station maps is just as likely
to get this information. Even using convenient tools such as MapQuest
and wpy.net, someone must know a little something about you (your name,
what state you're likely to reside in, etc) in order to narrow down the
search, regardless of their motives. It only becomes easier if one is
looking for a person with a distinctive or unusual name. That make the
search easier for anyone not using the internet, as well.
If I have a telephone and live on a road maintained at taxpayer expense
and have mail delivered by the US Postal Service, there are only so
many steps I can take from keeping people from tracking down my address
and phone number. Rather than implicating convenient services, let's
concentrate on promulgating those steps that we can take. Unless we're
willing to eschew the trappings of 20th century life, there's only so
far we can go to keep others from discovering where we live. I'd
rather concentrate on keeping private those things that aren't apparent
to casual observers, like financial matters et. al.
--
SP
------------------------------
From: Michael Passer <mpasser@cstp.umkc.edu>
Date: 23 Apr 1996 00:05:43 -0400
Subject: McDonald's/Disney Trivia Contest
Organization: University of Missouri-Kansas City
Being the lucky (?) winner of a US$12 retail value Disney merchandise
prize in the McDonald's Disney Trivia Challenge, I visited a store to
claim my prize.
The mailer I was given in which I was to send my winning game piece
asks for (and requires to receive the prize) the following
information:
PARTICIPANT'S NAME
ADDRESS
CITY
STATE
ZIP CODE
DATE OF BIRTH (Required to determine eligibility)
PARTICIPANT'S SOCIAL SECURITY # (Taxpayer Identification Number -
Required for prize awarding)
HOME PHONE
WORK PHONE
EMPLOYER
Needless to say, I won't be redeeming this prize!
The highest valued prize that could be redeemed using this mailer is
"Free Happy Meals For 1 Year." I believe McDonald's could have
preserved their interests without invading the privacy of their patrons
by requiring the participant to sign a statement stating that:
1. They are over the required age for participating.
2. They and their family do not work for McDonald's.
I cannot figure out their rationale for collecting the telephone
numbers, other than perhaps to sell them or use them for other
marketing.
--
Michael Passer
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 23 Apr 1996 11:52:19 -0500 (CDT)
Subject: From Risks: Email Aliases
Organization: University of Wisconsin-Milwaukee
Taken from RISKS-LIST: Risks-Forum Digest Friday 19 April 1996
Volume 18 : Issue 05 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND
RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public
Policy, Peter G. Neumann, moderator
Date: 16 Apr 1996 20:39:59 GMT
From: ckk@uchicago.edu (Chris Koenigsberg, ckk@pobox.com)
Subject: Re: Microsoft Exchange e-mail aliases etc. (RISKS-18.02)
Following up on the discussion begun in 18.02, here's another relevant
incident involving bad aliases (I think it was Microsoft Mail rather
than Exchange):
Just a few days ago, we suddenly started getting obviously internal,
confidential e-mail, from various members of some local law firm,
addressed to our Mailer-Daemon (which is forwarded to 3 responsible
sysadmins here).
Repeated replies from me to the senders, warning them to stop including
our Mailer-Daemon in their internal replies, were unheeded. Finally, a
day later, I got a frantic phone call from one of them, who was taking
on the added volunteer duty of administering the Microsoft Mail system
there. He said that his colleagues were all asking what the hell was
going on, why was I replying to their internal confidential mail
messages that they were simply addressing to "All-Staff"?
Somehow he had literally added our Mailer-Daemon to an internal
system-wide MS-Mail "All-Staff" alias there. I assume that he, or
someone else, had previously tried to e-mail someone here, perhaps in
our Law School, had made a typo in the address, gotten a reply back
from the infamous Mailer-Daemon, and mistakenly pasted the
Mailer-Daemon's address into their PERSONAL alias book, and
subsequently copied their PERSONAL aliases blindly into the SYSTEM
alias. (did I ever tell you about the fascinating love letters we get,
mistakenly addressed to the Mailer-Daemon? :-)
Their internal MS-Mail users would simply address their messages to
"All-Staff" and not even see the expansion of the alias, which is
reasonable (why should the users be bothered with the expansion for
every message to the whole staff?).
(in fact, the first of their puzzling messages leaked to us was from
this guy, saying "OK everyone, I've finally got the staff-wide alias
working! Fire away!" :-)
The problem is, no one was carefully auditing the results. Since no one
actually was paid to be a system administrator, no one bothered to
carefully examine the system-wide aliases. So their confidential mail,
about alternative possible strategies of argument before the judge in a
current pending case, were all forwarded to us!
Of course we offered to delete our copies for a very reasonable fee :-)
:-) (no, I'm kidding, we really did delete them, although perhaps they
made it onto a backup tape or two, maybe even a long-term archival
storage tape? hmm...)
Chris Koenigsberg ckk@uchicago.edu, ckk@pobox.com
http://www2.uchicago.edu/ns-acs/ckk/index.html (also
http://www.pobox.com/~ckk)
------------------------------
------------------------------
From: "John E. Mollwitz" <moll@mixcom.com>
Date: 24 Apr 1996 04:00:45 -0500
Subject: Golden Key Crypto Campaign
Date: 23 Apr 1996 17:27:22 -0500
From: "Marc Rotenberg" <rotenberg@epic.org>
Subject: Golden Key Crypto Campaign
To: "Press List" <PL@epic.org>
Apologies for the empty message. Attached is the press release for
the Golden Key campaign. The URL with a complete description of
the effort is at
http://www.privacy.org/ipc/
PRESS RELEASE
Wednesday, April 24, 1996
URL: http://www.privacy.org/ipc/
Contact: Marc Rotenberg, EPIC, 202/544-9240
Lori Fena, EFF, 415/436-9333
Barbara Simons, USACM 408/463-5661
RSA, 415/595-8782
------------------------------------------
INTERNET PRIVACY COALITION FORMED
Golden Key Campaign Launched
Groups Urge Good Technology for Privacy and Security
Senator Burns to Introduce Legislation
------------------------------------------
WASHINGTON, DC -- A new coalition today urged support for strong
technologies to protect privacy and security on the rapidly growing
Internet. The Internet Privacy Coalition said that new technologies
were critical to protect private communications and on-line commerce,
and recommended relaxation of export controls that limit the ability of
US firms to incorporate encryption in commercial products.
Phil Zimmermann, author of the popular encryption program Pretty Good
Privacy, expressed support for the effort of the new coalition. "It is
time to change crypto policy in the United States. I urge those who
favor good tools for privacy to back the efforts of the Internet
Privacy Coalition."
GOLDEN KEY CAMPAIGN LAUNCHED
The Coalition has asked companies and Internet users to display a
golden key and envelope to show support for strong encryption
technology. Copies of the logo are available at the group's web page
on the Internet.
According to Lori Fena, director of the Electronic Frontier Foundation,
the purpose of the campaign is to educate the public about new
techniques for privacy protection. "Society's feelings about privacy
have not changed, only the medium has," said Ms. Fena.
US industry has pressed the US government to relax export controls on
encryption as consumer demand for software products has increased. They
cite the fact that foreign companies have been able to sell strong
products in overseas markets that are now restricted for US firms.
Jim Bidzos, President and CEO of RSA Data Security, said that US firms
continue to face excessive burdens. "Encryption is the key to on-line
commerce. Government regulations are simply keeping US firms out of
important markets."
The Internet Privacy Coalition is the first net-based attempt to bring
together a broad base of companies, cryptographers and public interest
organizations around the central goal of promoting privacy and security
on the Internet and urging relaxation of export controls.
Dr. Barbara Simons, chair of the public policy committee of the
Association for Computing said, "The broad support for the Golden Key
campaign shows that the reform of encryption policy is a shared goal
for companies, users, and professional associations."
SENATOR BURNS TO INTRODUCE LEGISLATION
The Internet Privacy Coalition is being established as Congress
considers new legislation to relax export controls on encryption.
Senator Conrad Burns (R-MT) this week introduced legislation that would
relax export controls on commercial products containing technologies
for privacy such as encryption.
Marc Rotenberg, director of the Electronic Privacy Information Center,
said "We believe that Senator Burns has put forward a constructive
proposal. We look forward to working with him to ensure that good tools
for privacy and security are widely available to Internet users."
Hearings on Senator Burns bill are expected to take place in early
June. The proposal has already gathered support from a bipartisan
coalition in Congress.
For Internet users who are interested in following the debate about
encryption policy, the IPC has set up a Web page with information about
encryption regulations, court challenges, legislative developments, and
organizations and companies involved in the campaign.
The Internet Privacy Coalition was established by more than a dozen of
the nation's leading cryptographers, and thirty associations,
companies, and civil liberties organizations committed to strong
privacy and security technology for all users of the Internet.
URL: http://www.privacy.org/ipc/
----------------------------------------------
A KEY, AN ENVELOPE -- Both are historic means for communicating
privately and protecting personal information. Today, encryption tools
provide this privacy in the electronic world.
The Golden Key Campaign is being launched to raise awareness and
support for the preservation of the right to communicate privately and
the availability of new techniques which make it possible.
Privacy, a fundamental human right, has been affirmed by the US Supreme
Court, the constitutions and laws of many countries, and the United
Nations Universal Declaration of Human Rights. Privacy must be
preserved as we move from paper to electronic communications.
The Internet Privacy Coalition is urging members of the net community
to display a Golden Key & Envelope symbol on their Web pages to show
support for the right of privacy and the freedom to use good tools of
privacy without government restraints.
----------------------------------------------
--
John E. Mollwitz / Journal Sentinel Inc.
moll@mixcom.com / 72240.131@compuserve.com
------------------------------
From: Edupage Editors <educom@elanor.oit.unc.edu>
Date: 23 Apr 1996 17:34:05 -0400 (EDT)
Subject: From Edupage: Grateful Med On The Internet
GRATEFUL MED ON THE INTERNET The National Library of Medicine's
Grateful Med electronic retrieval service is moving to the Internet,
making the vast storehouse of electronic databases available via the
Web. The service, dubbed Internet Grateful Med, does not require users
to have any special software, and will be priced per character shipped,
with a typical physician's search costing about $1.25. Would-be users
need to sign up for the service and receive a user-ID code and a
password. < http://igm.nlm.nih.gov/ > or 800-638-8480. (Chronicle of
Higher Education 26 Apr 96 A25)
Edupage is written by John Gehl (gehl@educom.edu) & Suzanne Douglas
(douglas@educom.edu). Voice: 404-371-1853, Fax: 404-371-8057.
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 17 Mar 1996 09:14:50 -0600 (CST)
Subject: Info on CPD [unchanged since 11/22/95]
Organization: University of Wisconsin-Milwaukee
The Computer Privacy Digest is a forum for discussion on the effect of
technology on privacy or vice versa. The digest is moderated and
gatewayed into the USENET newsgroup comp.society.privacy (Moderated).
Submissions should be sent to comp-privacy@uwm.edu and administrative
requests to comp-privacy-request@uwm.edu.
This digest is a forum with information contributed via Internet
eMail. Those who understand the technology also understand the ease of
forgery in this very free medium. Statements, therefore, should be
taken with a grain of salt and it should be clear that the actual
contributor might not be the person whose email address is posted at
the top. Any user who openly wishes to post anonymously should inform
the moderator at the beginning of the posting. He will comply.
If you read this from the comp.society.privacy newsgroup and wish to
contribute a message, you should simply post your contribution. As a
moderated newsgroup, attempts to post to the group are normally turned
into eMail to the submission address below.
On the other hand, if you read the digest eMailed to you, you generally
need only use the Reply feature of your mailer to contribute. If you
do so, it is best to modify the "Subject:" line of your mailing.
Contributions to CPD should be submitted, with appropriate, substantive
SUBJECT: line, otherwise they may be ignored. They must be relevant,
sound, in good taste, objective, cogent, coherent, concise, and
nonrepetitious. Diversity is welcome, but not personal attacks. Do
not include entire previous messages in responses to them. 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. All reuses of CPD material should respect stated copyright
notices, and should cite the sources explicitly; as a courtesy;
publications using CPD material should obtain permission from the
contributors.
Contributions generally are acknowledged within 24 hours of
submission. If selected, they are printed within two or three days.
The moderator reserves the right to delete extraneous quoted material.
He may change the Subject: line of an article in order to make it
easier for the reader to follow a discussion. He will not, however,
alter or edit the text except for purely technical reasons.
A library of back issues is available on ftp.cs.uwm.edu [129.89.9.18].
Login as "ftp" with password identifying yourid@yoursite. The archives
are in the directory "pub/comp-privacy".
People with gopher capability can most easily access the library at
gopher.cs.uwm.edu.
Web browsers will find it at gopher://gopher.cs.uwm.edu.
---------------------------------+-----------------------------------------
Leonard P. Levine | Moderator of: Computer Privacy Digest
Professor of Computer Science | and comp.society.privacy
University of Wisconsin-Milwaukee | Post: comp-privacy@uwm.edu
Box 784, Milwaukee WI 53201 | Information: comp-privacy-request@uwm.edu
| Gopher: gopher.cs.uwm.edu
levine@cs.uwm.edu | Web: gopher://gopher.cs.uwm.edu
---------------------------------+-----------------------------------------
------------------------------
End of Computer Privacy Digest V8 #034
******************************
.