home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8518 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  2.6 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!uwvax!gorgon!fullfeed!ruth!rat
  2. From: rat@ruth.UUCP (David Douthitt)
  3. Newsgroups: comp.org.eff.talk
  4. Subject: Purpose of a (beneficial) compression virus
  5. Message-ID: <JXB4wB5w165w@ruth.UUCP>
  6. Date: 9 Jan 93 03:37:42 GMT
  7. Organization: Network XXIII - +1 608 222 9253
  8. Lines: 53
  9.  
  10.  
  11. Giving some thought to the purpose for such a virus, I find myself with more
  12. and more questions...
  13.  
  14.     1. If the only true action of the virus is to load itself into memory
  15.        when called, why not place it into a clear plain-as-day CONFIG.SYS
  16.        file as a device driver?
  17.  
  18.     2. What is different between a virus which takes up residence to
  19.        compress executables on the fly and a device driver which
  20.        compresses files as they are loaded for the first time?
  21.  
  22. Seems to me the underlying purpose of a virus is to infect systems; if
  23. the user has to install the marker file then the virus can no longer
  24. infect by its own and is no longer useful as a virus.  Why couldn't
  25. the user install a device driver instead?
  26.  
  27. I would suggest that the best use for a beneficial virus would be on a
  28. larger scale to replicate some code/action over a wide audience.
  29.  
  30. For example:
  31.    - a virus could suggest repair (and possibly effect the actual
  32.      repair) of an operating system or any other program.
  33.  
  34.    - update old programs with new versions.
  35.  
  36.    - take (nationwide! international!) surveys/polls.
  37.      [SAY!  Is this an idea or what?  :-) ]
  38.  
  39.    - eradicate other (malicious) viruses.
  40.  
  41.    - eradicate pirated copies of software (its possible!)
  42.  
  43. Most of these options would include some form of approval of the host.
  44. In the case of updates, for example, it could be a part of the purchase
  45. agreement.  In the case of surveys/polls, it could be part of the code.
  46.  
  47. In fact, the update example I would suggest is close to how things are
  48. done with Flash BIOSes in PCs - with the exeption that the user calls
  49. the BBS or whatever and gets the new BIOS and downloads it.  Suppose the
  50. user was registered with the manufacturer and when a new BIOS came out,
  51. the manufacturer's BBS called his system, and downloaded the BIOS into
  52. his system one night?  [HHMMMMM.... lots of ethical questions there...]
  53.  
  54. Lots of things to think about....
  55.  
  56.  
  57. --
  58. UUCP: ....!fullfeed.com!ruth!rat        |  Network XXIII - +1 608 222 9253
  59. InterNet: rat@ruth.UUCP                 |  80Megs+ of Usenet/Fido programs!
  60. Fidonet: David Douthitt 1:121/23        |  ... Files via Fidonet FREQ,
  61. "...because appealing to the masses has |  anon uucp, first time login,
  62.  never appealed to us."                 |  mail to fileserver@ruth.uucp
  63.