So, how do you create a signature here - I didn't see an explanation in your FAQ, or am I missing something?!

Same way as through any other forum: through your forum preferences. :)

---

Greetings,

Jord it is then - and I am James, with a "Jay" rather than a "Yay". ;D (Scandinavia by any chance? - hence the same bedtime as myself!?)

Thank you for forwarding it to the relevant person(s).

As you can see, I've successfully added my usual avatar ("Dragan Glas" - pronounced Droggon Gloss - is Irish for "Green Dragon". Yes, I'm Irish, although currently based in the UK. ;D)

I'm also currently awaiting a colleague - who's a wizard at stats - to send me the right code/link for the team's stats image. When he replies, I'll add that into my signature! (I use a different one at CastleCops.)

[Speaking of bedtime... ;D - Don't stay up looking at the monitor!! 8O)

Kindest regards,

Dragan Glas
Team CastleCops Chief Host
http://www.castlecops.com

---

Jord it is then - and I am James, with a "Jay" rather than a "Yay". ;D (Scandinavia by any chance? - hence the same bedtime as myself!?)[/url]

Mine is Jord without the DJe sound in the J.

And I live in the country on your right, just across the channel. Well, ok, depends on where you live in England, but let's say above London, then look to your right. ;-)

Clue: we spreken er Nederlands.

---

Hi Jord, Dragan Glas,

our bedtimes are similar ;o) I'm from Austria.

Be that as it may, I'd like to help in evaluating BOINC clients for validity, though I believe that may be a bit like Sisyphos and his rock...

At this point, I know of about 10 modified BOINC versions in general circulation, but those are just the ones that I stumbled upon in the past half year. The real number is most probably closer to 30-50.

Maybe the project itself could help us out with this - they should be able to query the main DB and find out all unique BOINC manager version strings (SELECT DISTINCT from xxxx).

As an added precaution, it may be useful to calculate checksums for the BOINC client executable and keep a list of such checksums to compare against. This would make automated version checking (and also, disallowing known unsafe/cheating clients) much easier (you can cheat a version string, but having the exact same checksum? Not likely).

Regards,
Simon.

---

First off, welcome to these forums and this thread, Simon. :-)

Hi Jord, Dragan Glas,

our bedtimes are similar ;o) I'm from Austria.

What are you still doing up then? ;-)

Be that as it may, I'd like to help in evaluating BOINC clients for validity, though I believe that may be a bit like Sisyphos and his rock...

I lack some historic knowledge, so thank the gods for Wikipedia: Sisyphus.

The real number is most probably closer to 30-50.

If you add all Linux versions together, then add the not-so-normal-platforms to it, does that do it justice?

Maybe the project itself could help us out with this - they should be able to query the main DB and find out all unique BOINC manager version strings (SELECT DISTINCT from xxxx).

Wouldn't this be available through the statistics XML file that each project (so far they have one) releases every day/x-days?

As far as a checksum goes, you mean to have it crunch a result which outcome is always known? A control result?

---

Hi Jord,

Thanks for the welcome :o) I may really have understated the possible number of clients in the wild...

No, by checksum I mean calculating a checksum (MD5 or the like) for the executable file in question itself. This (MD5) also has the added advantage of being available on any platform (it's open source) and a widely used algorithm.

As for the data being acessible through the XML stats, I'm not so sure. May be possible, though I haven't looked at what's in there. Thing is, you can fake a version string very very easily, but you cannot modify an executable and have it produce the same checksum; it just doesn't work.

So that's something that only the BOINC devs could do - unless they already have. It's way easier to track lots of different versions by their checksum. The only question is, what or who calculates the checksum? Currently, I don't think this is implemented anywhere, but it should be relatively simple to code.

Regards,
Simon.

---

Greetings,

Jord, Simon - and thank you for showing an interest in this concept!

The only question is, what or who calculates the checksum? Currently, I don't think this is implemented anywhere, but it should be relatively simple to code.

There are a number of standard utilities to generate/calculate and check checksums.

One could use any one of these to do so.

If a developer donates a client to the list, along with its checksum, and says that (s)he used "this" utility to generate the checksum, all we'd have to do is run the same utility on the source to generate the checksum - if they didn't match... ;)

Apart from this, one could generate checksums for a client using all the main utilities for doing so - this would ensure that we'd know all the possible checksums for a client: no-one could claim that we've used the wrong utility if our checksum doesn't match theirs.

As you say, Simon, it's practically impossible to "fake" a checksum.

Using a utility, like md5sum, you can check the checksum for a file to verify that it is the genuine one and has not been replaced or tampered with. This is one very useful security measure when authenticating OS files to ensure they have not been changed in any way by malware, etc.

Kindest regards,

Dragan Glas
Team CastleCops Chief Host
http://www.castlecops.com

---

Presumably the code to compare the checksum with the executable would be held in the executable itself? (i.e., in the core client or the boinc manager). This would be a potential security hole.

---

I thought about it some more and you're right, Mike.

It's not the simplest of tasks to ensure it can't be tampered with.

One possible solution would be to use an extra commandline utility that has a known checksum. Then every time BOINC communicates with the server, it can be passed the checksum to the currently used checksummer, which then proceeds to check itself for validity. Should the file have been tampered with, a fresh copy is downloaded, and the checksum for BOINC is calculated and transmitted on the next update, along with a "I have been tampered with" message, maybe. BOINC could also lock this file (so it cannot easily be overwritten while BOINC runs).

Should be implementable, though it may need some testing.

Regards,
Simon.

---

The other hole is that the benchmark figures are currently held in an XML file, which can be edited. This is what some of the credit cheaters do (so even perfectly valid versions of Boinc can be used to inflate credit). The sooner projects move away from benchmark based credits, the better, as far as I'm concerned.

---

Greetings,

Simon and Mike(?) - I'm James, by the way - thank you again for your ideas.

Perhaps a few observations of my own might help...

1) Checksums for clients
If we take Windows as an example.

Let's say I have a Windows file, which I'm not sure is the real thing - it has the same name as a legitimate file but there's something funny going on...

I can run this file through md5sum - right click on the suspicious file and choose md5sum, which effectively starts up the latter with the former as the parameter.

md5sum calculates a checksum for it.

I then go to the Microsoft site and look for the filename/version and see what the checksum should be.

If the MS one matches the one md5sum calculated for my version of the file, then it's legitimate.

As you can see, there's no checksum held within the file itself - that's calculated by running it through md5sum.

The same would be the case for the BOINC client - the valid checksums for the various clients would be held on the BOINC server against which a user can check their md5sum-generated checksum and validate that his/her client is what it claims to be. [Not a (disreputable) substitute with the same name as a real client.]

So, all (BOINC) clients' checksums are held on the BOINC site server(s).

A user, wishing to ensure that their one is legitimate, runs the client on their system through md5sum.

They then check the generated checksum against the valid checksum on the BOINC site - if they match, their client is what it claims to be; whether a "good" one or a "bad" one, is another matter! ;D

There is no need to "store" a value within the client itself.

Nor is there any "code" within the client to calculate it's own checksum - that's done by another program external to it.

In fact...

What if the user could validate their client at the BOINC site?

This way, the checksummer is on the site, not on a user's system. The user runs their client through the site's checksummer - much like one can go to a AV site and have a file scanned by the site's scanner - and is then told if it's what it claims to be.

The site could also tell the user if this is a "good" or "bad" client (reputable or not).

One last point about checksums: from what I know, the SHA256 algorithm is reputed to be better than md5 - it's said there's a lesser probability of "collisions" (randomly generated hashes which happen to match).

2) Altered/replaced files outside the client
The point about benchmark-based credits is a valid one.

The only problem is that any measure of "work" can be inflated through the use of a multiplier - just as does the title of this topic.

We've already dealt with the client itself misreporting figures - "good" (reputable) ones won't!

This section deals with data held outside the client being tampered with - such as benchmark data held in a editable XML file.

(a) the only measure of work done should be flops/cpu cycles;
(b) this data should be encrypted to prevent tampering by a user through a public/private key encryption system.

Let's say all three of us download the SETI client.

Each of us gets the public key for this client - of which there is only one for each version of the SETI client. The private keys(!) are held on the BOINC server. There is one private key for each user of the client version - each one of us has a private key associated with our individual client-version.

None of us could tamper with the client and/or the encrypted Work-Measure Data as we don't have our client's private key.

This would mean that the client is generating the data within a "black box".

The BOINC site would be generating the sort of charts that appear in peoples signatures - the sites which currently do so would not be able to as they can't access the encrypted WMD(!) ;D

Hence, third-parties have no ability to misreport work - even at this stage of the process.

Any thoughts on the above?

Kindest regards,

Dragan Glas
Team CastleCops Chief Host
http://www.castlecops.com

---

The only problem is that any measure of "work" can be inflated through the use of a multiplier - just as does the title of this topic.

This can't be done with climateprediction, because there it's determined by a discrete unit of work being done, i.e. a trickle.
Either you return a trickle of work, or you don't.

Greetings,

Thank you, Les - that's good to hear! ;D

Perhaps BOINC needs to decide on which methods of reporting "work" are acceptable - so that misreporting, whether by the ("bad") client and/or by editing data files, can't occur?

There needs to be a concerted shift away from the fixation on stats.

The stats may be nice to watch how you're doing, but people choose projects which appeal to their conscience and humanity - not which clients can ramp them quickest up the "league table"!

The clients need to be:

1) Reputable;
2) Stable

Why that order?

If the client is not "reputable" (reports work honestly), there's no point wasting developers' time and energy in working on its stability.

Kindest regards,

Dragan Glas
Team CastleCops Chief Host
http://www.csatlecops.com

---

Mail from David Anderson:

Here's a road map for improving the credit system:

1) near term: add support for "benchmark workunits".
The time it takes to machine to finish the benchmark WU
determines how much credit per CPU second it gets for subsequent WUs.
If all projects use this, we can get rid of CPU benchmarking
in the core client (which is the root of many problems).

2) longer term: add support for project-defined "credit pricing".
This lets project say how they want to assign credit,
e.g. a host with 4 GB RAM gets twice the credit per CPU sec
of a 1 GB machine.
Or credit for long-term disk storage.
Or they can give credit for non-computation stuff like
recruiting participants or doing good message board posts.
The only restriction is that the maximum possible credit per computer-day,
averaged over all computers currently participating in any BOINC project,
is 100 (or some constant).

-- David

---

As Dragan Glas pointed out,

There needs to be a concerted shift away from the fixation on stats.

Allow me to quote another of the Team CastleCops participants, with emphasis added.

I'll comment on the stats themselves. Personally, I appreciate all the effort being put into the stats and find them interesting and encouraging. The fact that in the early stages of folding, a person can gain a lot of spots in the rankings and receive a bit of mention might just be the incentive they need to keep on folding. As I climb in the rankings, I can see that in a relatively short time I will be in a position that I will only "move up" over a longer period because the point differences get much larger. By the time someone reaches this point, hopefully they will be firmly entrenched in folding and comfortable with the program on their computer(s) enough that they will have long since grown to appreciate the importance of the project much more than any personal recognition or statistical growth. The milestones may be less frequent, but perhaps more satisfying.

While the above comment was made with respect to Folding@Home, it is equally applicable to any and all of the BOINC science projects.

Indeed, the manifest "fixation" on credits earned do a grave disservice to science, to the individual projects, and to BOINC as a whole. The pursuit of science is a continuing quest for new knowledge and coherent understanding. Dissemination of that new knowledge and understanding is an integral component of scholarship.

With these thoughts in mind, I have considered other measure--in addition to the stats--that might be utilized to follow the progress of the projects: measures that would be particularly significant for dedicated, experienced participants, and for participants, and potential participants, that are truly interested in the science itself.

Some possible measures are:

1. Peer reviewed publications, particularly ones that explicitly acknowledge the contributions of the distributed computing participants.
2. Literature citations of the research group's publications.
3. Conference presentations.
4. Seminar presentations.
5. Graduate degrees (Masters and PhD) granted that utilized the results from the distributed computing participants.
6. Grants awarded or renewed to fund the research projects.
7. Reputable science-media coverage of the research projects.

BOINC is the most logical place to serve as a centralized repository of such information as it is supplied by the individual projects. The agencies (for example, NSF and MPG) that financially support the individual projects require periodic progress reports from the Principal Investigators. BOINC participants also provide vital support to these projects and equally deserve periodic progress reports that far transcend accumulated credits.

Lets keep in mind
1) That an over-clocked machine often gets cheated- It finishes to quickly and the slower machines win the vote.
2) All optimized apps are not just increasing benchmark scores- compiling the SETI app with the Intel ICC compiler, using in the performance math libs cuts the WU processing time by better than 30% in my experience.
3) The benchmark scores are fairly bogus. A) The Windows version starts the benchmark thread running and then drops it's own priority. The Linux version uses a "fork" command to start the thread which gives it the same priority as the parent. B) The Windows clock that they are using is not that good, it rounds everything off to the nearest 30 mSec period, where as Linux is about 1 mSec in most cases. C) I you compare the Boinc benchmark scores to Sandra (Windows) or UnixBench (Linux) you will find all sorts of different answers to what the computing power is.
4) That being said, I did download an optimized 5.9.0 Client from the web that reported crazy high (2x-3x) benchmark scores. If that is what the scores should be , fine, but they are "out of line" with the main-stream so far that I deleted the apps and built my own, optimizing the compile of the Berkeley code. That reports just slightly higher than the "stock" version, which is what I would expect.

---