Date: Tue, 05 Mar 96 14:01:20 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#021
Computer Privacy Digest Tue, 05 Mar 96 Volume 8 : Issue: 021
Today's Topics: Moderator: Leonard P. Levine
Social Security Numbers 101
Re: AOL Mail Retention
A Far-Reaching Privacy Bill
A Far-Reaching Privacy Bill
Powerful Engines that Search Usenet
Two Telephone Services Recognising Tone Dialing
Re: International Billing for 800's
Re: Caller ID is not 800# ANI
Re: Caller ID: Ameritech -> MCI
Re: Caller ID: Ameritech -> MCI
Re: ANI Information Cannot Be Used for Marketing Purposes
Re: Your Computer Is Watching You
Java/JavaScript security breaches
Info on CPD [unchanged since 11/22/95]
----------------------------------------------------------------------
From: Robert Ellis Smith <0005101719@mcimail.com>
Date: 01 Mar 96 16:47 EST
Subject: Social Security Numbers 101
The U.S. Department of Transportation requires states to get Social
Security numbers on commercial drivers' licenses. For non-commercial
licenses, states MAY collect SSNs (and display them on the license
itself). Even though the federal Privacy Act limi ts states from
collecting SSNs, it was amended in the 1970s to exempt state
departments of motor vehicles from that limitation. (Laws in five
states expressly say that a person may decline to provide an SSN for a
driver's license.)
The current welfare reform bill before Congress (HR 4) would REQUIRE
all (non-commercial) licensed drivers to provide SSNs to the states.
This proposal is a regression to the 1960s when the federal government
first encouraged states to collect SSNs for m otor vehicle licensing.
Why is this important? With a national epidemic of "theft-of-identity"
and credit-card fraud, you want to minimize the places where your
Social Security number can be accessed. As a citizen, you may also
want to be known by a name, not a number. Lastly , you may want to
remind the information collectors that many people care enough to
minimize the amount of unnecessary personal information that is
collected.
--
Robert Ellis Smith/ Privacy
Journal/ 401/274-7861/ 0005101719@mcimail.
If you subscribed, you'd know all this already.
------------------------------
From: rescue@snowcrest.net (M. Steven McClanahan)
Date: 03 Mar 1996 16:58:49 -0800
Subject: Re: AOL Mail Retention
Organization: Silicon Alchemy
References: <199602071932.NAA10030@blatz.cs.uwm.edu> <comp-privacy8.14.4@cs.uwm.edu>
Aaron Zaugg <relief@indirect.com> said: While this may be skirting
the true issue with AOL's mail retention without user's consent, I
wonder if there isn't an easy way around this. I do not use AOL,
but more than likely a user should be able to edit their e-mail
[...]
PHILS@RELAY.RELAY.COM (Philip H. Smith III, (703) 506-0500) wrote:
Despite being aimed at the home market, presumably AOL has figured
out how to run a real data center by now (if not, I know several
people who will happily educate them at several hundred $$$/hour),
so I kind of doubt that what is being proposed here will achieve
anything other than to waste an AOLer's time.
Yes, AOL has figured this out. In the recent case where AOL rolled over
without a fight and gave law enforcement access to their email files,
the cops looked at five sets of tapes.
Even if there are no additional sets of tapes, I tell my users it is
virtually impossible to stop a sophisticated enough person from
recovering data that has been "erased" from any magnetic media. I've
done it for a federal agency that shall remain nameless.
--
M. Steven McClanahan, MICP
(Doc_Holiday@awwwsome.com)
aWWWsome Net Services
THE CONNECTION YOU WANT, FOR THE CONNECTIONS YOU NEED
------------------------------
From: Glenn Foote <glnfoote@freenet.columbus.oh.us>
Date: 03 Mar 1996 21:51:33 -0500 (EST)
Subject: A Far-Reaching Privacy Bill
Beth Givens <bgivens@pwa.acusd.edu> Writes, "No person or
corporation may use or distribute for profit any personal
information concerning a person without that person's written
consent. Such information includes, but is not limited to, an
individual's credit history, finances, medical history, purchases,
and travel patterns."
With all due respect, I fail to see how this bill will do very much to
protect privacy. In fact, it may do the opposite.
Consider; any business has only to place a few sentences in _every_
contract, charge card slip, bank notice, loan or insurance application,
etal ... which might read something like:
(you) agrees that all information contained herein and/or resulting
from any process and procedure hereto, shall become the exclusive
property of the provider(me) and hereby provides consent for the
use of that information by the provider(me) as they see fit. (you)
further hereby provide consent for (me) to access all available
commercial information and investigate as may deemed necessary."
With that one small change to any document (and you _MUST_ sign, or go
elsewhere, and there is _unlikely_ to be an "elsewhere"), they would
now have full authority to gather, compile, use, share, AND sell every
piece of data about you they could get their hands on.
I really hope that someone can tell me that I am wrong. I'm NOT a
lawyer, and it only took 60 seconds to come up with the above. I
suspect someone who was really devious could much more damage to
privacy rights.
--- ** Glenn "Elephant" Foote ...... glnfoote@freenet.columbus.oh.us
------------------------------
From: johnl@iecc.com (John R Levine)
Date: 03 Mar 96 23:45 EST
Subject: A Far-Reaching Privacy Bill
Organization: I.E.C.C., Trumansburg, N.Y.
[ proposed California law says] "No person or corporation may use
or distribute for profit any personal information concerning a
person without that person's written consent. Such information
includes, but is not limited to, an individual's credit history,
finances, medical history, purchases, and travel patterns."
Sadly, I doubt that such a bill would have any practical effect
whatsoever. All it means that banks, doctors, credit card companies,
etc. will add another sentence to their existing application
boilerplate that says "and we can use data collected about you for any
purpose we want."
A lot of them already say that.
It seems to me that a somewhat more effective approach would be to
require that requests for data be accompanied by the specific purpose
for which it is to be used, and that other uses require prior written
permission. The trick is to make "specific" work, so they can't just
use value blanket descriptions again.
--
John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869
johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof
------------------------------
From: magary@news-e2c.gnn.com (Al Magary)
Date: 04 Mar 1996 21:48:22
Subject: Powerful Engines that Search Usenet
Organization: GNN
The Wall St. Journal today (3/4/96, p.B1) has an article, "World-Wide
Fame Is at Your Fingertips," about the adventure of powerful search
engines that search both the Web and Usenet, principally Alta Vista
(owned by Digitil):
http://www.altavista.digital.com/
and Open Text:
http://www.opentext.com/omw/f-omw.html
These services have spiders constantly collecting every bit of new text
on the Web and Usenet. To see how effective they are, input your own
name in the search-for slot.
It may be quite a party stunt in Silicon Valley to rate people's social
status by how many hits they get in an Alta Vista search (Bill Gates,
60,000; you, zero?), but for those, like myself, who conduct all
Internet business under their own name, Alta Vista's archiving of old
correspondence is chilling.
--
Al Magary
magary@gnn.com
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 05 Mar 1996 09:06:24 -0600 (CST)
Subject: Two Telephone Services Recognising Tone Dialing
Organization: University of Wisconsin-Milwaukee
Taken from RISKS-LIST: Risks-Forum Digest Monday 4 March 1996 Volume
17 : Issue 83 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED
SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy,
Peter G. Neumann, moderator
From: ian@tanagra.demon.co.uk (Ian Chard)
Date: 02 Mar 1996 00:33:30 GMT
Subject: Two telephone services recognising tone dialing
I just decided to check the balance on my current account using my
bank's automated telephone banking service. I share a phone with
several others, so to avoid arguments over the bill I decided to put
the call on my British Telecom chargecard.
Both the chargecard service and the phone banking service are operated
by DTMF (tone dialing), however when I was connected to the bank and
dialed ## code for "cancel operation", British Telecom disconnected the
call and asked me if I would like to make another one.
The risks here are:
(a) To have seen me dial the ##, BT must have been monitoring the
line for DTMF throughout the call. This means that they monitored
my account number and PIN as I entered them into the banking
system.
(b) Anything I dial is ambiguous in this situation, unless I know
*every* code BT understands during a call, and which ones it will
act upon instead of passing them through to the called party.
Ian Chard, back in Manchester ian@tanagra.demon.co.uk
NTS: G7OMZ @ GB7VRB.#38.GBR.EU Phone: +44 161 434 6492
------------------------------
From: Bruce.Taylor@hedb.uib.no (Bruce Taylor)
Date: 02 Mar 1996 18:50:15 GMT
Subject: Re: International Billing for 800's
Organization: Computing Section, Faculty of Arts, University of Bergen, Norway
References: <comp-privacy8.20.3@cs.uwm.edu>
"Peter M. Weiss +1 814 863 1843" <PMW1@PSUVM.PSU.EDU> writes: What
happens if the 800/880 # is terminated in Canada but initiated in
the USA? Who calls the shots then?
Whenever I call an 800 number in the US (I'm in Norway), a recorded
message informs me that I will pay international rates for the call,
and the I should hang up if I don't want to continue.
--
Bruce Taylor Bruce.Taylor@hedb.uib.no
Det historisk-filosofiske fakultets edb-seksjon voice: +47.55.212348
Universitetet i Bergen, Norway fax: +47.55.231897
------------------------------
From: bo774@freenet.carleton.ca (Kelly Bert Manning)
Date: 02 Mar 1996 19:15:41 GMT
Subject: Re: Caller ID is not 800# ANI
Organization: The National Capital FreeNet
References: <comp-privacy8.17.11@cs.uwm.edu> <comp-privacy8.20.6@cs.uwm.edu>
Richard A Lee (Richard_Lee@ssw.mclean.sterling.com) writes: 800
numbers use ANI (Automatic Number Identification, I think), which
existed well before Caller ID and is quite unrelated to it. Using
Caller ID blocking will not -- repeat, _not_ -- prevent ANI from
working. The fact that the 800 number belonged to a different
provider in your case is _completely_ irrelevant.
But are blocked caller ID signals being recreated from ANI data?
In 1993 I called a "Joker" 1-800 number from a pay phone and heard it
read back the number, even though the local telco says that it blocks
Caller ID for all lines on the exchange in all cases.
The telco looked into in and said that while the Canadian stentor group
companies honoured caller ID blocking flags other companies were free
to recreate them from ANI data. Is this still going on?
ANI was sort of a mainframe or at least minicomputer type of thing.
Ie. you needed to pay for more than a basic ISDN line, over a dozen.
Caller ID provides lowers the entry point quite a bit.
--
notice: by sending advertising/solicitations to this account you will be
indicating your consent to paying me $70/hour for a minimum of 2 hours for
my time spent dealing with it
------------------------------
From: sean@sdg.dra.com (Sean Donelan)
Date: 02 Mar 96 14:33:41 CST
Subject: Re: Caller ID: Ameritech -> MCI
Organization: Data Research Associates, St. Louis MO
References: <comp-privacy8.19.5@cs.uwm.edu>
Glenn Foote <glnfoote@freenet.columbus.oh.us> writes: All can be
either immediately dumped to the party you called as their phone is
ringing, or retrieved while you are on line. All through the use
of commercial services SOLD WITH 800 number services as part of
this "right" to _audit_ their bill. I suspect that the risks of
calling _any_ 800 number are a little more that most people
realize.
The same risks exist when you call anyone collect. "Toll-free" 1-800
numbers and collect calls both result in the callers telephone number
appearing on the billing statement.
I suspect Enterprise, Zenith, and the various other incarnations of
reverse-charging have the same results. I'm never surprised that the
risks of anything are a little more than most people realize.
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Affiliation given for identification not representation
------------------------------
From: lachman@netcom.com (Hans Lachman)
Date: 04 Mar 1996 12:06:54 GMT
Subject: Re: Caller ID: Ameritech -> MCI
Organization: Agency for the Prevention of Evil
References: <comp-privacy8.17.11@cs.uwm.edu> <comp-privacy8.18.10@cs.uwm.edu>
dan@fch.wimsey.bc.ca (Dan Fandrich) writes: When an 800/888/900
number owner receives the number of the person calling, he receives
the caller's ANI (Automatic Number Identification), NOT his
directory number sent by Caller*ID. In most cases, the ANI and
Caller*ID are the same but since ANI is designed for billing
purposes, they can be different. ANI uses a completely different
mechanism from Caller*ID and *can not* be blocked by the caller,
period. The reasoning is that the 800 number owner is paying for
the call so is entitled to know who is racking up his bill.
A point of logic, if I may:
This reasoning would also imply that for all calls I receive, on an
ordinary line, I should be given the identity of the caller because I'm
"entitled" to know who is wasting my time. Time is money, after all.
(Logic mode off, opinion mode on.)
I'd say nobody is really "entitled" to anything in these situations,
other than to choose whether or not engage the other party.
After having read many responses on this topic saying "ANI is not
Caller ID", I think the point of the original post got lost. Sure, you
all did provide an accurate technical response, but I believe the more
important implication of the original post was that (1) if identity
information can be passed to the callee, then the caller has a
reasonable expectation to have a way to block it, and (2) the caller
has a reasonable expectation that the blocking method is simple and
consistently effective.
The reason for (2) is that Joe User shouldn't need to know all kinds of
technical details about the inner workings of the telephone network,
such as why ANI is different from Caller ID. Those of you who do
understand the details might not understand why, but just please
believe me, Joe User would rather think in terms of the abstraction "I
push dese buttons, da phone number not given out." The original post is
a case in point, supporting this position.
Also, make no mistake about this, by (1) I do not imply that 800 number
owners should be forced to accept (and pay for) calls from people who
choose to withhold their identity. They should simply be able to have
these calls automatically rejected. On the other hand, some 800 number
owners might like to accept calls regardless of whether the caller
withheld their identity, so this automatic rejection feature should be
optional for the 800 number owner.
I had a debate about all this with someone on comp.dcom.telecom a
couple years ago, and the debate ended with him saying that he knows
more about telecom than I do, and it's just not technically feasible to
implement these features in the telephone network (i.e., ANI blocking
option for the caller, and call rejection option for the 800 number
owner). All I can say is that, if that's the case, then the telecom
industry ought to hire better design engineers.
And that's all I have to say about that.
------------------------------
From: privacy@interramp.com (Privacy Newsletter)
Date: 03 Mar 1996 23:43:58 GMT
Subject: Re: ANI Information Cannot Be Used for Marketing Purposes
Organization: Privacy Newsletter
References: <comp-privacy8.19.7@cs.uwm.edu> <comp-privacy8.20.4@cs.uwm.edu>
privacy@interramp.com (Privacy Newsletter) wrote: Ironically, such
a provision does not apply to numbers captured under Caller ID --
only under ANI. For more information, you can check the complete
rule under the FCC's homepage or contact Privacy Newsletter.
glr@ripco.com says... Where is the oversight / enforcement? How do
you prove they used your number from ANI?
Excellent points, Glen. Especially, "where is the enforcement." Don't
expect the FCC to do a good enforcement job; it's just unrealistic,
unless the violator in question has demonstrated an extremely abundant
and systematic pattern of such behavior across a wide cross-section of
individuals.
How do you prove ANI usage, Well, if you've never contacted the firm
before and you didn't provide your name when you called, then if the
call you back -- especially soon after your initial call -- then it's a
pretty reasonable assumption that they used ANI for marketing
purposes.
--
John Featherman
Privacy Newsletter
PO Box 8206
Philadelphia PA 19101-8206
E-mail: privacy@interramp.com
Phone: 215-533-7373
------------------------------
From: gordon@sneaky.lerctr.org (Gordon Burditt)
Date: 03 Mar 1996 17:22:21 -0600 (CST)
Subject: Re: Your Computer Is Watching You
Why not update, alter, or amended the cookies file to provide bogus
information to whoever snoops...
Cookies can be active in your browser that you pick up during a
session, and they won't be present in the cookies file until you quit
your session, so you can't alter or delete them until the end of the
session. However, it will give out cookies during the session. (I
tested this. It's easy with a CGI program that just formats all its
environment variables for presentation to the user, and sets a cookie
to see if it later shows up in the environment.)
Further, the default duration (unless an expire time is specified) is
for the session (Netscape does have a spec for the cookies feature
online), and these cookies will never show up in the cookie file.
MCOM-HTTP-Cookie-file-1
.infoseek.com TRUE / FALSE 826157028
InfoseekUserId 3393C369AEB848A45615C6081EAE685E
.infoseek.com TRUE / FALSE 826157028
InfoseekCookieVersion 1
What secrets have I told the world by incluing my cookie file
here?
The expire time on these cookies is about 6PM March 6, Central Standard
Time. I suppose I could find out the usual expiration time for these
and figure out when you accessed Infoseek.
You gave Infoseek an email address to go with your cookie by posting
it. They can associate that with all the searches you did and all
their pages you visited. If you used Infoseek to search for sexually
explicit material, you just might be confronted by it during divorce
proceedings.
Even if you give a FAKE cookie, they can still track you with it, just
like consistently using the same fake SSN. Unlike the fake SSN, it is
unlikely anyone but Infoseek and anyone they sold data to can get any
useful information to associate with it.
--
Gordon L. Burditt
sneaky.lerctr.org!gordon
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 05 Mar 1996 09:08:21 -0600 (CST)
Subject: Java/JavaScript security breaches
Organization: University of Wisconsin-Milwaukee
Taken from RISKS-LIST: Risks-Forum Digest Monday 4 March 1996 Volume
17 : Issue 83 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED
SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy,
Peter G. Neumann, moderator
From: Jack Decker <jack@novagate.com>
Date: 01 Mar 1996 20:25:14 -0500
Subject: Java/JavaScript security breaches
If you are running Netscape 2.0 on your system, and are at all
concerned about security or privacy, you should run, not walk to this
URL:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The World
Wide Web Security FAQ
Pay special attention to questions 69 through 71. Number 71 in
particular discusses:
* How a JavaScript page could grab a user's e-mail address from
Netscape's preferences dialog and send it across the Internet.
* A script that can open up a small window that continuously monitors
the user's browsing activity, capture the URLs of open documents, and
transmit them to a remote server.
* A script that can obtain recursive directory listings of the user's
local disk and any network disks that happen to be mounted. This
information can be transmitted anywhere in the Internet.
* How the version of JavaScript that was included with beta versions of
Netscape 2.0 contained holes that allow the user's history and cache
files (both of which contain lists of recently-visited URLs) to be
captured.
I have not seen any information on this before today, so I suspect that
other Netscape users might want to know about these risks!
------------------------------
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Date: 02 Mar 1996 23:51:49 +0000 (GMT)
Subject: Java security bug (applets can load native methods)
There is a serious security bug in the class loading code for the Java
development kit and Netscape (all Java-enabled versions). If an
attacker can arrange for two files (a "Loader" class, and a dynamic
library) to be installed in any readable directory on the client
machine, he/she can bypass all of Java's security restrictions. For
example, the applet can read, write and execute files on the client,
with the same permissions as the user of the browser.
The only way to avoid this bug at the moment is to disable Java. In
Netscape this can be done by selecting 'Disable Java' in the 'Security
preferences...' section of the 'Options' menu.
This bug affects all Java implementations based on Sun's source code.
It is not related to JavaScript.
Further details will be posted when Sun and Netscape have released
patches.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Date: 04 Mar 1996 18:08:58 +0000 (GMT)
Subject: Java security bug (applets can load native methods)
Unfortunately my news server has been off-line for the past few days.
However, I'll try to address some of the questions that were raised on
strong-java@entmp.org and in private mail about the recently-discovered
bug in Java's class loading code. The same questions have probably been
asked on RISKS and/or comp.lang.java as well.
Apparently I wasn't clear enough in stating that this bug allows
classfiles to be loaded from _any_ directory on the client machine, not
simply those on the CLASSPATH or LD_LIBRARY_PATH. This includes, for
example, /tmp, ~ftp/incoming, or an attacker's home directory if he/she
has an account on the same system.
The attack requires two support files on the client's system: a
classfile and a dynamic library. Both files must be readable by the
browser, and the dynamic library must be executable (this is always
true for systems that have no file permissions). The path to the
classfile from the client's root directory must be known by the
attacker in advance.
Code demonstrating the bug has been written and tested on Linux and
Digital Unix (OSF/1). It should be portable to all POSIX systems, and
with a little work, to any system that supports Java. The demonstration
is very easy to extend - hiding it within any applet would require
adding only two extra lines of code. Changing the C code to execute any
command would be a single-line change. For that reason, the code will
not be described in detail or released publically until patches are
available for both Netscape 2.0 and the Java Development Kit.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 02 Mar 1996 10:34:30 -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 #021
******************************
.