home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8437 < prev    next >
Encoding:
Text File  |  1993-01-07  |  6.1 KB  |  141 lines
  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!news.ans.net!cmcl2!panix!rpowers
  3. From: rpowers@panix.com (Richard Powers)
  4. Subject: Re: Beneficial Virus?
  5. Message-ID: <C0IDMu.By5@panix.com>
  6. Organization: PANIX Public Access Unix, NYC
  7. References: <C0EJAu.HuI@panix.com> <1993Jan6.152243.22472@nastar.uucp> <C0GIA7.4Fz@panix.com> <1993Jan7.152339.25886@nastar.uucp>
  8. Date: Fri, 8 Jan 1993 00:06:30 GMT
  9. Lines: 130
  10.  
  11. In <1993Jan7.152339.25886@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  12. >In article <C0GIA7.4Fz@panix.com> rpowers@panix.com (Richard Powers) writes:
  13. >>>>In <1993Jan5.153018.18935@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  14.  
  15. >>>Consider a multi-user system where another user installed the virus, and I
  16. >>>want to transfer a file to my home system, and need to transfer the marker
  17. >>>file, but I do not know which file it is.
  18.  
  19. >>A multi-user system can be treated exactly like several single-user
  20. >>systems.  If you want to transfer a file (or make available to other
  21. >>users) to another user on the same _or_ to a different system you can:
  22. >>
  23. >>(1) remove the virus first
  24. >>    or
  25. >>(2) also transfer (make available) the permission file.
  26.  
  27. >If I do not know the virus is in place on the multi0user system (and if it
  28.  
  29. How would you not know it is in place?  You would have had to place it
  30. there yourself.  Or at very least placed the marker file.
  31.  
  32. >deserves the name 'virus', I shouldn't know unless I really poke around), I
  33.  
  34. All it needs to "deserve" the name virus is the ability to replicate
  35. itself.  
  36.  
  37. >cannot be aware of the necessity of transferring the marker file, and I also
  38. >do not know how to remove the virus before transferring the file.
  39.  
  40. >>If you're talking about a multi-user system where a super-user has
  41. >>installed the virus (ie: the virus has permission to spread to _any_
  42. >>users files), then I would certainly hope that the super-user would
  43. >>have informed all other users that this is the case.  I don't think it
  44. >>would be ethical otherwise, since the person would be changing people's
  45. >>files without consent.
  46.  
  47. >Not necessarily.  Some systems operate user accounts under suffrance - you
  48. >get only what the admins allow.  Others allow privacy, but do not guarantee
  49. >anything else.  The raw format of the data is not usually guaranteed, like
  50. >the position of files on a disk is not guaranteed.
  51.  
  52. I'm not sure what you're getting at here.  If the system in question
  53. has no guarantees about anything, I don't want to be on the system,
  54. BCV or not.
  55.  
  56. >An admin who installed a device driver that compressed all files would
  57. >be doing the same thing, in essence, and would not be likely to tell the
  58. >users, except as bragging about the regained disk space :-)
  59.  
  60. IMO _if_ the existence of the virus will have any impact on the users,
  61. the admin has an obligation to notify those users.  This is not the
  62. same as a device driver.  With a device driver the effects should be
  63. totally transparent to the user.  And again, if it is _not_
  64. transparent, then the users should know.
  65.  
  66. >>Upon failing to find the marker file (which may contain some of the
  67. >>code the virus uses to compress/spread), it could do several things:
  68.  
  69. >>(1) Remove itself.  The BCV would decompress the file and then save it
  70. >>back to disk in its original state.  Uncompressed and w/out virus
  71. >>code.
  72.  
  73. >This would be the only ethical option for a 'beneficial virus', IMHO.
  74.  
  75. Not this method alone, IMHO.  If you have so much of your usable disk
  76. space compressed that not everything will fit uncompressed, then this
  77. method alone would be disastrous.
  78.  
  79. >>(2) Decompress as usual.  It would get the file running as usual, and
  80. >>then just quit.  Letting the host file continue.  *** I _don't_ think
  81. >>this is the way it should be implemented. ***
  82.  
  83. >>(3) Notify the user.  Tell the user it exists.  This could (should) be
  84. >>combined with other methods.
  85.  
  86. >>(4) Create a marker file.  Give itself permission to spread.  *** I do
  87.                                 ^^^^^^^^
  88. >>_not_ think this should be implemented by itself.  It defeats the
  89. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  90. >>pupose of the marker file.  ***
  91. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  92.  
  93. >This would make the virus unremovable.  Major unethical for a beneficial
  94. >virus.
  95.  
  96. As I already said.
  97.  
  98. >>(5) Ask the user.  Give the user a menu of choices for what it should
  99. >>do.  This is the only context I see (4) being appropriate.  (3) is, of
  100.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  101. >>course, not applicable.   ***  I prefer this method over all.  If (1)
  102. >>were implemented and the marker file was lost w/out my knowledge, I
  103. >>wouldn't want my files to mysteriously decompress. ***
  104.  
  105. >This starts to make the program less of a virus, since it becomes more of
  106. >a system utility.
  107.  
  108. It is a virus because it replicates itself.  Period.
  109.  
  110. >It also makes it possible for a user to infect a system without the
  111. >owner's knowledge.
  112.  
  113. I assume you are referring to method (4)?  I covered that above.  Read
  114. the underlined again.
  115.     ^^^^^^^^^^
  116.  
  117. >>I would probably also have one or more BCV maintenance tools.  To
  118. >>check up on how it is performing, to create/update/change the
  119. >>permission file, and to remove the BCV from specific files.
  120.  
  121. >This, along with the marker file having the compression code, makes this into
  122. >something other than a virus, IMHO.  It is not self-contained anymore.  It
  123. >becomes a disk compression utility that could be installed as a hook in the
  124. >drive access instead of a free-floating infectious program.
  125.  
  126. The whole idea has involved from the original to deal with a lot of
  127. nitpicking problems.  The original context was a hypothetical concept
  128. to refute the idea that a beneficial virus is inherently _impossible_.
  129.  
  130. I may not have used the most ideal example, but IMHO, it qualifies.
  131. Especially under the conditions that the idea was originally born to
  132. deal with.  And that is: a method to automatically PowerPack (an Amiga
  133. compression program) all executable files which would benefit on my
  134. home computer.
  135.  
  136. -- 
  137.  Richard Powers    / Huh?  David Letterman is whipping  / Apathy.
  138. rpowers@panix.com / his microphone with a rubber hose. /
  139.              /  No, wait!  Thats beef jerky!      /   Hail Eris! 
  140.  
  141.