Re: distributed.net and seti@home

[kgouws () GLOBAL CO ZA (Kerneels)]

This may sound silly, but for all you know your machine could be churning
away at decrypting the FBI login passwords for all you know, or whetever
else, with a lovely gui showing you that you still havent found any aliens
:)  If there is no source, how can you be sure what is being deciphered?
I personally like the idea of everyone working together toward a common
goal, but I dont believe in blind trust.

just my opinion.
Kerneels Gouws.

Sen_Ml Sen_Ml wrote:

> i'm getting a number of private comments about my posting, but rather
> than reply individually, here are my thoughts.
>
> one person mentioned that seti does not communicate w/ headquarters
> until it's finished with making its packet.  i fail to see the
> relevance of this.  how do i know what's in the packet?  i could scan
> all packets leaving the network to see...what exactly?  how do i know
> that info about my network isn't being leaked?  for me at least, it
> isn't worth the effort to try to figure out what info is being sent --
> there might be a design spec for the packets sent back about
> computational results, but how do i know whether the spec is followed
> or that there is no way to encode info about my network in there
> (everyone knows about steganogrpahy right?)?  i can't expect the world
> at large to go over source code that isn't available.
>
> much better to not run and not allow that sort of software to run on
> my network to begin with.  which is in fact what i do -- of course,
> you still have to look for people running the software ;-P  even if you
> are monitoring your network for certain packets and you know whose
> machine is running some distributed client, you still have to take
> the time to go deal with it.  it might also involve confrontations w/
> people that you might have been able to avoid otherwise.  but i digress.
>
> don't get me wrong, i think the distributed approach to some of these
> problems is a great idea.  i just think that given how many different
> places this kind of code runs, source really ought to be available
> and/or people should really think about where they run this kind of
> code (and indeed, i'm sure people do think about this -- just not
> enough people -- the awareness problem).  wait, the same idea applies
> to operating systems -- ah, now i see why i don't run certain ones ;-)
>
> it's not like i doubt the authors' intentions -- i distrust people who
> might want to abuse the fact that the code is so widespread.  it's
> also not like the folks who write the code always get to decide what
> to put in -- also if people are under nda, they may not be allowed to
> talk about what they put in either.  i am not suggesting here that i
> believe that for any of these projects there is anything sinister
> going on.  but who knows whether it might happen in the future in of
> these projects and it might happen in some new project that does
> collect info in a similar manner.  i'm reminded of a certain maker of
> audio software and personal information...
>
> i agree that if software like this were to put network interfaces into
> promiscuous mode that people would (i hope) notice.  obviously, that's
> not the only way to gain useful info about a network -- i used the
> word 'sniffing' originally, but perhaps i should have used more
> general phrasing.
>
> depending of the system you have, you could watch system calls,
> registry accesses, etc. to guess at what kind of info a piece of
> software uses or collects, but w/ the source you can stop guessing.
> why spend all that extra effort?
>
> another point to consider is the fact that it might be possible to
> write software that puts a network interface into promiscous mode w/o
> being able to tell in the usual ways by modifying the existing system.
> it's not like this hasn't been done for un*x boxen before -- i
> wouldn't be surprised if this could be pulled off for windows boxen
> either (perhaps it already has been).  even in this case i would hope
> someone would notice, but it's surprising how long this can take
> sometimes.
>
> i suppose it ends up being the full-disclosure discussion.
>
> there is one point that i haven't heard discussed though which has to
> do w/ people getting used to features or the way certain systems
> behave.  it's true that in specific cases you may be able to decide
> not to run certain software -- through policy, enforecement, etc.
>
> however, if enough of the right (or wrong?) people get used to some
> idea -- like running some of these distributed clients -- they may
> start building similar systems using similar designs (e.g. distributed
> w/ no source code).  after a while, people may just come to expect
> certain kinds of systems.  once enough of the population thinks this
> way it may become very hard for you to decide not to use certain types
> of systems.
>
> some of the long-term potential consequences don't feel very good.