Re: intent of package seti@home
Kevin Dalley writes:
> Yes, though fewer people are likely to fake an executable only program
> than a program which includes source code.
I wouldn't bet on that. As long as you're secretive, it's a challenge.
I'm almost tempted to do it just to prove the point. There's no need to
completely reverse engineer the client: all that's necessary is the
protocol.
You *will* get false data (not from me!). Plan on it.
> Sending data to multiple sources reduces the processing power
> substantially.
Reliability costs, but it is cheaper than the alternative.
> Perhaps occasional false data with a fake signal would help.
Test packets (good idea) are an additional way of validating clients, but
not a substitute for duplication.
It occurs to me that your test packets could require the client to compute
an md5sum on itself and send it in along with its version data. This would
pretty much require that everyone runs a binary issued or registered by
SETI, though.
> A second problem with source code is that people may try making changes
> and analyzing the SETI@Home data anyway.
If they introduced bugs then their modified client would fail the duplicate
test and/or the test packets.
> The speed would not be as fast, but the results would not be dependable.
The individual results from a network of unreliable computers will never be
dependable.
> Sending data to multiple clients usually protects against this problem,
> though a widely distributed modification may still create problems.
A common myth about free software. "If I release my source there will be
hordes of buggy, incompatible versions!" Doesn't happen. How many buggy,
incompatible unofficial modified versions of the Linux kernel are there in
circulation? Gcc? Perl? How many people are going to install a variant
SETI client hacked up by somebody they never heard of instead of getting
one from your site or installing it from their Debian CD? (The latter will
only be possible if you free your software, of course.)
> False data would only help a little, depending upon the bug introduced in
> the changed code.
You seem to be assuming that all changes will introduce bugs. Some will,
of course, but most will eliminate bugs (you do know that there are bugs in
the code, I hope).
Free your code and thousands of hackers will go to work finding bugs and
improvements and sending you patches. Keep it secret and the hackers will
lose interest. The crackers won't, though.
> And if I know their definition of impossibly quick, I slow down my
> forging.
It isn't a strong defense, but it would stop many trivial attacks.
It would also help defend against flooding.
--
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Reply to: