alex@bilver.uucp (Alex Matulich) (05/07/91)
In article <1991May06.213644.8679@convex.com> swarren@convex.com (Steve Warren) writes: >Pay attention, Alex. I never said that "Prodigy must be stealing >private data." If I did, then produce the quote. Otherwise shut up. If I accused you of that, then produce the quote. :-) My article was not directed at anyone in particular, I'm sorry if you took offense. >What I said was that if the information contained within the quoted >article was actually true, then Prodigy is lowlife scum. I stand by >that statement. > >Did you even read the article? I read it three different times, in three different newsgroups. The article was written by someone who obviously does not understand much about MS-DOS. If your data is being transmitted to Prodigy, then Prodigy is indeed a lowlife scum, but that was never proven. All that article showed was that a file gets created containing portions of unused disk space and computer memory. Big deal. >Let me refresh your memory. > >From my article (quoting another article): > [...] >Now, if you had bothered to read this, you would have realised that >he is talking about a seperate installation onto a floppy. Yes. The guy may not have booted up the floppy from a power-off state, and definitely did NOT clear the free clusters on his hard disk. If you had bothered to read this... well, never mind. >*You* tell *me* how a listing of his hard drive .BAT and setup files got >installed into the prodigy data file on his floppy? If the hard disk is there, good software should be intelligent enough to recognize the fact, and use all the services available to it on the computer. The listing of his .BAT files was most likely occupying unused space, from a file that used to be there, as I said before. Space for an allocated file is not cleared first. This is how MS-DOS (and AmigaDOS I might add) does things. If the Prodigy software was written to clear the space in the first place, this fuss would never have taken place. I can think of better, more transparent ways to glom someone's data. >>2) Then, run Prodigy. From a floppy, to make the test more conclusive, if > >I guess you really *didn't* read the article, huh? The test in the article was not what I described. Did you bother to read mine before flaming me? >There were other things mentioned in the quoted article that further >demonstrate premeditated data-snarfing. I never certified that they were >actually true. But the things mentioned in the article cannot happen by >accident. I think they can. You have made some good points, though. Mostly what I was objecting to in my original article was the appearance of people jumping to a conclusion without considering all the facts. If I sounded like I was accusing _you_ in particular of doing that, I apologize. My article was not directed at any one person. -- _ |__ Alex Matulich /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: alex@bilver.uucp <or> ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/09/91)
As quoted from <1991May06.213644.8679@convex.com> by swarren@convex.com (Steve Warren): +--------------- | There were other things mentioned in the quoted article that further | demonstrate premeditated data-snarfing. I never certified that they were | actually true. But the things mentioned in the article cannot happen by | accident. +--------------- Read up on DOS buffers, and on the standard malloc() function (NOT calloc()). They can indeed happen, and do happen, and have been proven to happen. (See my other post on the subject. See also comp.risks.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH