Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!usc!apple!portal!cup.portal.com!plav From: plav@cup.portal.com (Rick M Plavnicky) Newsgroups: comp.sys.amiga Subject: Re: PRODIGY HATES AMIGA -- Says wont do port! Message-ID: <33614@cup.portal.com> Date: 7 Sep 90 03:46:05 GMT References: <14988@shlump.nac.dec.com> <991@ucsvc.ucs.unimelb.edu.au> <26e31aa8-2999.3comp.sys.amiga-1@tronsbox.xei.com> Distribution: usa Organization: The Portal System (TM) Lines: 207 I've been following this discussion re: Prodigy for Amiga and I haven't heard anyone mention something which I consider quite important. During normal operation, Prodigy has the ability (at least on the IBM version) to update their software running on your machine without your knowledge. Prodigy salescritters I've spoken to acknowledge this when pressed, but they seem to take great pains to downplay it. While I agree with a previous poster who claimed that Prodigy availability would help to lend legitimacy to the Amiga, I know that *I* wouldn't have anything to do with it. Besides feeling pretty uncomfortable about turning control of my system over to some 'unknown' that explicitly limits their liabilty for damage in their contract, after using Prodigy on a friend's IBM for a number of hours I feel they offer me little, if any, real value for the price. There was a series of articles about this in Risks Digest some time ago which describe this much better than I could. I apologise for taking up so much space with this... From Risks Digest Vol. 9 Issue 69: >Date: Thursday, 15 Feb 1990 17:11:22 EST >From: m17434@mwvm.mitre.org (Wechsler, Donald B) >Subject: Now Prodigy Can Read You > >The Prodigy Services publication, PRODIGY STAR, (Volume III, No. 1) recently >showcased a "major benefit". The Prodigy system accesses remote subscribers' >disks to check the Prodigy software version used, and when necessary, download the latest programs. This process is automatic when subscribers link to the >network. > >I asked Prodigy how they protect against the possibility of altering >subscribers' non-Prodigy programs, or reading their personal data. Prodigy's >less-than-reassuring response was essentially (1) we don't look at other >programs, and (2) you can boot from a floppy disk. According to Prodigy, the >feature cannot be disabled. From Risks Digest Vol. 9 Issue 74: >Date: Fri, 09 Mar 90 09:37:19 E >From: Eric Roskos >Subject: Re: Now Prodigy Can Read You (RISKS-9.69) > >This issue was debated at length on the PRODIGY service several months >ago; an explanation was given by Harold Goldes, one of the PRODIGY >service's more technically knowledgeable user-support people. The >"programs" updated by the PRODIGY software are not executable files >loadable by the PC's operating system; it is not even clear that it is >code executable by the PC's CPU. Rather, routines to draw the >individual graphics displays used by the PRODIGY software are cached on >the user's disk in a single file, STAGE.DAT, and this cache is updated >via normal cache-updating algorithms. The PRODIGY software is unable to >update the DOS-executable object programs automatically, and has to send >out new disks when this is necessary. The explanation given in the >_PRODIGY_Star_ newsletter was an overly-abbreviated version, limited in >technical detail by the PRODIGY service's orientation to nontechnical >people, and, no doubt, by space limitations. > >Nevertheless, due the PC's lack of security mechanisms, the possibility >of altering subscriber's programs or reading personal data does exist on >any such system. PRODIGY representatives have repeatedly stated that >the PRODIGY software will not do this, and my examination of the >operation of the software has not shown any evidence that any file other >than STAGE.DAT is updated. > >A topic that has not been so clearly answered is what some users feel to >be the PRODIGY service's overuse of its built-in censorship facilities >and its employment of "over 100" censors; they feel the PRODIGY sevice >uses this facility to control the expression of opinions on the >service's bulletin boards which may adversely affect marketing goals. From Risks Digest Vol. 9 Issue 75: >Date: 12 Mar 90 20:44:07 EST (Mon) >From: simsong@prose.CAMBRIDGE.MA.US (Simson L. Garfinkel) >Subject: PRODIGY updating programs > >I must take issue with Eric Roskos saying that PRODIGY can only update >information in the STAGE.DAT file. > >In doing my article on PRODIGY for The Christian Science Monitor, I was told b Prodigy's manager of software services that one of the really nifty tricks of >PRODIGY is that nearly the entire system running on the PC --- including the >.EXE files --- can be updated remotely. This eliminates the need to send out >floppy disks with updates. (They didn't have it working well at the beginning >and actually had to send out one update --- an extremely expensive >proposition.) > >The reason for wanting to do this is based on two things: prodigy's pricing >structure and its target market. Prodigy charges one $9.95 a month. At that >price, it just isn't possibly to economically send out floppy disks. >Especially if they want to have 1-5 million subscribers within the next 2-10 >years. > >The other thing is their target market: they want people who don't know >anything about programs or files. Automatic updates eliminate the necessity o having to have users put disks into their computers and try to figure out what >is going on. > >The Prodigy censors is a very real problem. They have recently shut down >PRODIGY groups that have ventured into "unacceptable" topics like abortion and >homosexuality. From Risks Digest Vol. 9 Issue 78: >Date: Mon, 26 Mar 90 09:50:20 >From: Eric Roskos >Subject: More on Prodigy's Updating of a User's Disks > >In a recent RISKS posting, I responded to Donald B. Weschler's >statement that Prodigy could update arbitrary files on the user's hard >disk by saying that it appeared that Prodigy only does cache management >of data in a single file, STAGE.DAT, via this method. > >In response to my comment I received mail from Simson Garfinkel, who >wrote the recent Christian Science Monitor article on Prodigy. He said >that Prodigy's manager of software services had told him that they could >indeed update other files, including .EXE files, thus avoiding the need >to send out update disks. > >Seeking an explanation, I asked what could be updated by this method on >Prodigy's technical service bulletin board about a week ago, and also >wrote to one of their technical support people asking for clarification. >In response to this, Prodigy, who has always previously answered my >technical questions immediately, simply ignored the question altogether. >It has now been deleted from the bulletin board by Prodigy's automatic >article-expiration software. Harold Goldes, the Prodigy representative >who I asked about the updating, likewise did not reply. > >There were several messages by users who read my posting; they all said >the same thing -- that Prodigy could update .EXE files. One person said >that he had expressed concerned about the problem, but that Prodigy had >replied "trust us, no one has the access needed to cause an unauthorized >update." None of the posters said where they obtained their information, >but all postings are screened by Prodigy's staff before appearing on the >board, and Prodigy did nothing to correct these statements. Thus, I >tend to believe them, since they support the statement made by the >Prodigy manager. > >Needless to say, this is not encouraging. I re-checked my files in the >Prodigy directory this evening, and found that no file but STAGE.DAT has >been updated since I installed the software nearly a year ago. I >examined the contents of STAGE.DAT with a disassembler, and it does not >seem to be 8086 code. It has always been my belief that STAGE.DAT >contains code interpreted by the main Prodigy program, since Prodigy >also runs on the Macintosh and since STAGE.DAT seems from Prodigy's >previous descriptions to contain definitions of graphics screens and >windows displayed while the system is operating. > >If it is indeed an interpreted environment, it would be relatively easy >for Prodigy to prevent unauthorized updates of anything but STAGE.DAT. > >If, however, the claims are correct, the Prodigy updating mechanism >would seem to be a considerable risk to Prodigy and its users, as in the >case of a disgruntled employee who arranged for an "update" to occur >after leaving the company, or of someone who discovered a way to >circumvent Prodigy's access controls. Prodigy acknowledges the >possibility of such unauthorized access by outsiders in its membership >agreement: "Unauthorized access to the PRODIGY service or to restricted >portions of the service is a breach of this agreement and a violation of >law." > >This same agreement also tries (in capital letters) to limit Prodigy's >liability: "ANY LIABILITY OF PRODIGY, INCLUDING WITHOUT LIMITATION ANY >LIABILITY FOR DAMAGES CAUSED OR ALLEGEDLY CAUSED BY ANY FAILURE OF >PERFORMANCE, ... DELETION, ... THEFT OR DESTRUCTION OR UNAUTHORIZED >ACCESS TO, ALTERATION OF, OR USE OF RECORDS ... [including] TORTIOUS >BEHAVIOR ... SHALL BE STRICTLY LIMITED TO THE AMOUNT PAID BY OR ON >BEHALF OF THE MEMBER TO PRODIGY FOR THE PRODIGY SERVICE IN THE PRECEDING >12 MONTHS." At current service fees, this would be a maximum of $120 >liability on the part of Prodigy for damage to a user's data. From Risks Digest Vol. 9 Issue 79: >Date: Fri, 6 Apr 90 23:33:43 PDT >From: leonard@nosun.West.Sun.COM (Leonard Erickson) >Subject: Re: More on Prodigy's Updating of a User's Disks > >CompuServe has had the ability to do this for at least 9 years. Their >L-Protocol was *specificly* designed so a user could enter a short >BASIC program which would call in, download *and execute* a terminal >program. > >The B-protocol description includes this feature *explicitly* in the >protocol description, along with such features as "disable keyboard" >and disable video upddates". I *think* the older A protocol also had >these features. > >All of these CIS protocols include a whoami string that sends an >identifier string that identifies the machine type, software version, >and protocols supported in response to a remote query. This response is >invisible to the user. > >I know that some people used programs like CIS's VIDTEX for their >*only* terminal program. I once considered having a BBS check for such >people and do something to their machine... it would be rather easy. > >This is not a new risk, but it is more widespread than some think. >-- >Leonard Erickson ...!tektronix!reed!percival!bucket!leonard >CIS: [70465,203] >"I'm all in favor of keeping dangerous weapons out of the hands of fools. >Let's start with typewriters." -- Solomon Short /* Rick Plavnicky ...!sun!cup.portal.com!plav -or- plav@cup.portal.com */