Cheating in public distributed computing
Cheating is a serious problem in public distributed computing. For
both, the organizers of a project who might get false results and for
common users who are deprived of
a proper ranking in contributor statistics. Most organisations prefer
not to speak publically about cheating. This is usually due to fear of
losing the goodwill of contributors or to avoid
giving hints to cheaters. But it is clear that "security by
obscurity" or simply denying a problem at all are not adequate ways to
handle this problem.
Lecture at 20C3:
There is no way around the fundamental truth that public distributed
computing relies on contributions of essentially untrusted machines.
But there are ways to minimize the impact and feasibility of cheating
in public distributed computing projects. In a lecture
at the 20th Chaos Communication Congress
I outlined the problem and described possible ways to deal with it. The slides are now available as a pdf file under a Creative Commons License
Three basic guidelines on how to cope with cheating in public distributed computing.
Dont distribute "yes/no" jobs but aim for complex results to enable useful redundant verification
-> if you are really good you might implement magic ringers
Track work assignments in order to detect numerous "script kiddie" cheats
-> if you are really good you would use a public key infrastructure
A correct/trustworthy finaly result must be achievable even if some cheating remains undetected
-> rarely is it possible to efficiently verify the perfect correctness of all distributed jobs