sbrack@isis.cs.du.edu (Steven S. Brack) (05/01/91)
In article <1991Apr30.184714.4675@mnemosyne.cs.du.edu> sbrack@isis.UUCP (Me) writes: >Two articles appeared in comp.dcom.telecom recently: > >The first talks about Prodigy apparently uploading information from users >machines without their knowledge. This information has included programs, >legal records, & personal documents. ===== Start reposted Article ===== From mnemosyne.cs.du.edu!uunet!spool.mu.edu!telecom-request Mon Apr 29 03:48:35 MDT 1991 X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 311, Message 1 of 4 "Mark A. Emanuele" <overlf!emanuele@kb2ear.ampr.org> writes: I just downloaded this from a local bbs and thought it might be interesting. ### BEGIN BBS FILE ### 218/250: Fraudigy Name: George J Marengo #199 @6974 From: The Gangs of Vista (Southern California) 619-758-5920 The L. A. County District Attorney is formally investigating PRODIGY for deceptive trade practices. I have spoken with the investigator assigned (who called me just this morning, February 22, 1991). We are free to announce the fact of the investigation. Anyone can file a complaint. From anywhere. The address is: District Attorney's Office Department of Consumer Protection Attn: RICH GOLDSTEIN, Investigator Hall of Records Room 540 320 West Temple Street Los Angeles, CA 90012 Rich doesn't want phone calls, he wants simple written statements and copies (no originals) of any relevant documents attached. He will call the individuals as needed, he doesn't want his phone ringing off the hook, but you may call him if it is urgent at 1-213-974-3981. PLEASE READ THIS SECTION EXTRA CAREFULLY. YOU NEED NOT BE IN CALIFORNIA TO FILE!! If any of us "locals" want to discuss this, call me at the Office Numbers: (818) 989-2434; (213) 874-4044. Remember, the next time you pay your property taxes, this is what you are supposed to be getting ... service. Flat rate? [laugh] BTW, THE COUNTY IS REPRESENTING THE STATE OF CALIFORNIA. This ISN'T limited to L. A. County and complaints are welcome from ANYWHERE in the Country or the world. The idea is investigation of specific Code Sections and if a Nationwide Pattern is shown, all the better. LARRY ROSENBERG, ATTY Prodigy: More of a Prodigy Than We Think? By: Linda Houser Rohbough The stigma that haunts child prodigies is that they are difficult to get along with, mischievous and occasionally, just flat dangerous, using innocence to trick us. I wonder if that label fits Prodigy, Sears and IBM's telecommunications network? Those of you who read my December article know that I was tipped off at COMDEX to look at a Prodigy file, created when Prodigy is loaded STAGE.DAT. I was told I would find in that file personal information form my hard disk unrelated to Prodigy. As you know, I did find copies of the source code to our product FastTrack, in STAGE.DAT. The fact that they were there at all gave me the same feeling of violation as the last time my home was broken into by burglars. I invited you to look at your own STAGE.DAT file, if you're a Prodigy user, and see if you found anything suspect. Since then I have had numerous calls with reports of similar finds, everything from private patient medical information to classified government information. The danger is Prodigy is uploading STAGE.DAT and taking a look at your private business. Why? My guess is marketing research, which is expensive through legitimate channels, and unwelcomed by you and I. The question now is: Is it on purpose, or a mistake? One caller theorizes that it is a bug. He looked at STAGE.DAT with a piece of software he wrote to look at the physical location of data on the hard disk, and found that his STAGE.DAT file allocated 950,272 bytes of disk space for storage. Prodigy stored information about the sections viewed frequently and the data needed to draw those screens in STAGE.DAT. Service would be faster with information stored on the PC rather then the same information being downloaded from Prodigy each time. That's a viable theory because ASCII evidence of those screens shots can be found in STAGE.DAT, along with AUTOEXEC.BAT and path information. I am led to belive that the path and system configuration (in RAM) are diddled with and then restored to previous settings upon exit. So the theory goes, in allocating that disk space, Prodigy accidently includes data left after an erasure (As you know, DOS does not wipe clean the space that deleted files took on the hard disk, but merely marked the space as vacant in the File Allocation Table.) There are a couple of problems with this theory. One is that it assumes that the space was all allocated at once, meaning all 950,272 bytes were absorbed at one time. That simply isn't true. My STAGE.DAT was 250,000+ bytes after the first time I used Prodigy. The second assumption is that Prodigy didn't want the personal information; it was getting it accidently in uploading and downloading to and from STAGE.DAT. The E-mail controversy with Prodigy throws doubt upon that. The E-mail controversy started because people were finding mail they sent with comments about Prodigy or the E-mail, especially negative ones, didn't ever arrive. Now Prodigy is saying they don't actually read the mail, they just have the computer scan it for key terms, and delete those messages because they are responsible for what happens on Prodigy. I received a call from someone from another user group who read our newsletter and is very involved in telecommunications. He installed and ran Prodigy on a freshly formatted 3.5 inch 1.44 meg disk. Sure enough, upon checking STAGE.DAT he discovered personal data from his hard disk that could not have been left there after an erasure. He had a very difficult time trying to get someone at Prodigy to talk to about this. -------------- Excerpt of email on the above subject: THERE'S A FILE ON THIS BOARD CALLED 'FRAUDIGY.ZIP' THAT I SUGGEST ALL WHO USE THE PRODIGY SERVICE TAKE ***VERY*** SERIOUSLY. THE FILE DESCRIBES HOW THE PRODIGY SERVICE SEEMS TO SCAN YOUR HARD DRIVE FOR PERSONAL INFORMATION, DUMPS IT INTO A FILE IN THE PRODIGY SUB-DIRECTORY CALLED 'STAGE.DAT' AND WHILE YOU'RE WAITING AND WAITING FOR THAT NEXT MENU COME UP, THEY'RE UPLOADING YOUR STUFF AND LOOKING AT IT. TODAY I WAS IN BABBAGES'S, ECHELON TALKING TO TIM WHEN A GENTLEMAN WALKED IN, HEARD OUR DISCUSSION, AND PIPED IN THAT HE WAS A COLUMNIST ON PRODIGY. HE SAID THAT THE INFO FOUND IN 'FRAUDIGY.ZIP' WAS INDEED TRUE AND THAT IF YOU READ YOUR ON-LINE AGREEMENT CLOSELY, IT SAYS THAT YOU SIGN ALL RIGHTS TO YOUR COMPUTER AND ITS CONTENTS TO PRODIGY, IBM & SEARS WHEN YOU AGREE TO THE SERVICE. I TRIED THE TESTS SUGGESTED IN 'FRAUDIGY.ZIP' WITH A VIRGIN 'PRODIGY' KIT. I DID TWO INSTALLATIONS, ONE TO MY OFT USED HARD DRIVE PARTITION, AND ONE ONTO A 1.2MB FLOPPY. ON THE FLOPPY VERSION, UPON INSTALLATION (WITHOUT LOGGING ON), I FOUND THAT THE FILE 'STAGE.DAT' CONTAINED A LISTING OF EVERY .BAT AND SETUP FILE CONTAINED IN MY 'C:' DRIVE BOOT DIRECTORY. USING THE HARD DRIVE DIRECTORY OF PRODIGY THAT WAS SET UP, I PROCEDED TO LOG ON. I LOGGED ON, CONSENTED TO THE AGREEMENT, AND LOGGED OFF. REMEMBER, THIS WAS A VIRGIN SETUP KIT. AFTER LOGGING OFF I LOOKED AT 'STAGE.DAT' AND 'CACHE.DAT' FOUND IN THE PRODIGY SUBDIRECTORY. IN THOSE FILES, I FOUND POINTERS TO PERSONAL NOTES THAT WERE BURIED THREE SUB-DIRECTORIES DOWN ON MY DRIVE, AND AT THE END OF 'STAGE.DAT' WAS AN EXACT IMAGE COPY OF MY PC-DESKTOP APPOINTMENTS CALENDER. CHECK IT OUT FOR YOURSELF. ### END OF BBS FILE ### I had my lawyer check his STAGE.DAT file and he found none other than CONFIDENTIAL CLIENT INFO in it. Needless to say he is no longer a Prodigy user. Mark A. Emanuele V.P. Engineering Overleaf, Inc. 218 Summit Ave Fords, NJ 08863 (908) 738-8486 emanuele@overlf.UUCP [Moderator's Note: Thanks very much for sending along this fascinating report for the readers of TELECOM Digest. I've always said, and still believe that the proprietors of any online computer service have the right to run it any way they want -- even into the ground! -- and that users are free to stay or leave as they see fit. But it is really disturbing to think that Prodigy has the nerve to ripoff private stuff belonging to users, at least without telling them. But as I think about it, *who* would sign up with that service if they had bothered to read the service contract carefully and had the points in this article explained in detail? PAT] From mnemosyne.cs.du.edu!uunet!spool.mu.edu!mips!pacbell.com!lll-winken!telecom-request Mon Apr 29 03:50:16 MDT 1991 X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 314, Message 5 of 8 "Mark A. Emanuele" <overlf!emanuele@kb2ear.ampr.org> writes: > I just downloaded this from a local bbs and thought it might be > interesting. > Prodigy: More of a Prodigy Than We Think? > By: Linda Houser Rohbough > Those of you who read my December article know that I was tipped > off at COMDEX to look at a Prodigy file, created when Prodigy is > loaded STAGE.DAT. I was told I would find in that file personal > information form my hard disk unrelated to Prodigy. As you know, I > did find copies of the source code to our product FastTrack, in > STAGE.DAT. The fact that they were there at all gave me the same > feeling of violation as the last time my home was broken into by > burglars. The orginal author then speculates: > So the theory goes, in allocating that disk space, Prodigy > accidently includes data left after an erasure (As you know, DOS does > not wipe clean the space that deleted files took on the hard disk, but > merely marked the space as vacant in the File Allocation Table.) > There are a couple of problems with this theory. One is that it > assumes that the space was all allocated at once, meaning all 950,272 > bytes were absorbed at one time. That simply isn't true. My > STAGE.DAT was 250,000+ bytes after the first time I used Prodigy. The > second assumption is that Prodigy didn't want the personal > information; it was getting it accidently in uploading and downloading > to and from STAGE.DAT. I don't think that this explanation has been adequately refuted. When I examined my STAGE.DAT, I found lots of "private" information on the leftover ends of sectors - a sure sign that no erasure of prior information was being done by the Prodigy software. Since this is standard practice in DOS programming we all need to be more careful about this type of problem. I am never able to understand folks who reach in drawer, "erase files from the floppy retrieved", then copy a file over to the disk to give to me certain that I cannot read what was on the disk before! But I digress. Even the experiments reported later in the posting really don't discount this explanation. In that experiment, the user ran from a floppy based disk, but on a system with a hard disk. If I were a Prodigy programmer, I would consider it good programming to look for scratch space on every device available to me. If I could find hard disk scratch space, I would use it. Then when terminating the program I might copy it from the hard disk to the floppy so it would be available to me the next time I ran the program. Whether the space is allocated all at one point in time, is allowed to grow, or is allocated and deallocated dynamically matters not at all. The big problem is that there is always the problem of data from a previous file being included as parts of a new file. If you are concerned about this, you need to get one of the many programs which really do "erase" the file when it is deleted or encrypt all such files - be careful, however, about whether your word processor or compiler doesn't use scratch files that you will need to erase or encrypt as well. If you use Windows that uses a disk scratch file for the support of virtual memory you need to be concerned that something that was core resident isn't out there on your disk now. I don't want to maintain that the Prodigy folks are clean here, only that before we start making chargers that they are actually intentionally uploading information we need more proof. Anyone who is actually interested in this can monitor what is going out to the modem and then make their charges. Just because it is in a scratch data set proves nothing. Also that their customer reps can't answer any technical question about their software reveals nothing other than they are like the telephone company operators we all deal with :-* I also want to attempt to deal with the rapidly developing urban legend about the Prodigy censoring. As far as I am aware of, the censoring of the "Roosevelt Dimes" message etc were in posting to one of their "moderated groups" similiar to what Pat does all the time here :-). It was not in private e-mail. J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 phil@wubios.WUstl.edu - Internet (314) 362-3617 uunet!wuarchive!wubios!phil - UUCP (314)362-2693(FAX) C90562JM@WUVMD - bitnet ===== End Reposted Article ===== -- =========================================================================== Steven S. Brack sbrack@nyx.cs.du.edu | I have yet to find a I am not speaking for the Ohio State University. | quote good enough & Now, if only I could convince them of that 8) | short enough.
seurer+@rchland.ibm.com (Bill Seurer) (05/01/91)
I plan on running a little test tonight to see if this is true. 1) De-install Prodigy. (Erase all the Prodigy-installed files) 2) Run CLEANDSK (or equivalent) to overwrite all unused disk space with 0's. 3) Run CLEANEND (or equivalent) to overwrite the unused ends of files with 0's. 4) Modify CONFIG.SYS and/or AUTOEXEC.BAT to have 0 DOS buffers and remove any disk caching TSRs. 5) Defragment the harddisk. 6) Power PC off and then on to remove any DOS buffers and other resident stuff. 7) Re-install Prodigy. (Use a large STAGE.DAT) 8) Power PC off and then on to remove any DOS buffers and other resident stuff. 9) Immediately sign on Prodigy, poke around a bit, then sign off. 10) Dump STAGE.DAT and see what's inside. Does that sound reasonable? Can anyone think of other steps to take? - Bill Seurer IBM: seurer+@rchland Prodigy: CNSX71A Rochester, MN Internet: seurer+@rchland.vnet.ibm.com
jrbd@craycos.com (James Davies) (05/01/91)
> I received a call from someone from another user group who read >our newsletter and is very involved in telecommunications. He >installed and ran Prodigy on a freshly formatted 3.5 inch 1.44 meg >disk. Sure enough, upon checking STAGE.DAT he discovered personal data >from his hard disk that could not have been left there after an >erasure. Question: was he using an unused disk, or did he just reformat an old one, assuming that it would be wiped clean? Could some Prodigy user out there try this experiment again, this time using a verifiably empty disk? I get the feeling that this hasn't exactly been a controlled experiment so far...
jerry@matt.ksu.ksu.edu (Jerry J. Anderson) (05/01/91)
jrbd@craycos.com (James Davies) writes: >> He >>installed and ran Prodigy on a freshly formatted 3.5 inch 1.44 meg >>disk. Sure enough, upon checking STAGE.DAT he discovered personal data >>from his hard disk that could not have been left there after an >>erasure. >Question: was he using an unused disk, or did he just reformat an old >one, assuming that it would be wiped clean? >Could some Prodigy user out there try this experiment again, this >time using a verifiably empty disk? I get the feeling that this hasn't >exactly been a controlled experiment so far... If you're serious about it, start with a wipedisk. Then install a few files without erasing any. That way, the only non-wiped areas on the disk will be currently used for files. If STAGE.DAT and CACHE.DAT don't come up empty, you'll know something fishy is going on. -- Jerry J. Anderson Computing Activities Kansas State University Internet: jerry@ksuvm.ksu.edu Manhattan KS 66506
cyberoid@milton.u.washington.edu (Robert Jacobson) (05/01/91)
The Electronic Commerce Act (Moore, 1984), California Civil Code, provides that operators of online services (among other interactive services) must tell users at least minimal information about how they conduct their business. Failure to do so can result in prosecution and fines of $5,000 >per occurrence.< (This apparently high penalty was set to encourage local prosecutors, like the L.A. District Attorney, to take action, as they can pocket part of the fine as compensation.) The ECA may not be strong enough, however. Those who have an interest in expanding the scope of the law, given unsavory practices of some online operators, should contact Mr. Bill Julian, Principal Consultant, Assembly Utilities and Commerce Committee, State Capitol, Sacramento, CA 95814, 916-445-4246. Other states may have similar statutes in effect. Bob Jacobson --
cyberoid@milton.u.washington.edu (Robert Jacobson) (05/01/91)
The problem inherent in Prodigy's client-server method of service delivery has always been that the system can create a template, a mirror image, of the personal information entered into the person's PC in the course of activity. I don't know if this has happened; Prodigy's managers have always seemed to be aware of the danger of invasion of privacy when questioned about it. Bob Jacobson --
zane@ddsw1.MCS.COM (Sameer Parekh) (05/01/91)
Thank you for posting that. I had previously thought that Prodigy was simply a dumb service. Now I am committed to the education of people to stop using Prodigy. I will be writing an 'information sheet' which I will distribute so that we can educate those who are not on the net. I will post it here first so that I may get feedback on how it is. (I didn't hear about it from this post, a friend who obviously read this post told me about it.) -- The Ravings of the Insane Maniac Sameer Parekh -- zane@ddsw1.MCS.COM
kdenning@genesis.Naitc.Com (Karl Denninger) (05/01/91)
In article <1991Apr30.225133.8165@craycos.com> jrbd@craycos.com (James Davies) writes: >> I received a call from someone from another user group who read >>our newsletter and is very involved in telecommunications. He >>installed and ran Prodigy on a freshly formatted 3.5 inch 1.44 meg >>disk. Sure enough, upon checking STAGE.DAT he discovered personal data >>from his hard disk that could not have been left there after an >>erasure. > >Question: was he using an unused disk, or did he just reformat an old >one, assuming that it would be wiped clean? > >Could some Prodigy user out there try this experiment again, this >time using a verifiably empty disk? I get the feeling that this hasn't >exactly been a controlled experiment so far... Note one thing well: All formats on a floppy disk ARE LOW LEVEL FORMATS. That is, all data is physically erased, sector marks are rewritten, the whole works. It is not possible on a DOS machine to issue a "FORMAT A:" and have any data retained on the diskette from prior use. Try it. You'll see that this is the case. To do a controlled test, do the following: 1) Bulk erase and then format a floppy diskette. NO CHANCE of any residual data on the disk surface after this. 2) Run a "cleandisk" program to write ZEROS to all unallocated areas of the fixed disk in the machine. This will guarantee that all unallocated areas, which may be used for scratch buffers, have no data on them. The tail end of files are irrelavent -- that's an ALLOCATED area and should not be touched by the software if it's being "honest". 3) Install Prodigy on the floppy disk. Do not touch the hard drive, or run any software from it. Work >only< on the floppy disk. 4) Call Prodigy. Spend an hour or two online. Give 'em plenty of time to hose you if they're going to. 5) Sign off and look at STAGE.DAT on the floppy disk. Alternately, after cleaning the disk, install the Prodigy software on the fixed disk. DO NOT ACCESS ANY OTHER PROGRAMS OR DATA. Immediately run Prodigy, dial in, and use it for a couple of hours. Then check STAGE.DAT on the fixed disk. Since you zeroed all unallocated areas on the drive before you began, there is no way the STAGE.DAT file could have gotten private data in it unless the software is scanning your fixed disk drive. This should provide rather conclusive proof one way or the other. I'm not a Prodigy subscriber, or I'd try this... -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
seurer+@rchland.ibm.com (Bill Seurer) (05/01/91)
The Prodigy experiment Because of all the rumors flying around of Prodigy uploading data off of user's harddisks I decided to test if this was happening. All of these rumors are based on the fact that the staging file (STAGE.DAT) Prodigy uses to buffer its screens on the harddisk sometimes is found to contain bits and pieces of user files and directories. Some users claim this proves Prodigy is uploading the data while others just say it is an artifact of the way that DOS allocates files and because Prodigy does not initialize the file when it is created. I devised and carried out the following experiment in order to test if this was happening. The results are: Prodigy does not appear to be uploading any data. The STAGE.DAT file contains bits and pieces of ERASED files. The experiment went as follows: 1) Re-installed Prodigy. I erased all of the files Prodigy had installed on my system. 2) Modified CONFIG.SYS and AUTOEXEC.BAT to remove all TSRs and have 0 DOS buffers. I removed the disk caching software I usually use. This was to prevent any leftovers in buffers or caches from showing up in STAGE.DAT and so that I could monitor what the harddisk was doing more easily. 3) Defragmented the harddisk so that all files were in contiguous blocks. 4) I ran CLEANDSK and CLEANEND to write zeroes over all the unused parts of the disk and over the unused ends of DOS files. 5) Powered the PC off and then on. All memory was therefore flushed and the minimal system with no buffers was in use. 6) I created several large (500k) files each containing a different pattern of characters. After all were created, I erased them. This was to test whether STAGE.DAT is picking up bits of erased files. 7) I installed Prodigy using a large buffer. This created a STAGE.DAT file that was just under 1 meg in size. 8) I browsed STAGE.DAT to see what was inside. The first 250k or so had interesting stuff and the other 750k was 0's. The interesting stuff was mostly buffered Prodigy windows (I could tell by the text that was mixed in) along with scattered pieces of one of the files I had created and deleted in step 7. This file made up about 100k of STAGE.DAT. and given where the data was I'd guess that the first 200k or so of STAGE.DAT had been overlaid on the disk where this file used to be. The *ONLY* non-Prodigy thing that I saw was a copy of my environment variables (COMPSEC, PATH, and PROMPT). I noted that the windows that were buffered were the "old" windows (Prodigy has changed many of its windows since I got my installation kit). 9) Made a copy of STAGE.DAT so that I could compare it with an updated copy after I signed on. 10) I again powered the PC off and on to clear all the memory. 11) I signed on Prodigy. While on I read some mail, sent some mail, read a few BBS appends, and looked at a couple of ads. Then I signed off. I noticed some things when I signed on. First of all, it took a looooong time. I surmised that all those "old" windows I had seen in STAGE.DAT were being updated. I carefully watched my modem lights and harddisk light (remember, I had no buffering). About 95% of the time (at least!) the modem was receiving data. At the end of each long receive (some were 4 or 5 seconds long) the hard disk would be used briefly and the modem transmit light would flicker on. Then there would be another long receive and etc. At no time was my modem transmitting for more than a fraction of a second. 12) Using a hex/ASCII file comparison tool I compared the contents of the STAGE.DAT that I had saved with the updated one after I logged off Prodigy. Many of the menus I had noticed the first time I looked were changed to the newer formats. Also, the sign off menus and some of the messaging menus had either overwritten some (but not all) of the data from the file I had created and deleted in step 7 or been added at the end of the 250k of initially used area in STAGE.DAT. STAGE.DAT now had about 280k of used area less perhaps 80-90k of data from the file in step 7. From this experiment I would say that all the stuff about Prodigy uploading files is rumors started by people ignorant of how DOS works. Some people said that they reinstalled Prodigy to see if that changed STAGE.DAT but they didn't defragment/zero out their disks first so their data is highly suspect. If they had watched their modem lights they would realize that almost no time is spent sending data to Prodigy when signing on but is almost all sent receiving it. If I were to run this again I would change step 7 to completely fill up the unused portion of my harddisk with the dummy files and then erase them all. My guess is that the 750k of space at the end of STAGE.DAT would then contain bits from those files. Later this week I think I'll try this and see. My set-up in case you're interested is: IBM PC-1 (the original) with an Intel Inboard/386, 40 meg harddisk, and 2400 modem. I use DOS 3.2 and the version of Prodigy I installed was 3.1 which is the latest I believe. If you have any questions about the experiment I'm more than happy to answer them. Also, if you have suggestions for more things to try next time let me know. - Bill Seurer IBM: seurer+@rchland Prodigy: CNSX71A Rochester, MN Internet: seurer+@rchland.vnet.ibm.com
esf00@uts.amdahl.com (Elliott S. Frank) (05/01/91)
In article <1991Apr30.185752.4913@mnemosyne.cs.du.edu> sbrack@isis.UUCP (Steven S. Brack) writes: >In article <1991Apr30.184714.4675@mnemosyne.cs.du.edu> sbrack@isis.UUCP (Me) writes: >>Two articles appeared in comp.dcom.telecom recently: >> >>The first talks about Prodigy apparently uploading information from users >>machines without their knowledge. This information has included programs, >>legal records, & personal documents. > [excerpt from reposted article] > > The danger is Prodigy is uploading STAGE.DAT and taking a look at >your private business. Why? My guess is marketing research, which is >expensive through legitimate channels, and unwelcomed by you and I. >The question now is: Is it on purpose, or a mistake? One caller >theorizes that it is a bug. He looked at STAGE.DAT with a piece of >software he wrote to look at the physical location of data on the hard >disk, and found that his STAGE.DAT file allocated 950,272 bytes of >disk space for storage. > >The orginal author then speculates: > >> So the theory goes, in allocating that disk space, Prodigy >> accidently includes data left after an erasure (As you know, DOS does >> not wipe clean the space that deleted files took on the hard disk, but >> merely marked the space as vacant in the File Allocation Table.) > I was concerned about what the Prodigy software would do back when it first came out. If you read the shrinkwrap license agreement, by signing onto Prodigy (and therefore agreeing to the terms and conditions under which they offer the service), you will find (paraphrased -- I don't have the text of the agreement in front of me) that you *have* agreed to allow them to upload *anything that they want* off your system. If the contents of STAGE.DAT are random and ignored at this point in time, you have still agreed that *whatever* they can find on your system can be uploaded and used for any purpose they desire. [I would hope that someone could find their "little yellow box" and post the text in question -- it would add signal to the signal-to- noise ratio surrounding this issue.] There was a discussion on the license agreement on RISKS when Prodigy first appeared, and the ramifications of the license agreement were explored. As you might expect, I never did log on to Prodigy. -- Elliott Frank ...!{uunet,sun}!amdahl!esf00 (408) 746-6384 or ....!esf00@amdahl.com [the above opinions are strictly mine, if anyone's.]
louisg@vpnet.chi.il.us (Louis Giliberto) (05/01/91)
In article <1991Apr30.185752.4913@mnemosyne.cs.du.edu> sbrack@isis.UUCP (Steven S. Brack) sends us an article stating: > >intentionally uploading information we need more proof. Anyone who is >actually interested in this can monitor what is going out to the modem >and then make their charges. Just because it is in a scratch data set >proves nothing. Also that their customer reps can't answer any >technical question about their software reveals nothing other than >they are like the telephone company operators we all deal with :-* > [author's name deleted since not involved in this conversation] > ===== End Reposted Article ===== Thank you for that article. It was *very* informative. I cancelled Prodigy a while back for the E-Mail limit reason (plus I recevied access to Internet, so I don't need it; I can annoy people here). A couple of comments on the above author's question of proof: (they are *not* Mr. Brack's; he just forwarded the info!!) 1) If I were a programmer with a scratch data set that was basically a cache as Prodigy claims they use it, I would not save unused sectors; would you? True, with Windows (tm MicroSoft) you can have a permanent swap file, but that is permanent in size, it nevers grows or shrinks. The Prodigy file *does* change in size, and I doubt it's due to a faulty allocation algorithm. 2) If there is *any* information from sectors that have been not deleted, then that is proof positive that the program is picking your files. If it were merely allocated and unused sectors containing data from the last delete, then it would not be able to contain "live" data. 3) As for using the hard disk area, no, as a programmer I would not. The reasonbeing that I was not given that area to use. I was being used on a floppy. If I did put a temp file on the hard drive without prior consent (GOd only knows why some idiot programmer would do that), I sure as hell wouldn't copy the sectors over to the floppy. Why save the sectors of a temp file? Temp means temporary! 4) The problem with a "saved" cache as this seems to be is that on Prodigy, the screens change *every* day. There is no reason to save the cache. That's true of any cache. On Windows (tm) you can have a non-permanent cache; why? because the info is worthless after that session. The permanent cache just ensures enough drive space is always present. The Prodigy cache seems to be dynamic, so it isn't saved to ensure enough drive space. Why is it saved then? 5) I've expressed my opinions on Prodigy before, and I'll express them again: It is one huge marketing scam, IMHO. I would not be surprised if they were gleaning info for marketing purposes. There is no service beyond sales. This is from an ex-Prodigy user. If it weren't illegal, I might suggest someone reverse compiling / unassembling the code an poke around. But that's illegal, so I won't suggest it. :-) I'll have to check my disks. I wonder what they thought when they found like 10 megs worth of Phrack on my hard drive? ;-) Louis Giliberto (louisg@vpnet.chi.il.us) -- --------------------------------------------------------------------------- ! "As above, so below; as below, so above" -- The Kybalion ! ! "I don't trust him; he has dark hair" -- My girlfriend's mother ! ! "So I'm stupid; what's your point?" -- Me !
Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) (05/02/91)
Quoting Jerry J. Anderson's msg of 01 May: >> He >>installed and ran Prodigy on a freshly formatted 3.5 inch 1.44 meg The standard DOS FORMAT.COM program actually writes E5's to all data sectors. A disk so formatted is completely and thoroughly blank. Aftermarket formatters such as NORTON et al have schemes to simply erase or move directories to help "unformat" later. FORMAT A: Will completely and thoroughly blank a diskette irretrievably assuming it's MSDOS or DOS FORMAT.COM. -- Tom Jennings - via FidoNet node 1:125/777 UUCP: ...!uunet!hoptoad!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
tmkk@uiuc.edu (K. Khan) (05/02/91)
In article <sc7Ryf491EAf8CjSg4@rchland.ibm.com> seurer+@rchland.ibm.com (Bill Seurer) writes: >I plan on running a little test tonight to see if this is true. > >1) De-install Prodigy. (Erase all the Prodigy-installed files) >2) Run CLEANDSK (or equivalent) to overwrite all unused disk space with 0's. >3) Run CLEANEND (or equivalent) to overwrite the unused ends of files with 0's. I used Norton's WIPEDISK (version 4.5) which does the same thing, only I overwrote the erased areas with 0x20 (ASCII space character) to make anything else stand right out. I did this on both hard drives, and disconnected my network drives. >4) Modify CONFIG.SYS and/or AUTOEXEC.BAT to have 0 DOS buffers and >remove any disk caching TSRs. >5) Defragment the harddisk. >6) Power PC off and then on to remove any DOS buffers and other resident stuff. >7) Re-install Prodigy. (Use a large STAGE.DAT) >8) Power PC off and then on to remove any DOS buffers and other resident stuff. >9) Immediately sign on Prodigy, poke around a bit, then sign off. >10) Dump STAGE.DAT and see what's inside. > >Does that sound reasonable? Can anyone think of other steps to take? Sounds good. Let us know what you come up with. I am no longer a Prodigy subscriber (they sent me the software free and a 1-month free trial, so I decided to see for myself what everyone was slamming), so I did not go as far as actually logging on, but I did complete the installation, complete with STAGE.DAT. I used Norton Utilities to view the contents of STAGE.DAT. I saw that it contained my complete path string, as well as LOTS of prodigy screens (telling me that if I clicked on 'accept' that I would be agreeing to pay for all charges blah blah blah). That's all I saw - no (recognizable) evidence of data snatched from other files on my two hard disks. on. (Needless to say, I was very disappointed! ;-)
brad@looking.on.ca (Brad Templeton) (05/02/91)
Let us not forget that at this time, the industry is still young, and while we should strive to get all the facts, the only thing we should *do* about anything we don't like is vote with our feet, as many Prodigy users reportedly have done. There is a healthy competitive market in online services, ranging from the big boys to USENET to thousands of local BBSs. The main thing covered by existing statute is the privacy of E-mail. I doubt any of the big services are reading E-mail of the users. They have all, to the best of my knowledge, explicitly stated that they don't. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
dale@cec2.wustl.edu (Dale Frye) (05/02/91)
In article <1991May01.024205.13181@ddsw1.MCS.COM> zane@ddsw1.MCS.COM (Sameer Parekh) writes: > > Thank you for posting that. I had previously thought that Prodigy >was simply a dumb service. Now I am committed to the education of people to >stop using Prodigy. I will be writing an 'information sheet' which I will >distribute so that we can educate those who are not on the net. I will post >it here first so that I may get feedback on how it is. > (I didn't hear about it from this post, a friend who obviously read >this post told me about it.) The evidence presented so far has been in a word "SHODDY". Before you go making statements about this matter I would advise you to investigate more fully. Telling people not to use this service because of a supposely found problem that later turns out to be false opens the possibility of being sued for LIBEL. You could be sued for loss of revenue for each and every user you convince to discontinue or not use the service. This includes lost advertising revenue. The "litmus" tests I have seen so far are invalid. They show a lack of understanding of all the possible ways for this to happen (and there are many!) The proper test should be: 1: wipe the hard disk clean -- i.e. low level reformat or wipedisk etc. Note: This should be done to any and all disks, partitions, etc on the system. (Or remove them) 2: insure all disks are clean!! 3: install test files to look for(if needed). Do not delete anything. Do not use any disk compressor. Just copy the files onto the disk. 4: POWER OFF the machine. Wait 10 min. (Yes, 10 MIN!) 5: Turn machine on and verify memory is clear. Don't do anything except what is listed here. Especially don't go looking at files. Don't do anything that might bring a file into memory or a disk buffer. 6: install prodigy 7: run prodigy for a period of time (1 hour or so) 8: NOW check the STAGE.DAT file. An even better test would to be to monitor the data being sent back to Prodigy. Dale Frye Washington University in St. Louis P.S. I'm not trying to defend Prodigy. I just hate it when people go off half cocked.
leng@ruacad.ac.runet.edu (Lud Eng) (05/02/91)
In article <1991May1.051734.24594@pcserver2.naitc.com> kdenning@genesis.Naitc.Com (Karl Denninger) writes: >Alternately, after cleaning the disk, install the Prodigy software on the >fixed disk. DO NOT ACCESS ANY OTHER PROGRAMS OR DATA. Immediately run >Prodigy, dial in, and use it for a couple of hours. > >Then check STAGE.DAT on the fixed disk. > >Since you zeroed all unallocated areas on the drive before you began, there >is no way the STAGE.DAT file could have gotten private data in it unless the >software is scanning your fixed disk drive. > >This should provide rather conclusive proof one way or the other. Karl, As someone else pointed out, this is not conclusive. Due to the way the Prodigy software works, it may well be trying to buffer to the hard drive even if it's not installed there. If there is indeed a bug in it, I guess it's possible that instead of reading from the buffer file it would write random things read from random places on the drive to the temp file. I do not subscribe to Prodigy either, but this is at least possible, depending on how it's written. People have been talking about STAGE.DAT files in excess of 900k. I'm sorry, but I don't really think that a 900k file is going to be 'secretly' uploaded in the background while it's drawing windows and menus without you noticing large delays for no apparent reason, unless you are spending 20 hours a day on the system. If someone has an external modem, WATCH THE LIGHTS ON IT! Look to see if a decent amount of data is being sent while you are not doing anything (there will probably be some blips of data every now and then to make sure you're still there and there will probably be ack packets when you're receiving things, but they will be SMALL - not in the kilobyte range.) Better yet, someone should run a TSR to monitor file access and see just when STAGE.DAT is acccessed. Has Prodigy had any solid comments on this? If it's a bug, I'm sure they will be quick to send out a new version.
shafer@pioneer.arc.nasa.gov (Mary Shafer -- OFDD) (05/02/91)
In article <57M001546bv800@amdahl.uts.amdahl.com> esf00@amdahl.uts.amdahl.com (Elliott S. Frank) writes: >> The danger is Prodigy is uploading STAGE.DAT and taking a look at >>your private business. Why? My guess is marketing research, which is >>expensive through legitimate channels, and unwelcomed by you and I. >>The question now is: Is it on purpose, or a mistake? >I was concerned about what the Prodigy software would do back when >it first came out. If you read the shrinkwrap license agreement, by >signing onto Prodigy (and therefore agreeing to the terms and >conditions under which they offer the service), you will find >(paraphrased -- I don't have the text of the agreement in front of me) >that you *have* agreed to allow them to upload *anything that they >want* off your system. If the contents of STAGE.DAT are random >and ignored at this point in time, you have still agreed that >*whatever* they can find on your system can be uploaded and used for >any purpose they desire. > >[I would hope that someone could find their "little yellow box" and >post the text in question -- it would add signal to the signal-to- >noise ratio surrounding this issue.] I just got out my little yellos box. The actual software package says "By opening this container you agree that this PRODIGY software is licensed sloely for use in accessing the PRODIGY service, and may be used or copied solely as instructed for such use. Copying or use for any other purpose is prohibited by law." I also has an 11-page PRODIGY Service Member Agreement, which I am not going to key in. The only relevant thing I can find is "7. Information Supplied by Prodigy by Members" which says that personalization is valuable and is based on data provided by the Member to Prodigy, data derived from the Member's use of the PRODIGY service, and from the Members responses to Prodigy's questions and surveys. Mambers may review.... Prodigy may disclose aggregate (not individually identifiable information regarding Members for any purpose. Individually identifiable data will be used or disclosed by Prodigy only: (1) to personalize the PRODIGY service; (2) as necessary to provide any information, services, or merchandise ..., for billing ...; (3) to make Memeber aware of new areas and features ...; (4) to protect the security of PRODIGY or to protect the rights or property of Prodigy or its Members or Merchants; (5) as require by Law; or (6) in any other manner consistant with this Agreement." "Information regarding a Member's financial holdings, medical history, and credit card number(s), which may be requested in certain specialized areas ..., shall be used or disclosed only for the purposes for which such information is collected, or as required by law. Members' addresses, phone numbers and other relevant information will be provided to Merchants along with orders placed by Members." Nothing about uploading from your disk. They can look at your inputs but they can't rummage through your disk. -- Mary Shafer shafer@skipper.dfrf.nasa.gov ames!skipper.dfrf.nasa.gov!shafer NASA Ames Dryden Flight Research Facility, Edwards, CA Of course I don't speak for NASA "Turn to kill, not to engage." CDR Willie Driscoll
skymaste@brahms.udel.edu (Paul S Masters) (05/02/91)
Interesting, maybe I cold whip up a virus for them to grab. Any one know what
kind of architecture they are using? ;-]
Paul
--
"Let there be light" -- Bomb #20 -- Starship Dark Star
Paul Masters N3IRU (The ham license arived 12/04/90) francis@zaphod.uchicago.edu (05/02/91)
In article <1991May01.165140.22452@vpnet.chi.il.us> louisg@vpnet.chi.il.us (Louis Giliberto) writes: 1) If I were a programmer with a scratch data set that was basically a cache as Prodigy claims they use it, I would not save unused sectors; would you? Yes, if I wanted to be sure of having that space later. 2) If there is *any* information from sectors that have been not deleted, then that is proof positive that the program is picking your files. If it were merely allocated and unused sectors containing data from the last delete, then it would not be able to contain "live" data. Wrong. The file could include data telling the program where to stop reading. I'll have to check my disks. I wonder what they thought when they found like 10 megs worth of Phrack on my hard drive? ;-) What? -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Should five percent appear too small, | | francis@zaphod.uchicago.edu | Be thankful I don't take it all. "Taxman" | \============================================================================/
francis@zaphod.uchicago.edu (05/02/91)
In article <1991May1.215612.2978@ruacad.ac.runet.edu> leng@ruacad.ac.runet.edu (Lud Eng) writes: >In article <1991May1.051734.24594@pcserver2.naitc.com> kdenning@genesis.Naitc.Com (Karl Denninger) writes: >>Since you zeroed all unallocated areas on the drive before you began, there >>is no way the STAGE.DAT file could have gotten private data in it unless the >>software is scanning your fixed disk drive. >> >>This should provide rather conclusive proof one way or the other. >Karl, > As someone else pointed out, this is not conclusive. Due to the way >the Prodigy software works, it may well be trying to buffer to the hard >drive even if it's not installed there. If there is indeed a bug in it, Read the post you're following up to. He said to zero the unallocated areas; that means there shouldn't be any place for them to claim that has actual data in it. -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Should five percent appear too small, | | francis@zaphod.uchicago.edu | Be thankful I don't take it all. "Taxman" | \============================================================================/
Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) (05/02/91)
Quoting Dale Frye's msg of 01 May: >The proper test should be: >1: wipe the hard disk clean -- i.e. low level reformat or wipedisk etc. > Note: This should be done to any and all disks, partitions, etc on the > system. (Or remove them) You can avoid this unpleasant and impractical step if you disable the hard disk, either by setting "NONE" in your CMOS if you have one, or simply disconnecting the cable to the drive (after turning off the power!) Then boot from floppy. Yanking the hard disk controller card if it's separate from the floppy. If you use DOS FORMAT.COM, and not the aftermarket formatters on a floppy then it will be blank. I forgot to say, FORMAT.COM acts very differently on a HARD DISK than it does for a floppy. FOr hard disks, it does NOT do a low-level format. It DOES for floppies. -- Tom Jennings - via FidoNet node 1:125/777 UUCP: ...!uunet!hoptoad!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
jkp@cs.HUT.FI (Jyrki Kuoppala) (05/02/91)
In article <1991May1.215612.2978@ruacad.ac.runet.edu>, leng@ruacad (Lud Eng) writes: > People have been talking about STAGE.DAT files in excess of 900k. I'm >sorry, but I don't really think that a 900k file is going to be 'secretly' >uploaded in the background while it's drawing windows and menus without you >noticing large delays for no apparent reason, unless you are spending 20 >hours a day on the system. If someone has an external modem, WATCH THE >LIGHTS ON IT! Look to see if a decent amount of data is being sent while >you are not doing anything (there will probably be some blips of data every >now and then to make sure you're still there and there will probably be ack >packets when you're receiving things, but they will be SMALL - not in the >kilobyte range.) Better yet, someone should run a TSR to monitor file access >and see just when STAGE.DAT is acccessed. Even if data from the stage.dat file isn't routinely copied to the central system, what proves there isn't a way for the system to do that ? I think someone said software updates are done automatically via the on-line service in Prodigy - if this is true, this makes your files essentially at most as secret and/or secure from malicious tampering as the Prodigy system's security, and means that anyone who has access to the Prodigy system's functionality can do anything to your own system. //Jyrki
purdon@athena.mit.edu (James R. Purdon III) (05/02/91)
In article <1991May1.210740.19958@cec1.wustl.edu> dale@cec2.wustl.edu (Dale Frye) writes: >The proper test should be: > >1: wipe the hard disk clean -- i.e. low level reformat or wipedisk etc. > Note: This should be done to any and all disks, partitions, etc on the > system. (Or remove them) >2: insure all disks are clean!! >3: install test files to look for(if needed). > Do not delete anything. Do not use any disk compressor. > Just copy the files onto the disk. >4: POWER OFF the machine. Wait 10 min. (Yes, 10 MIN!) >5: Turn machine on and verify memory is clear. > Don't do anything except what is listed here. Especially don't go looking > at files. Don't do anything that might bring a file into memory or a disk > buffer. >6: install prodigy >7: run prodigy for a period of time (1 hour or so) >8: NOW check the STAGE.DAT file. I don't think this is necessarily the only valid test. It is a fairly well-known trick to allocate a large file space and write to a single byte at the end of the allocated space (or at the end of each disk block). Most of the systems that I have tried this on don't bother to zero out the allocated space, so that the data which previously occupied the space is still there and can be read. On a multi-user system, this can be considered a security violation, because the data may have belonged to someone else. Of course the presence of "old" data in a file does not necessarily mean it is being read. >An even better test would to be to monitor the data being sent back to Prodigy. This is indeed a better test, but not infallable. If a search is being conducted for specific items (such as the presence of a particular software package), not much needs to be sent back to indicate its presence. Of course, there is always the possibility that the software sends back large amounts of data only when it finds something of interest. Your test situation may fail to provide anything interesting. Lastly, it may be that the software only compromises security when directed to do so. Your test may show nothing because you are not a target. Such are the perils of running "black box" communications software. If the software was distributed as source, which could be compiled by several third-party compilers, users would probably feel more secure. Of course, even source code might contain a cleverly-hidden Trojan, disquised as a normal function. >Dale Frye >Washington University in St. Louis > >P.S. I'm not trying to defend Prodigy. I just hate it when people go off half >cocked. I'm not accusing Prodigy of anything at all. -- Jim Once I was a fetus. Now I am a person. Soon I will be married.
jrbd@craycos.com (James Davies) (05/02/91)
Now that there is some more reliable data on the STAGE.DAT "controversy",
I hope that everyone will settle down and stop accusing Prodigy of
spying on them. It appears that the "stolen personal data" in the
file was, as several people have speculated, just leftover pieces of
deleted files.
However, what nobody seemed to notice in all of this hysteria is that
Prodigy doesn't need to move data into STAGE.DAT in order to "steal" it.
They could just as easily have just directly snatched your client lists
and accounting records without buffering it to another file first (in fact,
a truly sneaky system would have done just that, I would say).
There is a lot of trust necessary to use any network software -- for all I
know, "rn" could be browsing through my files right this minute. However,
there is no reason for me to suspect this, and if it did happen and I
discovered it, I'm sure there would be hell to pay for the person responsible.
Prodigy is in a position to lose quite a bit if they were found to be
illegally spying on their users (can you say "deep pockets"? -- IBM is
the Grand Canyon of deep pockets...) It's inconceivable to me that they would
be pursuing such a risky policy.
jrbd
p.s. I don't expect the Prodigy story to go away at this point, by the way.
This has all the earmarks of a good urban legend...mbrown@testsys.austin.ibm.com (Mark Brown) (05/03/91)
Many People write:
> I *KNEW* Prodigy was E-vil In-car-nate!
Well, I've read Bill Seurer's test, here and in comp.risks.
....and I'm waiting for the lynch mob to start eating crow.
Mark Brown
MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown
Which came first: The Chicken or the Legba?
DISCLAIMER: Any personal opinions stated here are just that.seals@uncecs.edu (Larry W. Seals) (05/03/91)
I believe that sufficient evidence has been presented to convince me
that there's nothing to the STAGE.DAT business. However, in comp.risks
(Vol. 11, Issue 59) Mary Culnan (mculnan@georgetown.edu) presents what
may be the real privacy concern with Prodigy.
In her post, she notes that Prodigy recently ran an ad in DM News (a
weekly newletter for direct marketers) extoling the virtues of it's
on-line direct marketing ability and the availability of it's
subscriber's demographic information.
I think that might be of some concern to the Prodigy users.
**********************************************************************
Larry Seals @ Trailing Edge Software - "When it doesn't have to be
the very best!"
**********************************************************************seurer+@rchland.ibm.com (Bill Seurer) (05/03/91)
I have gotten some interesting feedback on the test that I ran. I thought that others might be interested in some of what I received. I got many messages thanking me for running the experiment. Thank you for responding! I got a really good suggestion for improving the test. Immediately after writing the test files out onto the disk and erasing them (step 7) run a small program that fills up all of unused memory with a pattern different than in any of the files to test if Prodigy is writing uninitialized blocks of memory into the STAGE.DAT file. This would also prevent any leftovers from the files I created from being in memory. I got several comments saying that I didn't have anything on my harddisk. Check my experiment more closely. The only thing I removed from it was Prodigy. It still had 15 meg (or 19 meg, something like that) of other data on it. The "cleaning" process I mentioned writes 0's into all unused disk areas. Several comments said that I probably didn't have anything interesting on my harddisk. Well, I can't prove that. I do have financial data run with a Major Financial package, correspondence and other documents from a Major Word Processor, source for programs, several compilers, games, other comm programs, etc. I suspect that this isn't too far from what many other people have. Several other comments mentioned that Prodigy maybe didn't do it the first time I called. Well, at least one of the posts my experiment was in response to claimed that this had happened. I suppose I could make lots of calls and check each time, but I have better things to do with my life thank you. True, I don't use Lotus XYZ and Wordwhatever and I can't prove that only people with specific packages aren't targeted. Nor can I prove that Prodigy doesn't upload all my files the 906th time that I use it. Heck, I can't prove that QMODEM doesn't secretly upload files when I call other BBS's either (and it doesn't have a handy staging file to look in). What I did prove was that Prodigy DID overlay erased files with STAGE.DAT (or picked them up from memory) and DIDN'T put anything from any not-erased files in STAGE.DAT. Using Occam's razor it is reasonable from the data I did collect to assume that STAGE.DAT is simply overlaying erased files or is being partly filled in from uninitialized memory. This is a satisfactory answer for me (and I would have been terribly upset if they had been uploading data from my disk). It obviously isn't good enough for everyone, but I somehow suspect that there would still be doubters even if they had Prodigy's source in hand, monitored their modem's traffic with some sort of tool, and could prevent parts of their disk from being read. P.S. I plan on trying again this weekend sometime and will incorporate the above suggestion. I'll also see what's changed in STAGE.DAT since then. - Bill Seurer Programming Support IBM Rochester, MN Prodigy: CNSX71A Internet: seurer@rchland.vnet.ibm.com
brad@looking.on.ca (Brad Templeton) (05/03/91)
Folks, this is silly. People are claiming they found their desk calendars or bits of old source code in the stage.dat file. Do you realize how clever the software would have to be to search your files for "interesting" data, upload it, and then, at the other end, process it along with 100,000 users' other "interesting file" And that if they were doing this, they would put it in the stage.dat file, which is a file used for caching material sent from Prodigy to you -- stuff it wants to access more than once. Why store stuff you want to access only once in a cache? Particularly if you were planning something sneakly like this? They're not that smart, and they're not that stupid. Can anybody confirm a case of a pure flopping installation that got fragments of stuff from hard disk files in it? I have heard reports of this, and that would indeed be odd. The rest sounds like paranoia. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
cep@Apple.COM (Christopher Pettus) (05/03/91)
In article <1991May2.160352.8928@craycos.com> jrbd@craycos.com (James Davies) writes: >Now that there is some more reliable data on the STAGE.DAT "controversy", >I hope that everyone will settle down and stop accusing Prodigy of >spying on them. It appears that the "stolen personal data" in the >file was, as several people have speculated, just leftover pieces of >deleted files. [...] >There is a lot of trust necessary to use any network software -- for all I >know, "rn" could be browsing through my files right this minute. However, >there is no reason for me to suspect this, and if it did happen and I >discovered it, I'm sure there would be hell to pay for the person responsible. What I found interesting about this discussion is that people were very, very willing to believe the worst about Prodigy's motives. It's quite true that I have no particular reason to believe that 'rn' is doing anything behind my back ... yet I found it very plausible that Prodigy was doing something slimey. Why? Prodigy's public image has been something of a nightmare of private control of communication. "We own the system, we own the e-mail, we can do whatever it pleases us to do." There is essentially no privacy of any kind on Prodigy, and Prodigy hasn't been shy about using its system administrator powers to censor. Consider what the outcry would be if uunet: (a) implemented a keyword scanner that replaced any "naughty" word with asterix; (b) refused to forward any news or mail which was critical of this or any other uunet policy; (c) stated that if you don't like it, find your own news forwarder. Until electronic mail is made into a common carrier, with the same restrictions and rights that other common carriers have, this problem will continue. -- Christopher Pettus -- Object-Based Systems -- Apple Computer, Inc. MS 3-PK -- (408) 974-0004 -- cep@apple.com -- Link CHRISTOPHE "Etiquette does not recognize competitive bereavement." -- Miss Manners
rjz@martian.UUCP (Robert J. Zepeda) (05/03/91)
One way to check if Prodigy is rummaging thru the files is for someone to use a dos emulator and unix directories. If Prodigy is out rummaging thru files the unix last accessed date should change. If Prodigy is using low level calls to read raw disk sectors then Prodigy should crash. I know HP and IBM make suitable emulators for this experiment. It should also be legal since you are not disassembling code.
leng@ruacad.ac.runet.edu (Lud Eng) (05/03/91)
In article <FRANCIS.91May1220515@magrathea.uchicago.edu> francis@zaphod.uchicago.edu writes: >>>This should provide rather conclusive proof one way or the other. >> As someone else pointed out, this is not conclusive. Due to the way >>the Prodigy software works, it may well be trying to buffer to the hard >>drive even if it's not installed there. If there is indeed a bug in it, >Read the post you're following up to. He said to zero the unallocated >areas; that means there shouldn't be any place for them to claim that >has actual data in it. I did read the post... He just said to zero the unused areas, but leave the hard drive (and all info) accessable. My point was that Prodigy may go ahead and use the hard drive for scratch space if it's available, so zeroing the floppy may not do much. I'm not saying it's particularly likely (or even makes sense offhand to me) that they could accidently read non-prodigy related files off the hard drive and get them mixed into their temp file, but it can't be ruled out as a bug just because it's unlikely. :)
rlemon@unislc.uucp (Richard LeMon) (05/03/91)
Do any Prodigy users have AT&T UNIX source on their computer (for legitimate reasons)? Check your STAGE.DAT. If the UNIX source appears, you might want to let AT&T know. I bet AT&T's lawyers could beat up IBM and Sears lawyers. -- Rick LeMon rlemon@unislc
igb@fulcrum.bt.co.uk (Ian G Batten) (05/03/91)
In article <1991May2.160352.8928@craycos.com> jrbd@craycos.com (James Davies) writes: > > There is a lot of trust necessary to use any network software -- for all I > know, "rn" could be browsing through my files right this minute. However, > there is no reason for me to suspect this, and if it did happen and I > discovered it, I'm sure there would be hell to pay for the person responsible. If you have secure information on a machine and you install software without verifying it, you're asking for trouble. Read the source. Make sure it isn't silently ftp-ing your files to whoever. ian
jonm@microsoft.UUCP (Jonathan MARK) (05/03/91)
In article <Ac7hkIM91EAf4CjIFp@rchland.ibm.com> seurer+@rchland.ibm.com (Bill Seurer) writes: >The Prodigy experiment Thanks for shedding some light on the subject! >The *ONLY* >non-Prodigy thing that I saw was a copy of my environment variables >(COMPSEC, PATH, and PROMPT). I should point out that Prodigy could get a good idea of which commercial software packages are installed, just by uploading the contents of PATH. This could be used for targeted marketing, catching software pirates, or who knows what else. Jonathan Mark uunet!microsoft!jonm [not speaking for my employer]
rogue@cellar.UUCP (Rogue Winter) (05/04/91)
mbrown@testsys.austin.ibm.com (Mark Brown) writes: > Many People write: > > I *KNEW* Prodigy was E-vil In-car-nate! > > Well, I've read Bill Seurer's test, here and in comp.risks. > > ....and I'm waiting for the lynch mob to start eating crow. > > Mark Brown > MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown > Which came first: The Chicken or the Legba? > DISCLAIMER: Any personal opinions stated here are just that. I hate to sully Bill Seurer's reputation, but I am awaiting a second, independent, confirmation of his tests. Mr. Seurer seems like a decent and competent person, but the fact that he works for IBM presents a potential conflict of interest. Rogue Winter | "The truth knocks on the door and you say, rogue@cellar.uucp | "Go away, I'm looking for the truth," and so uunet!cellar!rogue | it goes away. Puzzling." Cellar 215/3369503 | -Robert Pirsig (quoted in Zen_To_Go, Jon Winokur)
kdenning@genesis.Naitc.Com (Karl Denninger) (05/04/91)
In article <1991May3.071620.14140@ruacad.ac.runet.edu> leng@ruacad.ac.runet.edu (Lud Eng) writes: >In article <FRANCIS.91May1220515@magrathea.uchicago.edu> francis@zaphod.uchicago.edu writes: >>>>This should provide rather conclusive proof one way or the other. > >>> As someone else pointed out, this is not conclusive. Due to the way >>>the Prodigy software works, it may well be trying to buffer to the hard >>>drive even if it's not installed there. If there is indeed a bug in it, > >>Read the post you're following up to. He said to zero the unallocated >>areas; that means there shouldn't be any place for them to claim that >>has actual data in it. > >I did read the post... He just said to zero the unused areas, but leave >the hard drive (and all info) accessable. My point was that Prodigy may >go ahead and use the hard drive for scratch space if it's available, so >zeroing the floppy may not do much. I'm not saying it's particularly >likely (or even makes sense offhand to me) that they could accidently read >non-prodigy related files off the hard drive and get them mixed into their >temp file, but it can't be ruled out as a bug just because it's unlikely. :) Nonsense. They can't be doing that unless: 1) They're bypassing DOS' file access mechanisms, in which case I think the case can be made that their software is negligently designed. 2) They are deliberately opening files they have no business being in. If you have wiped all unallocated disk space on the fixed disk, and don't run anything else between the wipe and the Prodigy install/run, then there is no way for the data space they use to get your private data in it. (I am assuming you are smart enough to turn off disk caches, etc. to eliminate the possibility of a poorly-designed disk cache program.) If they're reading from data space assigned to some file other than their own or on the free FAT bitmap, then they're potentially guilty. If they're not, then they are clean. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
rdippold@cancun.qualcomm.com (Ron Dippold) (05/04/91)
In article <57M001546bv800@amdahl.uts.amdahl.com> esf00@amdahl.uts.amdahl.com (Elliott S. Frank) writes: >I was concerned about what the Prodigy software would do back when >it first came out. If you read the shrinkwrap license agreement, by >signing onto Prodigy (and therefore agreeing to the terms and >conditions under which they offer the service), you will find >(paraphrased -- I don't have the text of the agreement in front of me) >that you *have* agreed to allow them to upload *anything that they >want* off your system. If the contents of STAGE.DAT are random >and ignored at this point in time, you have still agreed that >*whatever* they can find on your system can be uploaded and used for >any purpose they desire. The Prodify license agreement states that if they steal your data, you can only hold them liable for the cost of service, i.e., your subscription cost. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
louisg@vpnet.chi.il.us (Louis Giliberto) (05/04/91)
In article <57M001546bv800@amdahl.uts.amdahl.com> esf00@amdahl.uts.amdahl.com (Elliott S. Frank) writes: >(paraphrased -- I don't have the text of the agreement in front of me) >that you *have* agreed to allow them to upload *anything that they >want* off your system. If the contents of STAGE.DAT are random >and ignored at this point in time, you have still agreed that >*whatever* they can find on your system can be uploaded and used for >any purpose they desire. > >[I would hope that someone could find their "little yellow box" and >post the text in question -- it would add signal to the signal-to- >noise ratio surrounding this issue.] >-- >Elliott Frank ...!{uunet,sun}!amdahl!esf00 (408) 746-6384 > or ....!esf00@amdahl.com > >[the above opinions are strictly mine, if anyone's.] I don't have the shrinkwrap sticker or whatever it was, but I do have the PRODIGY(tm) Service Member Agreement. It doesn't say anything like that. What it *does* say (and this is rather interesting in light of their recent actions) is this: (Section 8, p. 9 under the heading: Information Supplies by Members to other Members through the PRODIGY Service) Prodigy reserves the right to review and edit any material submitted for display or placed on the PRODIGY service, excluding private electronic messages. [In bold] Messaging. Prodigy will not intentionally [ha!] inspect the contents of private electronic messages sent by one member to an identified addressee, or disclose such contents to other than the sender or an intended recipient, without the consent of the sender or of the intended recipient, unless required to do so by law. (this was from the July 1, 1989 printing) So if those guys were sending bulk junk mail to other users, how would Prodigy know without looking at it? And, if they use some form of electronic sentry to sniff out key words such as "bomb," is that not an inspection? This is off of the subject, but I just noticed it when I looked at the agreement. I don't see how they could justify their action without admitting a breach of contract or license or whatever you call it. Does anyone else see this, or am I looking at things sideways? Louis Giliberto (louisg@vpnet.chi.il.us) -- --------------------------------------------------------------------------- ! "As above, so below; as below, so above" -- The Kybalion ! ! "I don't trust him; he has dark hair" -- My girlfriend's mother ! ! "So I'm stupid; what's your point?" -- Me !
jcm@cbnewsc.att.com (jeffrey.c.martin) (05/04/91)
Found this stuff on Prodigy this evening. Posted without permission
or comment. (Personally, I believe the Prodigy folks on this issue.)
----------------------
PRODIGY(R) interactive personal service 05/03/91 10:49 PM
The Privacy of Member Information
Some members have asked recently about the privacy of
information they store on their personal computers, as it
relates to their use of the PRODIGY service. I felt this
subject was important enough to inform all our membership
about it.
Privacy of a member's personal information is of primary
importance to us. We know that our members consider this
kind of information proprietary, and so do we.
A recent, unsubstantiated and incorrect newspaper report
suggested that members' personal information--unrelated to
their use of the PRODIGY service--is being transmitted to
our host computers from our members' computers. This is
simply not true. It never has been.
We have no central computers that access private computer
files. The PRODIGY service software does not read, collect,
or transmit to the Prodigy Services Company any information
or data that is not directly connected with your use of the
service.
Member privacy has always been a top priority for Prodigy.
Your use of the service can continue with the highest
confidence that your personal data will not be accessed
by us.
Ted Papes
President, Prodigy Services Company
May 2, 1991
You may have recently read about data from other files
appearing inside the STAGE. This is a harmless side effect
of DOS file operations and the process by which the PRODIGY
STAGE is created. On the following screens you'll find a
discussion of your STAGE.DAT file.
If you're interested in the details, please read on. I think
you'll be more comfortable once you've read the facts.
Harold Goldes (CBXH97A)
Technical Editor, PRODIGY Star
The occurrence of "non-PRODIGY" data within the disk space
used by the STAGE has prompted some to speculate that
PRODIGY can gain access to that information or other
information on a member's hard disk. Here are the facts:
The PRODIGY software does not examine a member's
hard disk as a whole. It does not read files created
by other software. It does not read data other than
its own. It does not upload files to do this. The
PRODIGY software confines its file operations to a
limited and well defined section of your disk: The
PRODIGY directory.
When you install the PRODIGY software on your computer we
create a unique file on your floppy or hard disk:
STAGE.DAT. The STAGE (or STAGE.DAT as it appears in your
directory or folder) is a "container". What does it hold?
The STAGE contains frequently used information and
instructions that make up PRODIGY applications
("applications" refers to the individual activities
available to you on the service; FIND and the Movie Guide,
are examples).
Placing portions of applications on the STAGE (and not in
other more remote parts of our network) puts them close to
you. Without a storage structure like the STAGE, key
components of an application would be sent to your computer
whenever you visited the application. This adds
transmission time. Placing them on your computer saves
time. When you install the DOS version of the PRODIGY
software, you have the choice of creating the STAGE in a
range of sizes from about 160Kb to 950Kb. For Macintosh
users there is one size: 200,064 bytes.
If a member installs to a floppy disk(s), the STAGE may
vary in size. These intermediate sizes depend on several
factors including the capacity of the disk and the version
of DOS. Once it's been created, the STAGE never changes its
size. But the date and time stamp on the STAGE does change
and is updated at the end of every PRODIGY session. This
reflects the fact that during your session we read PRODIGY
content from it and write updated PRODIGY content to it.
To improve performance during your session, certain
frequently used parts of the service are always "staged". A
larger STAGE, should you choose one, permits a growing
inventory of applications to reside on your computer.
Because our software adapts itself to you, some of the
content you use regularly can become staged.
Whenever and wherever you logon to the Prodigy service, we
check to see if you've got the latest versions of a variety
of programs and data that reside in the STAGE. If not we
send you what you need. You don't have to ask for new
disks. And you don't have to reinstall.
Some members use RAMdisks to improve performance. A RAMdisk
is a "disk drive" made from memory (RAM) not from
mechanical parts. It's faster than its physical counterpart
but can more easily lose data. For that reason we don't
recommend using a RAMdisk. However here's something to
keep in mind if you're going to do it anyway. A RAMdisk is
volatile. If you turn your machine off, the information
stored on the RAMdisk evaporates. As you may be receiving
an update each time you sign on, be sure to save the
updates. To do this, copy the file named STAGE.DAT back to
your PRODIGY directory before you hit that switch.
Members often ask about the need to update the PRODIGY
software on their PRODIGY installation disks. There is no
need to update the original installation disks. Use those
disks (or backup copies) to install the software on any
computer you use to sign on to the PRODIGY Service. Then,
when you sign on for the first time, the service will
automatically update the PRODIGY software.
Suppose you have two computers and use them both to access
the service. Let's say you use one more frequently than the
other. Each of your computers will get updates, if needed,
when you use them. The machine used most frequently will be
updated steadily (almost imperceptibly) by increments. When
you use the other machine, you might notice a delay during
logon because it's receiving a greater amount of updated
information all at once.
There's a practical limit to the kinds of changes we can
make automatically to an existing version of the software.
If you've ever tried adding air conditioning to a car you
bought without it, you'll understand this; sometimes it's
best to start over with the really useful options built in.
So over time when we make extensive improvements to the
PRODIGY software, we may send you a new set of disks.
From time to time members using the DOS version of the
PRODIGY software see information from "other" (non-PRODIGY)
applications in the disk space used by STAGE.DAT.
Data from non-PRODIGY files is never actually part
of STAGE.DAT. More importantly it is never accessed or
uploaded by the PRODIGY software. There are two ways in
which extraneous data can appear in the STAGE. In the first
case, the data was originally located in areas of the hard
disk once used by other software. At one point in the past,
this data was erased.
When you erase a file, PC-DOS or MS-DOS (the operating
system for personal computers) does not remove the file's
contents from your disk. Instead it only marks the space
used by the file as now "available for use". In doing this,
it gives other software permission to reuse that space.
Until that space is used by its new owner, the old data
remains. This is why certain "unerase" software packages
can recover accidentally deleted files. When you install the
PRODIGY software, it asks DOS to supply disk space for the
STAGE.DAT file. Depending on the size of the STAGE you
choose, this is usually a request for anywhere between
160Kb to 1 Mb.
DOS then checks its inventory of available disk sectors,
finds the space and reserves it for its new owner:
STAGE.DAT. But DOS leaves any old data in that space
intact. Please keep in mind that DOS simply supplies the
sectors we request (as long as they are available) and does
not touch their original contents. Next, our install
program starts filling the space with blocks of PRODIGY
information. The PRODIGY install program does not erase any
old data because to do so would appreciably lengthen the
install process. As a result, old "erased" data may appear
in unused space following the blocks (where it's more
noticeable) as well as in smaller areas that occur within
the blocks (for more on this see "HOW WE USE SPACE" below).
If you chose a large STAGE (anything from 250Kb to 950Kb),
chances are that at first, a portion of it will be unused.
It is likely that some of the space within that unused
portion was used by other software at one time. If so what
you'll see if you examine that area will be "leftovers".
Over time, the PRODIGY software will write blocks of
information to the STAGE replacing whatever is there.
Please keep in mind that the PRODIGY software can only
recognize the blocks of information that it puts into
STAGE.DAT itself. It does not read, collect, process or
transmit "non-PRODIGY data". All disk space containing such
data is treated as empty.
Like most major software, to ensure compatibility and
reliability when creating, reading and writing files, the
PRODIGY software employs standard "services" provided by
your computer's operating system. By viewing the STAGE with
certain software tools, members have observed information
from non-PRODIGY applications. However the PRODIGY software
can neither see this information nor use it. To the PRODIGY
software this space is considered "empty" and available for
storing PRODIGY data. Over time, as you use the service,
this "empty" space is covered by PRODIGY content.
When we store data in the STAGE, we do it via DOS in blocks
of a specific size. Let's say that size is 100 bytes. If we
store a 120 byte "object" then we use two blocks (or 200
bytes of storage). What we store takes up all of the first
block but only 20 bytes of the second block. What happens
to the remaining 80 bytes of the second block? Whatever was
there originally remains. If that block was built on a
previously used sector, 80 bytes of "old" data will be seen.
There's a second way in which extraneous data may appear
within the disk space used by the STAGE. When the STAGE is
being created, certain "control" areas may incorporate
information that was in your computer's memory (RAM). These
areas are used by the STAGE itself to keep track of its own
contents. This extraneous data may include non-erased data
or data from another disk. You may observe the names of
directories, your PATH, or information from the software
you were using just before you installed the PRODIGY
software. To minimize the occurrence of this data within
the STAGE, just turn your PC off, wait 15 seconds then turn
it on again before installing the PRODIGY software.
In short, extraneous information can appear in the disk
space used by the STAGE and yet not actually be part of it.
The appearance of this "non-PRODIGY data" is a side effect
of DOS file operations or the process by which the STAGE is
created. But, like a bottle containing oil and water, this
disk space STAGE can contain both PRODIGY and non-PRODIGY
data which are different and remain separate.
The PRODIGY software does not read information created by
other software. And it does not read data other than its
own. Nevertheless some members have tried to delete
non-PRODIGY data from the STAGE by using file editors.
Modifying the contents of the STAGE file will do more harm
than good. To maintain the integrity of the STAGE, we use
special techniques that detect alteration of its contents.
Changing the contents of the STAGE with a software tool
(like an editor) will render the STAGE unusable. You'll
have to reinstall the PRODIGY software. For those members
who are concerned by even the appearance of extraneous data
within the STAGE, we are preparing a utility to eliminate
non-PRODIGY data from the STAGE.
No extraneous information appearing within the disk space
used by STAGE.DAT is known to or used by PRODIGY.
The only information used by the PRODIGY software is what
is needed for the installation and operation of the
software.dave@kharma (05/04/91)
leng@ruacad.ac.runet.edu (Lud Eng) writes: > In article <FRANCIS.91May1220515@magrathea.uchicago.edu> francis@zaphod.uchic > >>>This should provide rather conclusive proof one way or the other. > > > I did read the post... He just said to zero the unused areas, but leave > the hard drive (and all info) accessable. My point was that Prodigy may > go ahead and use the hard drive for scratch space if it's available, so > zeroing the floppy may not do much. I'm not saying it's particularly > likely (or even makes sense offhand to me) that they could accidently read > non-prodigy related files off the hard drive and get them mixed into their > temp file, but it can't be ruled out as a bug just because it's unlikely. :) Having just checked out a client's file area(s), I am relatively certain in my mind that Prodigy is, in fact, invading the users privacy. Here are some reasons why: I was able, through very *minor* hex tweaking, to create a spreadsheet file from data contained within STAGE.DAT in less than an hour, and I am not that skilled in such things. I could actually see the numbers! Also, no one has questioned the issue of proprietary software rights. My client has a registered user's copy of Brown Bag Software's very nice menuing program, Power Menu. I was able to find a substantial amount of the text and error messages from this software within STAGE.DAT near the end of the file. I wonder what Brown Bag would say if they knew this was happening? To what end is STAGE.DAT being used? I asked an unknown individual at Prodigy about this, and I was rudely and immediately hung up on. When I called back, asserting my right to protect my client from what I perceived as a potential security problem, I was again told to "mind my own business" and the individual hung up on me without comment. If there is not such an invasion taking place, why are the Sears representatives being such a butt? What I have instructed my entire client base to do, if they insist upon running Prodigy, is to create a boot diskette, carefully avoiding any CONFIG.SYS references to drivers or other programs on Drive C and use that diskette to boot their system, prior to running Prodigy, which also is run from a diskette. I do wish to note that, in the final analysis, STAGE.DAT under the methodology just described, shrank from a file size of nearly 600 K (!!) to less than 3 K in file size. A properly skeptical and logical mind might ask, why does this smaller file size occur, if they are not storing data off the hard disk... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - isc-br!tau-ceti!dogear!kharma!dave [dave@kharma] Dave Laird, SysOp: kharma The Computer Concern, Springdale, WA 258-7109 or 1-800-786-7109 kharma: 509-233-8474 (Local from Spokane Area) 24hrs 1200-14400 (HST)
gardner@ux1.cso.uiuc.edu (Mike Gardner) (05/05/91)
louisg@vpnet.chi.il.us (Louis Giliberto) writes: >Prodigy reserves the right to review and edit any material submitted for >display or placed on the PRODIGY service, excluding private electronic >messages. >[In bold] Messaging. >Prodigy will not intentionally [ha!] inspect the contents of private electronic >messages sent by one member to an identified addressee, or disclose such >contents to other than the sender or an intended recipient, without the consent >of the sender or of the intended recipient, unless required to do so by law. >So if those guys were sending bulk junk mail to other users, how would >Prodigy know without looking at it? And, if they use some form of electronic >sentry to sniff out key words such as "bomb," is that not an inspection? Notice that Prodigy says "sent by one member to AN identified ADDRESSEE". That's one person. The mail could still be reasonably private, but forwarding programs could flag and hold mail that was broadcast to a MANY people or placed in public areas without examining the contents of any message or violating their agreement. Anything you put on the outside of an envelope (mail headers) is not under the same protection as what is inside. >Does anyone else see this, or am I looking at things sideways? mmmmm About 45 degrees to the right... I think Prodigy bungled their email policy and I don't like what they did either, but if you join the club, you play by their rules. There are better places to get better service. mgg ****************************************************************** .+|+, CCC SS OO +-*-+ C S O O NETWORKING: ubiquitous, demanded, `+|+' + C S O O demanding, misunderstood. +-##-+ CCC SS OO +-# #-+ University of Illinois, Computing Services Office +-##-+ 1304 W Springfield, Urbana, Il 61801 + .+|+, Michael G. Gardner, Assistant Director, 1122 DCL +-*-+ (217)244-0914 gardner@ux1.cso.uiuc.edu `+|+' FAX (217)244-7089 ******************************************************************
multics@acm.rpi.edu (Richard Shetron) (05/06/91)
In article <1991Apr30.225133.8165@craycos.com> jrbd@craycos.com (James Davies) writes: > <stuff deleted about using blank diskettes > >Question: was he using an unused disk, or did he just reformat an old >one, assuming that it would be wiped clean? > This was done with a brand new diskette that was erased/reformatted bye the sysop of a local BBS and this type of stuff showed up. I don't remember the full details (I can upload them here if desired), but he monitered the communications with a second computer to confirm that personal data was being uploaded by prodigy from the hard drive even running off the floppy. (I may not remember all the details, but he did make sure there was no way prodigy could get the data without going out to his HD to get it.) -- A good bureaucracy is the best tool of oppression ever invented. Richard Shetron USERFXLG@mts.rpi.edu multics@rpi.edu
multics@acm.rpi.edu (Richard Shetron) (05/06/91)
In article <565g7df@rpi.edu> multics@acm.rpi.edu (Richard Shetron) writes:
Please ignore the article I posted above. There are several typing errors
that I did not catch at the time of posting that change the meaning of
the article. The cancel article has not worked.
--
A good bureaucracy is the best tool of oppression ever invented.
Richard Shetron USERFXLG@mts.rpi.edu multics@rpi.edurdippold@maui.qualcomm.com (Ron Dippold) (05/06/91)
In article <1991May2.160352.8928@craycos.com> jrbd@craycos.com (James Davies) writes: >Prodigy is in a position to lose quite a bit if they were found to be >illegally spying on their users (can you say "deep pockets"? -- IBM is >the Grand Canyon of deep pockets...) It's inconceivable to me that they would >be pursuing such a risky policy. Yeah, you'd think that it would be really stupid for a service like Prodigy to engage in information theft, wouldn't you? Infoworld Magazine reports that Soap Opera Now, a weekly newsletter covering TV soaps, has sued Prodigy Services Company. Apparently, Prodigy started an online soap opera service last August and a number of stories from Soap Opera Now began appearing online verbatim. Michael Kape, editor of the 6500 subscriber weekly arranged for publication of a totally fictitious story with the consent of the story's subject. According to Kape, it appeared on the Prodigy service with virtually the same wording. The lawsuit seeks damages of $38 for each of Prodigy's 700,000 subscribers. Prodigy refused to comment on the story. GEnie and CompuServe both have software that does approximately the same thing. The difference being that GEnie and CompuServe haven't pursued a policy of arrogance and apparent unconcern towards the concerns of their users as Prodigy has. It's trust, and Prodigy doesn't have it. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
skymaste@brahms.udel.edu (Paul S Masters) (05/07/91)
All they have to do is place an EOF charactor where there data stops, and have
there software respect it. Since they don't implement such a simple solution,
then I guess I just have to wonder about there stand on privacy.
Paul
--
"Let there be light" -- Bomb #20 -- Starship Dark Star
Paul Masters N3IRU (The ham license arived 12/04/90) seurer+@rchland.ibm.com (Bill Seurer) (05/07/91)
Excerpts from netnews.comp.org.eff.talk: 3-May-91 Re: Prodigy charged with in.. Rogue Winter@cellar.UUCP (955) > I hate to sully Bill Seurer's reputation, but I am awaiting a second, > independent, confirmation of his tests. Mr. Seurer seems like a decent and > competent person, but the fact that he works for IBM presents a potential > conflict of interest. I knew that this eventually would come up. If I wanted to hide the fact that I work for IBM, I could have easily loaded my message from Fidonet. I have read several posts from other people who basically ran the same sort of test that I did. Isn't that enough proof for you? - Bill Seurer Programming Support IBM Rochester, MN Prodigy: CNSX71A Internet: seurer@rchland.vnet.ibm.com
jms@tardis.Tymnet.COM (Joe Smith) (05/07/91)
In article <21151@brahms.udel.edu> skymaste@brahms.udel.edu (Paul S Masters) writes: >All they have to do is place an EOF charactor where there data stops, and have >there software respect it. Since they don't implement such a simple solution, >then I guess I just have to wonder about there stand on privacy. From what I've read of their rebuttal, that is EXACTLY what they are doing. Near the beginning of the file is a count of bytes that have valid data, and they say that their software does NOT access anything past that point. Putting a single EOF character (Control-Z) in a binary file does not prevent access to the rest of the file. As long as the blocks are allocated, they are accessable. The place where Prodigy goofed is where they pre-allocate the space for STAGE.DAT. Before they write any data into the newly created file, they should have filled all blocks of the file with dummy data, such as ^Z. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
seurer@rchland.vnet.ibm.com (Bill Seurer) (05/07/91)
Excerpts from netnews.comp.org.eff.talk: 4-May-91 Re: Prodigy charged with in.. Louis Giliberto@vpnet.ch (2565) > So if those guys were sending bulk junk mail to other users, how would > Prodigy know without looking at it? And, if they use some form of electronic > sentry to sniff out key words such as "bomb," is that not an inspection? > This is off of the subject, but I just noticed it when I looked at the > agreement. I don't see how they could justify their action without admitting > a breach of contract or license or whatever you call it. > Does anyone else see this, or am I looking at things sideways? It could be that one of the recipients complained about the contents of the message(s). If you get an "objectionable" message, Prodigy asks that you notify them and they will "take care of it." I assume at that point they go look at the message (which is OK 'cause you asked them to). Since every message has the distribution list of who it was sent to at the bottom, if one recipient complained, Prodigy would know the contents AND that it was "bulk" mailed. I can't find the post that the above poster references so I'm not sure of the details. The only time I ever considered doing this was just before they started charging for over 30 messages/month and some jerk sent me (and dozens of others) about a hundred messages. I was just about to complain when I noticed that the time on the messages was just after the "free" cutoff. The guy had forgotten that the cutoff was at midnight Eastern time. I sure hope he enjoyed the bill! :-) - Bill Seurer Programming Support IBM Rochester, MN Prodigy: CNSX71A Internet: seurer@rchland.vnet.ibm.com
leng@ruacad.ac.runet.edu (Lud Eng) (05/07/91)
>Nonsense. > >They can't be doing that unless: > >1) They're bypassing DOS' file access mechanisms, in which case I think > the case can be made that their software is negligently designed. > >own or on the free FAT bitmap, then they're potentially guilty. > As I said, it makes no sense WHY they would do it, but you can't just rule it out! Also, I'm not sure... Is it actually illegal for them to read any file on the system with their program as long as they don't do something like upload it without you knowing? I still haven't seen anyone who has actually looked to see if the contents of this file are being uploaded or not.. just that the file exists.
stokes@churchy.gnu.ai.mit.edu (Perry Stokes) (05/07/91)
In article <1991May6.225049.10812@ruacad.ac.runet.edu> leng@ruacad.ac.runet.edu (Lud Eng) writes: >Also, I'm not sure... Is it actually illegal for them to read any file on >the system with their program as long as they don't do something like upload >it without you knowing? I still haven't seen anyone who has actually looked >to see if the contents of this file are being uploaded or not.. just that the >file exists. Nope. It is my understanding that all legal rights are given up when you sign on to PRODIGY for the first time. I believe this is explained in the user agreement. Perry -- Perry Stokes | Despite the fact it kills millions of stokes@ai.mit.edu | people each year, being stupid isn't 512-836-2163 | against the law
dave@kharma (05/22/91)
jerry@matt.ksu.ksu.edu (Jerry J. Anderson) writes: > jrbd@craycos.com (James Davies) writes: > > > If you're serious about it, start with a wipedisk. Then install a > few files without erasing any. That way, the only non-wiped areas > on the disk will be currently used for files. If STAGE.DAT and > CACHE.DAT don't come up empty, you'll know something fishy is going > on. > I did that with a client's system. I went one step further, in the interest of scientific <*> correctness. I used a bulk formatter, and electro=magnetic gadget that completely jumbles anything already on the disk. <It also eliminates *any* possibility of diskette born virusi, BTW>. Then I did a standard format and install the Prodigy apps on the clean diskette. I furthermore verified the empty sectors of the diskette before I started to make absolutely certain that they were empty. After *ONE* log-in at Prodigy, the STAGE.DAT had pieces of a spreadsheet in Drive C:, all the options from Prodigy which my client had chosen that night, and an entire <mostly> copy of the tree on Drive C:... I dunno about you, but I won't use Prodigy again. It's a marketing tool, to be sure, but in the wrong hands it could be Big Brother. Neither you nor I are standing at Rears and Soebucks to make certain that doesn't happen. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - isc-br!tau-ceti!dogear!kharma!dave [dave@kharma] Dave Laird, SysOp: kharma The Computer Concern, Springdale, WA 258-7109 or 1-800-786-7109 kharma: 509-233-8474 (Local from Spokane Area) 24hrs 1200-14400 (HST)
jrbd@craycos.com (James Davies) (05/22/91)
In article <7msB32w164w@kharma.UUCP> dave@kharma writes:
{installing Prodigy on a bulk-erased disk left parts of a spreadsheet
in STAGE.DAT, therefore Prodigy is snarfing personal information}
Sigh. This rumor apparently isn't going to go away, is it?
Did you clear the memory of your machine first (by doing a power-off
reboot)?
Why would anyone want part of a spreadsheet, anyway? Why wasn't the whole
thing there?
I think that remembering Occam's Razor would be a good idea at this point.
I'll repeat a point I made a few weeks ago: Prodigy could transfer your
stuff directly from the original file. Why would they bother to put it in
STAGE.DAT first?dave@kharma (05/23/91)
jrbd@craycos.com (James Davies) writes: > In article <7msB32w164w@kharma.UUCP> dave@kharma writes: > > {installing Prodigy on a bulk-erased disk left parts of a spreadsheet > in STAGE.DAT, therefore Prodigy is snarfing personal information} > > Sigh. This rumor apparently isn't going to go away, is it? Not until my clients stop asking embarassing questions, no. After all, I was the person who recommended Prodigy so highly. <eeek!> > > Did you clear the memory of your machine first (by doing a power-off > reboot)? > You bet. I even waited a good five minutes, not being altogether too certain how long transient voltage would remain active in the computer after power-down took place. > Why would anyone want part of a spreadsheet, anyway? Why wasn't the whole > thing there? I haven't the foggiest idea. I'm not even certain why so little valid information could be of use. But it *is* in there, including the graphic driver (95% intact) for the client's HP Paint Jet printer. > > I'll repeat a point I made a few weeks ago: Prodigy could transfer your > stuff directly from the original file. Why would they bother to put it in > STAGE.DAT first? Damned good question. I feel, like you, that much of this affair is overblown beyond true proportions. There are some credibility problems, though, that refuse to go away. People who complain are summarily cut off from the service, at least those who are strident. And the response from Prodigy? A lackluster affair if I ever saw one. I cannot state for a fact that Prodigy is stealing client information, but I cannot safely recommend that anyone use it, either. It is either a very slick method of marketing, including the use of STAGE.DAT to gather information about the user's system, or it could be ??????? There are still a lot of questions, and Prodigy is very close-lipped about the whole mess. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - isc-br!tau-ceti!dogear!kharma!dave [dave@kharma] Dave Laird, SysOp: kharma The Computer Concern, Springdale, WA 258-7109 or 1-800-786-7109 kharma: 509-233-8474 (Local from Spokane Area) 24hrs 1200-14400 (HST)
greg@hoss.unl.edu (Lig Lury Jr.) (05/25/91)
dave@kharma writes: >jrbd@craycos.com (James Davies) writes: >>Why would anyone want part of a spreadsheet, anyway? Why wasn't the whole >>thing there? >I haven't the foggiest idea. I'm not even certain why so little valid >information could be of use. But it *is* in there, including the graphic >driver (95% intact) for the client's HP Paint Jet printer. >>I'll repeat a point I made a few weeks ago: Prodigy could transfer your >>stuff directly from the original file. Why would they bother to put it in >>STAGE.DAT first? >Damned good question. I feel, like you, that much of this affair is overblown >beyond true proportions. One reason why bits and pieces would be targeted would be that you would get a more various data. Grabbing an entire file when only parts of it may give you enough information for database purposes would be a waste of transfer time. Grabbing portions of several files gets you more information. There is the possibility that the program is exploiting the fact that the disk sectors do still contain deleted information. How hard would it be for them to tell the system where EOF was? >isc-br!tau-ceti!dogear!kharma!dave [dave@kharma] Dave Laird, SysOp: kharma > The Computer Concern, Springdale, WA 258-7109 or 1-800-786-7109 > kharma: 509-233-8474 (Local from Spokane Area) 24hrs 1200-14400 (HST) Just putting out ideas. I'm not familiar with the OS being referred to in this discussion. If you had created a new file of one sector in size, deleted it, and then created a new file of 0 length, would you have your file back in this situation? -- /// ____ \\\ "The major problem--one of the major problems, for there are | |/ / \ \| | several--one of the many major problems with governing \\_|\____/|_// people is of whom you get to do it, or more to the greg \_\\\/ hoss.unl.edu point, who gets people to let them do it to them."
tau-ceti (05/27/91)
greg@hoss.unl.edu (Lig Lury Jr.) writes: > dave@kharma writes: > >jrbd@craycos.com (James Davies) writes: > > >>Why would anyone want part of a spreadsheet, anyway? Why wasn't the whole > >>thing there? > > >I haven't the foggiest idea. I'm not even certain why so little valid > >information could be of use. But it *is* in there, including the graphic > >driver (95% intact) for the client's HP Paint Jet printer. > > >>I'll repeat a point I made a few weeks ago: Prodigy could transfer your > >>stuff directly from the original file. Why would they bother to put it in > >>STAGE.DAT first? > > >Damned good question. I feel, like you, that much of this affair is overblow > >beyond true proportions. > > One reason why bits and pieces would be targeted would be that you would > get a more various data. Grabbing an entire file when only parts of it > may give you enough information for database purposes would be a waste of > transfer time. Grabbing portions of several files gets you more > information. > > There is the possibility that the program is exploiting the fact that > the disk sectors do still contain deleted information. How hard would it > be for them to tell the system where EOF was? > > >> Just putting out ideas. I'm not familiar with the OS being referred to in >> this discussion. If you had created a new file of one sector in size, >> deleted it, and then created a new file of 0 length, would you have your >> file back in this situation? > Well, I did some considerable homework this weekend, including a trip to a research library. It *is* entirely possible that what has happened is that Prodigy's STAGE.DAT has picked up whatever was in RAM memory, at the time, as one user has suggested. It is also possible that the disk sectors contained deleted data, too. After nearly a whole day spent reading voluminous garbage, I think I have a handle on what has happened. Prodigy blew it, not from a point of spying on people, but on stifling an honest, open response to the public's concern. In other words, the worst thing they did wrong was a PR gaffe of monstrous proportions. There are other reasons for my decision...I will list them briefly: 1. During a recent Prodigy session, other than my keystrokes, my modem's SD light never flickered once. If they were taking data off my system, wouldn't that require that I *send data* out? 2. When I did a cold boot, using a system diskette, without the .BIN file my hard disk requires, and used a new STAGE.DAT that I personally checked, nothing in STAGE.DAT changed. However, when I booted from the hard disk, deliberately loaded Wordperfect, and then exitted, LO and behold, I had pieces of the Wordperfect text in the STAGE.DAT...from RAM memory. 3. I repeated the above exercise several times, and never saw any indication that my terminal was sending data out, except during the times when I was typing responses to Prodigy's prompts. That isn't to say I don't think that Prodigy *COULD* be doing something funky in the past. There are a *lot* of unanswered questions left over from when the fiasco first started. I will always wonder what they really had in mind with STAGE.DAT, probably never will really trust them, and do not recommend that anyone with sensitive data on their hard disk call them without taking precautions. Gee, does this make me sound paranoic? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - isc-br!tau-ceti!dogear!kharma!dave [dave@kharma] Dave Laird, SysOp: kharma The Computer Concern, Springdale, WA 258-7109 or 1-800-786-7109 kharma: 509-233-8474 (Local from Spokane Area) 24hrs 1200-14400 (HST)
tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) (05/28/91)
Umm ... Prodigy stealing my spreadsheets would be certainly devious,
but totally useless. Random data is just that -- random.
A more useful thing would be a quick scan & profile of filenames on
the hard disk -- 123.COM, WS.EXE, LOTUS.EXE, WORD.EXE. You could with
some certainty determine what products a given system has simply by
getting a list of the filenames (ie. WORD.EXE plus the zillion system
and font files, that sort of thing. WORD.EXE by itself could mean
anything.)
MSDOS system hackers would be the ones to talk to. I used to have a
tool (a bit dangerous) that listed on the screen each and every system
call -- file open "FOO", read file 1, close file ... directory open
"\BIN", that sort of thing ...
I am *NOT* implying that Prodigy does this, simply that this is far
more "interesting" than "stealing" my checkbook spreadsheets, which is
silly.
--
tom jennings - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!111!tom.jennings
INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORGgast@lanai.cs.ucla.edu (David Gast) (05/28/91)
I have never used Prodigy so I can't comment from personal experience, but a couple points seem clear. Prodigy is probably not taking information off one's hard disk. But that does not mean that they could not if they wanted to. I understand that they can download updates to their software to your disk. Clearly, if they can write, they can read. Further, I would be very concerned about some program writing new files to my disk without my knowledge. What if I don't want the new larger program? What if I am running another program (TSR or otherwise) that violates some rule that Prodigy expects my computer to obey and the update causes serious problems? Why does Prodigy take so much more space than it needs? Presumably so that it can guarantee that the disk won't fill up, but I think this practice is unreasonable. Suppose I need that space. Can you imagine if every spreadsheet program decided to reserve 20 meg of space because you might use that much on spread sheet applications and every word processor decided to reserve 40 meg of space because ... You get the idea. It's unreasonable. Further, it could communicate information about your hard disk without sending much data. One byte (8 bits) can send back the answer to 8 boolean questions. It could send your PATH and a few other variables without your knowledge. Prodigy does, in fact, get personal information about you. It decides what ads to send based on what you have done. And it is my understanding, possibly false, that it sells info about the users of Prodigy to others. David
rockwell@socrates.umd.edu (Raul Rockwell) (05/28/91)
Dave Laird: I will always wonder what they really had in mind with STAGE.DAT, probably never will really trust them, and do not recommend that anyone with sensitive data on their hard disk call them without taking precautions. Gee, does this make me sound paranoic? nahh.. that's barely even security concious. People truly concerned about security don't hook their machines up to the outside world at all, run them in shielded rooms, do extensive validation on both the equipment and the software, etc. And if you were truly paranoid, you'd probably have the entire system rigged to be destroyed in case of an emergency, with armed guards and extensive surveillance of the surrounding area, and maybe a few mines, etc. etc. Raul Rockwell
mikea@casbah.acns.nwu.edu (Atkinson Michael) (05/28/91)
rockwell@socrates.umd.edu (Raul Rockwell) writes: >Dave Laird: > I will always wonder what they really had in mind with STAGE.DAT, > probably never will really trust them, and do not recommend that > anyone with sensitive data on their hard disk call them without > taking precautions. Gee, does this make me sound paranoic? > >nahh.. that's barely even security concious. People truly concerned >about security don't hook their machines up to the outside world at >all, run them in shielded rooms, do extensive validation on both the >equipment and the software, etc. > I have a few files on my hard drive that I don't care for others to see. I have .ZIPed them with encryption, which on a MS-DOS machine with PKZIP is fairly easy to do. Maybe somebody with a serious decryption program could figure out that it is zipped (has inoccuous .ext) and could figure out my key, but it isn't *that* sensitive. >And if you were truly paranoid, you'd probably have the entire system >rigged to be destroyed in case of an emergency, with armed guards and >extensive surveillance of the surrounding area, and maybe a few mines, >etc. etc. > >Raul Rockwell Michael A. Atkinson | "Life doesn't happen in straight lines." mikea@casbah.acns.nwu.edu | All opinions expressed herein are solely Student Consultant | those of my friend Buck the squirrel. Academic Computing and Network Services, Northwestern University
paul@xcluud.sccsi.com (Paul Hutmacher) (05/29/91)
rockwell@socrates.umd.edu (Raul Rockwell) writes: > And if you were truly paranoid, you'd probably have the entire system > rigged to be destroyed in case of an emergency, with armed guards and > extensive surveillance of the surrounding area, and maybe a few mines, > etc. etc. I thought everyone safeguarded their system that way. I know I sleep better at night. Paul Hutmacher | "Just like Rome we fell asleep when we got spoiled. paul@xcluud.sccsi.com | Ignore human rights in the rest of the world ya uunet!nuchat!xcluud!paul | might just lose your own." -- Jello Biafra & DOA
louisg@vpnet.chi.il.us (Louis Giliberto) (05/29/91)
What the whole thing boils down to is credibility. Way back in my Commodore 64 days when I was in grade school, I eventually got a modem and signed up for Q-Link(tm). It was great, I loved it, but the bill was too much. They too have their own special software which basically takes control of your machine. They also have the same deal for IBM. The point is that I *never* worried about them doing something nasty. I trusted their software to control my machine. Now Prodigy(tm), given their past track record, I wouldn't trust for a second. The thing is that Prodigy has had a really shitty attitude in the past. THe way they run things, people *don't* want to trust them. They want to see them screw up. Makes a good business lesson, don't it? Louis Giliberto louisg@vpnet.chi.il.us -- --------------------------------------------------------------------------- ! "As above, so below; as below, so above" -- The Kybalion ! ! "I don't trust him; he has dark hair" -- My girlfriend's mother ! ! "So I'm stupid; what's your point?" -- Me !
dagmar@brainiac.raidernet.com (Greble Dagmar) (06/01/91)
louisg@vpnet.chi.il.us (Louis Giliberto) writes: > What the whole thing boils down to is credibility. > Way back in my Commodore 64 days when I was in grade school, I eventually > got a modem and signed up for Q-Link(tm). It was great, I loved it, but the > bill was too much. They too have their own special software which basically > takes control of your machine. They also have the same deal for IBM. > > The point is that I *never* worried about them doing something nasty. I trus Well, not to be picky, but there's not a heck of a lot you can DO to a Commie. The rumors flying around about Prodigy concerned that it was scanning a hard disk, where Beemers keep all their stuff. While you and I (Commodore 128D) would have to be asked by the software to stick personal data into the drive. ONe good thing about this is that we're immune to viruses, even if we do get swapping-cramp every now and then. :) -- ----- -------------------------------------------------------------------- = \:/ = Save Mother Earth or Die! : Greble Dagmar... Occult Theologian =_ : _= (This is not a joke.) :...!uunet!mjbtn!raider!brainiac!dagmar -- ----- --------------------------------------------------------------------
rockwell@socrates.umd.edu (Raul Rockwell) (06/01/91)
Me: >People truly concerned about security don't hook their machines up >to the outside world at all, run them in shielded rooms, do >extensive validation on both the equipment and the software, etc. Michael Atkinson: I have a few files on my hard drive that I don't care for others to see. I have .ZIPed them with encryption, which on a MS-DOS machine with PKZIP is fairly easy to do. Maybe somebody with a serious decryption program could figure out that it is zipped (has inoccuous .ext) and could figure out my key, but it isn't *that* sensitive. Good, because any time you display the text (or whatever) in those files on your screen, you're broadcasting it to the world (or at least everybody in a several block radius with some fairly trivial equipment). [Assuming you're using a CRT display.] Raul Rockwell
mikea@casbah.acns.nwu.edu (Atkinson Michael) (06/02/91)
In article <ROCKWELL.91Jun1114428@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes: >Me: > >People truly concerned about security don't hook their machines up > >to the outside world at all, run them in shielded rooms, do > >extensive validation on both the equipment and the software, etc. > >Michael Atkinson: > I have a few files on my hard drive that I don't care for > others to see. I have .ZIPed them with encryption, which on a > MS-DOS machine with PKZIP is fairly easy to do. Maybe somebody > with a serious decryption program could figure out that it is > zipped (has inoccuous .ext) and could figure out my key, but it > isn't *that* sensitive. > >Good, because any time you display the text (or whatever) in those >files on your screen, you're broadcasting it to the world (or at least >everybody in a several block radius with some fairly trivial >equipment). [Assuming you're using a CRT display.] > >Raul Rockwell Several block radius? Fairly trivial equipment? In My Less Than Perfect Understanding, it was a less than 100 foot radius with some serious equipment. Furthermore, if it is a couple of blocks, there are about 2000 other undergrads, with maybe 700 computers between them, within a couple of blocks. Interference might make it a bit difficult to read my text. Does anybody have the info on this technology? Michael A. Atkinson | "Life doesn't happen in straight lines." mikea@casbah.acns.nwu.edu | All opinions expressed herein are solely Student Consultant | those of my friend Buck the squirrel. Academic Computing and Network Services, Northwestern University
rockwell@socrates.umd.edu (Raul Rockwell) (06/02/91)
Michael Atkinson: [responding to my post about CRT image radiation] Several block radius? Fairly trivial equipment? In My Less Than Perfect Understanding, it was a less than 100 foot radius with some serious equipment. Furthermore, if it is a couple of blocks, there are about 2000 other undergrads, with maybe 700 computers between them, within a couple of blocks. Interference might make it a bit difficult to read my text. Does anybody have the info on this technology? Yeah, well.. I pulled my numbers on range out of a hat. Actual range depends quite a bit on local conditions. As for interference, various lensing techniques can "work wonders", though there is a limit to what you can pack into your typical van. Finally, a pure analog approach isn't going to do as well as something "tuned" to the vertical refresh rate of your screen (building up an image from a number of frames). Raul Rockwell
turrell@violet.berkeley.edu (David Turrell;;;;GQ79) (06/03/91)
>From: dogear!kharma!dave@isc-br!tau-ceti >Date: 27 May 91 08:30:21 GMT >Message-ID: <a6JL31w164w@kharma.UUCP> > >I think I have a handle on what has happened. Prodigy blew it, not from a >point of spying on people, but on stifling an honest, open response to the >public's concern. In other words, the worst thing they did wrong was a PR >gaffe of monstrous proportions. Their PR *used* to be good. I know I was intrigued by their ads and what else I heard about them before the stuff hit the you-know-what. I couldn't ever believe they were creatively spying on their customers, perhaps because I've worked for big brotherish companies and know how much a waste of everyone's time that would be. In the first place, it's not necessary. A computer service has a pretty good idea of where you fit on the scale of fundamentalist to far-out by the services you use. All my service, Compuserve, has to do for market reasearch is find out which forums I have joined, which databases I query and which CB channel I hang-out on. Never mind that they can read my e-mail if they have a mind to. Secondly, the demands on Prodigy's systems would be enormous, if they decided they were going to start uploading a large amount of data from their subscribers' machines. Care to calculate the added amount of processor time, number of disk seeks, etc. needed to upload and stash on Prodigy's system all the secrets that its subscribers have got stashed on their systems? So that does leave only the fact that people were willing to believe the worst about Prodigy because Prodigy had a major talent for p*ss**g people off. >[...] > >That isn't to say I don't think that Prodigy *COULD* be doing something funky >in the past. There are a *lot* of unanswered questions left over from when the >fiasco first started. I will always wonder what they really had in mind with >STAGE.DAT, probably never will really trust them, and do not recommend that >anyone with sensitive data on their hard disk call them without taking >precautions. Gee, does this make me sound paranoic? And you were sounding so sane up until now. I haven't heard much about what STAGE.DAT does, other than wind up with a lot of data no one wants it to have. Given Prodigy's use of graphics, it must contain, among other things, video display refresh buffers. The name of the file evokes a theatrical stage with its scenery flats that are lowered and raised as needed. STAGE.DAT probably has several refresh buffers whose starting offsets are loaded into the display device driver whenever Prodigy undergoes a change of "scenery". This might also account for some of its sloppy behavior. Graphics programmers are used to being under pressure to do a buffer update between scans and they often regard niceties, such as zeroing out allocated RAM prior to use, or using sparse matrix techniques to write to a file only the RAM they use, as sacrilegious. I hope Prodigy will give a better explanation sometime. -David Turrell
marrone@skiff.uucp (Michael Marrone) (06/04/91)
I'll make this short.....I subscribed to this newsgroup after my news server deleted the original messages on this topic. I heard about the privacy thing (and am also annoyed about some of their other stunts they pulled, but that's a different story) before, but don't know the details. Can someone post what exactly this is about, for my benefit, and others that may have missed it? Thanks.