Date: Mon, 27 Mar 95 15:19:30 EST Errors-To: Comp-privacy Error Handler From: Computer Privacy Digest Moderator To: Comp-privacy@uwm.edu Subject: Computer Privacy Digest V6#030 Computer Privacy Digest Mon, 27 Mar 95 Volume 6 : Issue: 030 Today's Topics: Moderator: Leonard P. Levine Cameras in the Federal Courts Re: Big Modem is Watching Re: Big Modem is Watching Re: Big Modem is Watching Re: Can a LAN supervisor watch me? Re: Can a LAN supervisor watch me? Re: Is Reading E-Mail Legal? Fair Information Practices Senate Committee Approves "Decency" Bill [EPIC 2.05] Caller ID Snafus: FCC Delays [EPIC 2.05] Commerce Dept. to Recommend Relaxing Crypto Control [EPIC 2.05] Maryland Debates Online Privacy [EPIC 2.05] Info on CPD [unchanged since 12/29/94] ---------------------------------------------------------------------- From: jwarren@well.sf.ca.us (Jim Warren) Date: 26 Mar 1995 15:01:25 +0800 Subject: Cameras in the Federal Courts From: "Mark P. Eissman" <75567.2545@compuserve.com> Subject: cameras in fed cts vote Exciting news on cameras in the federal courts! The U.S. Judicial Conference voted 17 to 9 to do just what we asked, to allow its Court Administration and Case Management Committee to consider new proposals for television coverage. The vote, as I understand it (the vote took place in closed session as do all of the full Conference's proceedings) pertains only to civil and non-criminal cases, at least with regard to the trial level. The appellate level appears not to have that restriction. The vote cleared up the apparent misunderstanding that we brought forth. The case adminstration committee, is free to consider "pilot programs or conduct{ing} studies necessary to the making of further recommendations on cameras in civil cases," the full Conference voted. I am told that some of the other proposals we raised with the Conference, such as allowing cameras at the appellate level or letting each court of appeals decide for itself, were discussed and can now be considered. Not bad for an issue thought to have been dead just a few months ago. After I obtain more information, we can discuss how to best be heard by the court administration committee. Take Care -- Mark ------------------------------ From: George Mullins Date: 26 Mar 1995 21:00:14 -0800 Subject: Re: Big Modem is Watching Dan Sticka wrote: I caught an article in Forbes (Feb13,1995;pg:186) titled "Big Modem is Watching". The jisk of the article describes the practice of online services doing a check of your system and writing some files on your hard drive to give quicker and flashier access. [stuff deleted] The logical conclusion of this is while you may trust your friendly online service provider, who knows what lurks out in the big bad Internet. "While you are scanning one (WWW page), the operator could be scanning you." I think it may have been pointed out before, but some of the current web browsers will send your username (uid) to the server you are currently connected to, upon request with your knowledge or control. It could just as well and may send other information, such as system type, programs loaded on your machine, ... And now folks like NETSCAPE want to encrypt the bytes that are sent with keys they generate on the fly and you can no longer see what is being said/sent about you and your configuration. This is the future, this is SSL coming to a browser near you. WATCH OUT. -- george ------------------------------ From: zimmermn@summa4.MV.COM (Uwe Zimmermann) Date: 27 Mar 95 17:41:45 GMT Subject: Re: Big Modem is Watching Organization: Summa Four Inc. wrote: I caught an article in Forbes (Feb13,1995;pg:186) titled "Big Modem is Watching". The jisk of the article describes the practice of online services doing a check of your system and writing some files on your hard drive to give quicker and flashier access. ... The logical conclusion of this is while you may trust your friendly online service provider, who knows what lurks out in the big bad Internet. "While you are scanning one (WWW page), the operator could be scanning you." This sad state of affairs is only because (toy) operating systems like DOS and Windows do not enforce what's called "access control": the ability to restrict users' (and programs') access to parts of your system (specially files). Even with OS's like Unix, it's not easy to setup (ie. you have to do lots of extra admin stuff), and even harder to get a transaction log (of accesses to restricted resources), unless you run extra security software (or want to wade through gobs of "ptrace" output). Not something an individual concerned about privacy would want to do. Back to what most of us run on: does anybody know of software for DOS or Windows that would limit access to subdirectories (via prior configuration), and notify the user if restrictions are violated by the currently running program(s), like some of the anti-virus software does? Note that read and write violations need to be reported, and that we are not trying to guard against (extremely) malicious software like viruses. Reply to me via e-mail, and I'll summarize interesting responses to this group (if appropriate). -- Uwe Zimmermann, Software Consultant, Summa Four, Inc., 603-625-4050 x2580 25 Sundial Ave., Manchester, NH 03103-7251 uwe@summa4.mv.com Privately uwe_zimmermann@mv.mv.com, CompuServe 75014,336 Finger uwe@mv.mv.com for PGP 5A DB 3E 44 D6 E6 C3 80 A5 F2 99 0A D0 9E C0 D9 ------------------------------ From: travis@racerx (Travis Lee Winfrey) Date: 27 Mar 1995 15:02:38 -0500 (EST) Subject: Re: Big Modem is Watching Organization: Fixed Income Division - Goldman, Sachs & Co. /DD.ID=OVMAIL1.WZR014/G=DANIEL/S=STICKA/@EDS.DIAMONDNET.sprint.com writes: The author then explores the possibility of the online service doing more, such as checking out the type of software you have loaded, or browsing your Quicken files for financial info, all without you knowing it. The big three (Prodigy, AOL, CompuServe) all deny looking at the subscriber's information other than available disk space, but the article describes some product registration software that did in fact snoop at software and update their database during the online registration process. Also, the existence of these downloading schemes means that they could conceivably be hijacked to do various things, whether or not the big service providers are themselves doing anything unwanted. (This also reminds me that it wouldn't be difficult to infect one of the AOL disk and replace it at a local magazine rack, possibly shrink-wrapped.) ------------------------------ From: Michal Szokolo Date: 27 Mar 95 02:21:54 +0200 Subject: Re: Can a LAN supervisor watch me? Organization: Selling Windoze is crime against mankind! DeMarco writes: Our workstations are networked, running NetWare - 250 user (I don't know the version No.) On boot-up, we (naturally) need to login with passwords, etc. If a user answers "no" to the login request, the workstation reverts to the "local" mode (the "C:\" prompt). BUT, it's still possible to type "F:" and receive the following: "F:\LOGIN". This means (to me) that although I'm _not_ "logged in", I'm still "attached" to the network in some fashion. NetWare is providing you with it's trusted copy of LOGIN.EXE, to avoid situation where someone installs fake LOGIN.EXE to gather passwords. My suspicion is that as long as the network interface card (NIC) is plugged into the workstation, and the cable from the NIC is plugged into the wall socket labled "DATA", there *always* remains a possibility that _someone_ , _somewhere_ can (using the network supervisory utilites, Intel's LanSight or "Satan" or _something_) read my hard drive, monitor my screen output or keyboard input. Using standard Novell utilities - NO. Supervisor can log off users, shut down server, read any and all files on network drives - but he can not spy on local disks/screens/etc even if users are logged on (however, he can then see what files they open - only names, but it may be significant). However, if someone installs "remote control" software, it may be possible to invigilate users as long as the network drivers are loaded. But again - such thing is not included in standard NetWare package. This is a particularly sensitive issue because as part of some of the work we do, certain data are explicity _restricted_ to viewing by certain _specific_ persons, and the mere ability that _anybody_ else (including the trusted LAN Supervisor) could have a peek at it would have significant legal ramifications. So, (1) what _are_ the strengths/limitations of the NetWare supervisor's abilities when I'm "attached" but not "logged in" to the LAN, It is possible to "cut you off" the network, probably causing lockup of your computer. It might be possible (with some extra utility) to find whether your machine is running. It is possible to read any and all files on network drives. (2) do I need to move all sensitive work to a physically isolated machine to be _assured_ of _total_ freedom from unauthorized access by others? (pulling the network connection plug is frowned upon) Either encrypt it or move it away and then encrypt it anyway. Network drives are only a bit safer than disks in publicly accessible machine. (3) any other suggestions? Have a look into memory - what's loaded? Borrow network manual and see if there's anything extra. Most snooping software I've seen makes no attempt to hide. -- |\/| << =// michal.szokolo@f19.n480.z2.fidonet.org | | >> //= msz@plearn.bitnet = msz@plearn.edu.pl ------------------------------ From: kadokev@rci.ripco.com (Kevin Kadow) Date: 27 Mar 1995 14:19:39 -0600 (CST) Subject: Re: Can a LAN supervisor watch me? From: jdemarco@netcom.com (John M. DeMarco) Please excuse a question from the paranoid: [ Misc deleted on Netware LAN, 'attached' to the server but not logged in ] As long as you have the network drivers loaded, there is the possibility that someone, somewhere can obtain information from your system. You could set the machine up so that you can boot without loading the network drivers, and as long as nobody secretly installs them, your data will be safe from the other users on the network. The most secure solution would be to install a network card with an AUI connection (most network cards have a 15-pin AUI connection) and use an external AUI transceiver with transmit and receive lights. You can then see when your system is transmitting, and if you need to do truly sensitive work, you can turn of your system and unplug the transceiver without disrupting the network. You might also consider moving sensitive data to a removable media and keeping it locked away when not in use. -- kadokev@ripco.com Kevin Kadow ------------------------------ From: eck@panix.com (Mark Eckenwiler) Date: 27 Mar 1995 07:44:16 -0500 Subject: Re: Is Reading E-Mail Legal? Organization: Saltieri, Poore, Nash, deBrutus & Short, Attorneys at Law ahoffman@li.net sez: Can someone give me a definitive authoritative answer regarding the exact status of if it is legal for system admins to read mail. Is e-mail covered in any law such as the electronic communicatiosn privacy act or the omni-bus crime bill? (I'm specifially referring to Internet providers). The answer is not a simple one. The pertinent *federal* law is chapters 119 and 121 of Title 18, U.S. Code. Under those statutes, 18 USC 2510 et seq., your sysadmin can read your mail (stored or simultaneously intercepted) a) in performing his/her normal duties (such as reforwarding misrouted mail) b) to protect the rights and property of the system owner (e.g., if there is reason to suspect system misuse or theft of services) c) with your consent, and consent can be created by posting a conspicuous notice that e-mail is subject to perusal by the sysadmin. State law may impose additional limits on the sysadmin's power to read your e-mail. ------------------------------ From: Robert Gellman Date: 27 Mar 1995 15:30:07 -0500 (EST) Subject: Fair Information Practices I thought that it might be a useful contribution to the Compter Privacy Digest to offer a copy of a code of fair information practices. It may be useful for reference or for information. Readers should understand that there is no universal code of fair information practices, but that all formulations are very similar. This happens to be a version that I prepared for another purpose. A Code of Fair Information Practices Prepared by Robert Gellman, Washington, D.C. rgellman@cais.com 1) The Principle of Openness, which provides that the existence of record-keeping systems and databanks containing data about individuals be publicly known, along with a description of main purpose and uses of the data. 2) The Principle of Individual Participation, which provides that each individual should have a right to see any data about himself or herself and to correct or remove any data that is not timely, accurate relevant, or complete. 3) The Principle of Collection Limitation, which provides that there should be limits to the collection of personal data, that data should be collected by lawful and fair means, and that data should be collected, where appropriate, with the knowledge or consent of the subject. 4) The Principle of Data Quality, which provides that personal data should be relevant to the purposes for which they are to be used, and should be accurate, complete, and timely. 5) The Principle of Use Limitation, which provides that there must be limits to the internal uses of personal data and that the data should be used only for the purposes specified at the time of collection. 6) The Principle of Disclosure Limitation, which provides that personal data should not be communicated externally without the consent of the data subject or other legal authority. 7) The Principle of Security, which provides that personal data should be protected by reasonable security safeguards against such risks as loss, unauthorized access, destruction, use, modification or disclosure. Sufficient resources should be available to offer reasonable assurances that security goals will be accomplished. 8) The Principle of Accountability, which provides that record keepers should be accountable for complying with fair information practices. --------------------------------------------------------- This formulation of a code of fair information practices is derived from several sources, including codes developed by the Department of Health, Education, and Welfare (1975); Organization for Economic Cooperation and Development (1981); and Council of Europe (1981). ------------------------------ From: "Prof. L. P. Levine" Date: 27 Mar 1995 12:19:04 -0600 (CST) Subject: Senate Committee Approves "Decency" Bill [EPIC 2.05] Organization: University of Wisconsin-Milwaukee Taken from EPIC Alert Published by the Electronic Privacy Information Center (EPIC) Washington, DC info@epic.org EPIC Alert 2.05 The Senate Commerce Committee voted on March 23 to incorporate a revised version of S. 314, the Communications Decency Act of 1995, into the telecommunications reform legislation. The amendment makes every person who creates, makes or solicits "any comment, request, suggestion, proposal or other communication which is obscene, lewd, lascivious, filthy, or indecent" subject to criminal prosecution. The bill also gives the FCC sweeping new authority to regulate on-line communications, and curtails First Amendment rights that currently exist for print communication. In a revision pushed by online providers, commercial carriers may avoid liability if they do not exercise editorial control over content, or if they take a series of good faith steps to comply with the statute. A provision criminalizing anonymous messages that "annoy, abuse, threaten, or harass" was also removed. However, users of on-line services, content providers, electronic publishers, and journalists face new restrictions on speech and private communications. For this reason, there is still considerable opposition to the bill. Civil liberties groups believe that the bill is unconstitutional. The Senate Commerce Committee approved the amendment, sponsored by Senator Slade Gorton (R-WA), unanimously by voice vote. The entire bill was approved by the Committee 17-2, subject to amendments. The bill now goes to the full Senate, where more amendments are expected to be added. The legislation has generated considerable controversy. Earlier this week, the presidents of the major computing societies in the US - ACM, IEEE, SIAM, CPSR and AAAI - wrote to Senator Exon expressing concern about the effects on the development of computer networks if the legislation was enacted. An Internet petition calling for the withdrawal of the legislation gathered over 100,000 signatures in only a few weeks and Senators on the Telecommunications subcommittee received a large number of calls, faxes and email messages on the bill. The bill is expected to be considered by the full Senate in the next few months. ------------------------------ From: "Prof. L. P. Levine" Date: 27 Mar 1995 12:19:04 -0600 (CST) Subject: Caller ID Snafus: FCC Delays [EPIC 2.05] Organization: University of Wisconsin-Milwaukee Taken from EPIC Alert Published by the Electronic Privacy Information Center (EPIC) Washington, DC info@epic.org EPIC Alert 2.05 The Federal Communications Commission announced on March 17 that it was delaying the implementation of rules proposed for interstate Caller ID. The rules were scheduled to go into effect on April 12, 1995, after four years of deliberation by the FCC. The order was delayed after the FCC received comments from telephone companies stating that they would not be able to comply in time. The FCC has not set a new date for implementation. There were also a number of petitions from state Public Utility Commissions and consumer organizations who opposed the original FCC order. The FCC order would have the effect of over-ruling state safeguards that currently require per line blocking. California has filed suit to prevent the FCC rule from going into effect. More than 40 states have required that per-line blocking be made available. The FCC also delayed enforcing the rule that common carriers who offer Automatic Number Identification (ANI) must inform customers that their number may be identified to the called party. ANI is used with 800 and 900 numbers. Problems also continued with the Caller ID services. There have been failures in at least 11 states with the implementation of per line blocking. One writer to the Telecom Digest reported that per call blocking also failed in Michigan due to a configuration error. ------------------------------ From: "Prof. L. P. Levine" Date: 27 Mar 1995 12:19:04 -0600 (CST) Subject: Commerce Dept. to Recommend Relaxing Crypto Control [EPIC 2.05] Organization: University of Wisconsin-Milwaukee Taken from EPIC Alert Published by the Electronic Privacy Information Center (EPIC) Washington, DC info@epic.org EPIC Alert 2.05 The Bureau of National Affairs reports that the Department of Commerce will recommend that the United States relax export controls on cryptography. The recommendations will be presented to the President in early July. The National Security Agency is expected to release a report on the availability of foreign encryption software which will be presented to the President at the same time. The Commerce Department has also filed a request with the Office of Management and Budget to collect information on the damage to US businesses resulting from current export controls. The Software Publishers Association, in a December survey of encryption software currently available, identified 407 foreign encryption products, 120 of which used the Data Encryption Standard (DES). The SPA found 480 domestic encryption products. ------------------------------ From: "Prof. L. P. Levine" Date: 27 Mar 1995 12:19:04 -0600 (CST) Subject: Maryland Debates Online Privacy [EPIC 2.05] Organization: University of Wisconsin-Milwaukee Taken from EPIC Alert Published by the Electronic Privacy Information Center (EPIC) Washington, DC info@epic.org EPIC Alert 2.05 On March 11, the Maryland House of Delegates held landmark hearings on online privacy. The hearing marked the first time that a state legislature had taken up the issue of privacy on the NII. The bill, SB 524, was prompted by revelations last year that America Online and other service providers were selling information about their customers to direct marketers. In the case of AOL, the users were not informed until after newspapers reported that advertisements for AOL member profiles appeared in a direct marketing magazine. The legislation requires that an "online computer service may not disclose personal information concerning a subscriber to any other person unless the subscriber ...has received notice ... and consented to the disclosure." The consent can be in electronic or written form. Online providers are also required to tell customers up front what information is being collected, how it is being used, and how customers can access their records. Dave Banisar from EPIC testified on behalf of the bill. He argued that the bill was a modest attempt to protect individual privacy. He noted that the provisions of the act were already incorporated in the 1980 OECD guidelines on privacy which was endorsed by many US companies in the early 1980's and the Code of Fair Information Practices, first developed in 1973. Opposing the bill were representatives from AOL, AT&T, Sprint, MCI and the Direct Marketing Association. The online providers argued that legislation should be placed on hold until national legislation is enacted, which is highly unlikely this term in Congress. The DMA strongly opposed the bill. Bell Atlantic, said that they may support the bill if it were revised to require an opt out. The sponsors of the bill indicated that they were agreeable to the change. The bill was sent to a committee for review over the summer break. It is expected to be reintroduced again next session. ------------------------------ From: "Prof. L. P. Levine" Date: 29 Dec 1994 10:50:22 -0600 (CST) Subject: Info on CPD [unchanged since 12/29/94] 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 or append to 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. Mosaic users will find it at gopher://gopher.cs.uwm.edu. Older archives are also held at ftp.pica.army.mil [129.139.160.133]. ---------------------------------+----------------------------------------- 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 | Mosaic: gopher://gopher.cs.uwm.edu ---------------------------------+----------------------------------------- ------------------------------ End of Computer Privacy Digest V6 #030 ****************************** .