Date: Tue, 05 Mar 96 14:01:20 EST Errors-To: Comp-privacy Error Handler From: Computer Privacy Digest Moderator 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> Aaron Zaugg 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 Date: 03 Mar 1996 21:51:33 -0500 (EST) Subject: A Far-Reaching Privacy Bill Beth Givens 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" 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: "Peter M. Weiss +1 814 863 1843" 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: 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: Glenn Foote 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: 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: 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" 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 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 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 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" 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 ****************************** .