[RC5] Service Pause Option

Bruce Wilson bwilson at distributed.net
Wed Mar 20 13:45:27 EST 2002

Hash: SHA1

We are very concerned about preserving the anonymity of our
participants, if they wish to remain anonymous.  Whatever process we
settle on (with public review, of course) will place high value on
the ability of legitimate users to install en masse, and for
participants to remain anonymous.  What we have *is* working pretty
well, but it does have some problems that continue to make it hard
for some people to participate.

The "registration/activation" process would not require any personal
information.  Basically, we already assign an ID to every participant
upon receipt of your first work unit.  The difference in this
scenario is that you would put an ID into dnetc instead of your email
address.  Because we would control the creation of the ID's, we would
have a record of who requested a given ID (the IP they were at, for
instance) which would give us some clue as to the identity of the
participant if there was ever any question.  This identifying
information would be of little value except for following up on

Work submitted with an invalid ID would be assumed to be from
unauthorized installs.  (Yes, yes, we're planning to phase this in so
everyone has time to change.)

In today's world, you could configure your client to use
ltorvalds at linux.org and nobody would be the wiser.  This has been the
case with a few of our abuses.  (Nugget's e-mail address was
targeted, for instance.)  Since work wouldn't appear in stats unless
it belonged to a valid ID, we remove part of the incentive of
including dnetc as a payload with a virus or trojan - you can't see
the results unless you get an ID, and then we'll know who you are. 
This is what I meant by making unauthorized installs less profitable.
 If you can't see how much work was done by your trojan install, why
install dnetc at all?

As an added advantage, since your work is tagged by ID instead of
your email address, retires could become a thing of the past.  If
your e-mail address changes, you do not need to reconfigure all your
dnetc's, just edit the address in the stats database.  Email address
would become demographic information instead of a primary key. 
Again, we plan to provide backward compatibility for all outstanding

In regards to people preserving their privacy, it's positively
shocking how few participants have ever changed the listmode to hide
their e-mail address.  We have never and will never sell our
participant's addresses, but we know addresses have been harvested
from our site on many occassions.

Bruce Wilson <bwilson at distributed.net>
PGP KeyID: 5430B995, http://www.toomuchblue.com/ 

Build a man a fire and he'll be warm for a day.
Set a man on fire, he'll be warm for the rest of his life.

| -----Original Message-----
| From: owner-rc5 at lists.distributed.net 
| [mailto:owner-rc5 at lists.distributed.net] On Behalf Of blitz
| Sent: Wednesday, March 20, 2002 12:49
| To: rc5 at lists.distributed.net
| Subject: RE: [RC5] Service Pause Option
| I can assure you, Dnet will dry up and blow away should you 
| follow through 
| with the below changes. Sending personal information over the 
| net is the 
| point most people balk at, and DNet is no different. Yeah, 
| sure you have an 
| email address, but its probably a throw-away in the first 
| place. Large 
| projects are always suspicious, and Dnet is no different. Who 
| knows, you 
| might sell all our email addys to a spamhaus once the project 
| is done? The 
| ability to labor on anonymous is precious to a lot of people. 
| Take it away, 
| and I can guarantee there will be a LOT less participants.
| Generally, I think most people are not installing where its 
| not wanted. If 
| Dnet becomes anal about it, well,theres lots of other distributed 
| challenges out there people can participate it....
| What youve got now is working pretty well, changes will not 
| be good for you.
| Just my 2c
| >Recent abuses have prompted us to explore options which will make
| >unauthorized installs more difficult, less profitable, and easier
| >to trace.  User interaction upon install is one option we are
| >exploring. 
| >  A registration/activation process is another.
| --
| To unsubscribe, send 'unsubscribe rc5' to 
| majordomo at lists.distributed.net
| rc5-digest subscribers replace rc5 with rc5-digest

Version: PGP 7.0.4


To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list