From: rpowers@panix.com (Richard Powers)
Subject: Re: Beneficial Virus?
Organization: PANIX Public Access Unix, NYC
Date: Fri, 8 Jan 1993 00:06:30 GMT

In <1993Jan7.152339.25886@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
>In article <C0GIA7.4Fz@panix.com> rpowers@panix.com (Richard Powers) writes:
>>>>In <1993Jan5.153018.18935@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:

>>>Consider a multi-user system where another user installed the virus, and I
>>>want to transfer a file to my home system, and need to transfer the marker
>>>file, but I do not know which file it is.

>>A multi-user system can be treated exactly like several single-user
>>systems.  If you want to transfer a file (or make available to other
>>users) to another user on the same _or_ to a different system you can:
>>
>>(1) remove the virus first
>>	or
>>(2) also transfer (make available) the permission file.

>If I do not know the virus is in place on the multi0user system (and if it

How would you not know it is in place?  You would have had to place it
there yourself.  Or at very least placed the marker file.

>deserves the name 'virus', I shouldn't know unless I really poke around), I

All it needs to "deserve" the name virus is the ability to replicate
itself.  

>cannot be aware of the necessity of transferring the marker file, and I also
>do not know how to remove the virus before transferring the file.

>>If you're talking about a multi-user system where a super-user has
>>installed the virus (ie: the virus has permission to spread to _any_
>>users files), then I would certainly hope that the super-user would
>>have informed all other users that this is the case.  I don't think it
>>would be ethical otherwise, since the person would be changing people's
>>files without consent.

>Not necessarily.  Some systems operate user accounts under suffrance - you
>get only what the admins allow.  Others allow privacy, but do not guarantee
>anything else.  The raw format of the data is not usually guaranteed, like
>the position of files on a disk is not guaranteed.

I'm not sure what you're getting at here.  If the system in question
has no guarantees about anything, I don't want to be on the system,
BCV or not.

>An admin who installed a device driver that compressed all files would
>be doing the same thing, in essence, and would not be likely to tell the
>users, except as bragging about the regained disk space :-)

IMO _if_ the existence of the virus will have any impact on the users,
the admin has an obligation to notify those users.  This is not the
same as a device driver.  With a device driver the effects should be
totally transparent to the user.  And again, if it is _not_
transparent, then the users should know.

>>Upon failing to find the marker file (which may contain some of the
>>code the virus uses to compress/spread), it could do several things:

>>(1) Remove itself.  The BCV would decompress the file and then save it
>>back to disk in its original state.  Uncompressed and w/out virus
>>code.

>This would be the only ethical option for a 'beneficial virus', IMHO.

Not this method alone, IMHO.  If you have so much of your usable disk
space compressed that not everything will fit uncompressed, then this
method alone would be disastrous.

>>(2) Decompress as usual.  It would get the file running as usual, and
>>then just quit.  Letting the host file continue.  *** I _don't_ think
>>this is the way it should be implemented. ***

>>(3) Notify the user.  Tell the user it exists.  This could (should) be
>>combined with other methods.

>>(4) Create a marker file.  Give itself permission to spread.  *** I do
								^^^^^^^^
>>_not_ think this should be implemented by itself.  It defeats the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>pupose of the marker file.  ***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>This would make the virus unremovable.  Major unethical for a beneficial
>virus.

As I already said.

>>(5) Ask the user.  Give the user a menu of choices for what it should
>>do.  This is the only context I see (4) being appropriate.  (3) is, of
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>course, not applicable.   ***  I prefer this method over all.  If (1)
>>were implemented and the marker file was lost w/out my knowledge, I
>>wouldn't want my files to mysteriously decompress. ***

>This starts to make the program less of a virus, since it becomes more of
>a system utility.

It is a virus because it replicates itself.  Period.

>It also makes it possible for a user to infect a system without the
>owner's knowledge.

I assume you are referring to method (4)?  I covered that above.  Read
the underlined again.
    ^^^^^^^^^^

>>I would probably also have one or more BCV maintenance tools.  To
>>check up on how it is performing, to create/update/change the
>>permission file, and to remove the BCV from specific files.

>This, along with the marker file having the compression code, makes this into
>something other than a virus, IMHO.  It is not self-contained anymore.  It
>becomes a disk compression utility that could be installed as a hook in the
>drive access instead of a free-floating infectious program.

The whole idea has involved from the original to deal with a lot of
nitpicking problems.  The original context was a hypothetical concept
to refute the idea that a beneficial virus is inherently _impossible_.

I may not have used the most ideal example, but IMHO, it qualifies.
Especially under the conditions that the idea was originally born to
deal with.  And that is: a method to automatically PowerPack (an Amiga
compression program) all executable files which would benefit on my
home computer.

-- 
 Richard Powers    / Huh?  David Letterman is whipping  / Apathy.
rpowers@panix.com / his microphone with a rubber hose. /
	         /  No, wait!  Thats beef jerky!      /   Hail Eris!