Stories
Slash Boxes
Comments

SoylentNews is people

Meta
posted by cmn32480 on Friday February 12 2016, @04:34PM   Printer-friendly
from the oragami-it-ain't dept.

I've taken the liberty of setting up an official folding@home team for Soylent News. In case you aren't familiar with folding@home, it's a distributed computing project that simulates protein folding in an attempt to better understand diseases such as Alzheimer's and Huntington's.

There is more information on the project here, which explains it much better than I could.

Clients are available for Linux, OSX, and even Windows (if you swing that way), so come join our botnet!

That Other Site's team is ranked at 1817, so we've got some catching up to do.

On a personal note, my Dad carries the gene markers for Huntington's disease, and will eventually succumb to it. Research like this is very helpful for understanding, and hopefully developing treatments for it.

tl;dr Our Soylent News team ID is 230319


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by q.kontinuum on Saturday February 13 2016, @09:45AM

    by q.kontinuum (532) on Saturday February 13 2016, @09:45AM (#303617) Journal

    That's not entirely comparable. When I download a browser, I can trust a signature of the binary (or, when I build from source, the hashes of the git repository). The trust is based on the fact that some more or less high-profile people publish their keys and vouch for the software with their good names.

    In an interactive online project with thousands of anonymous participants, the situation is different. If the key is part of the OSS-package, it can be extracted and used to sign falsified data. If the key is generated for each user, there is no base to trust this signature since $evilperson can generate a signature just as valid.

    That said, the concept they seem to employ here is security by obscurity, which is usually discouraged. I still think the only solution is to have some other kind of verification for the data.

    --
    Registered IRC nick on chat.soylentnews.org: qkontinuum
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by maxwell demon on Saturday February 13 2016, @12:51PM

    by maxwell demon (1608) on Saturday February 13 2016, @12:51PM (#303656) Journal

    The software would still come from a central repository with the maintainers having tight control of what does or does not go into the code. They would certainly not distribute the keys any more than they are distributed for Linux.

    I certainly would hope they verify their data. After all, intentional tampering is not the only way the data could get corrupted. The typical way to do this is to send the same work package to several clients, and compare the results. But there may also be checks that are less computationally expensive than doing the complete calculation again. I didn't check what they actually calculate, but if, for example, the algorithm is an iteration converging to the correct solution, then running the iteration step just once should be sufficient to check whether the iteration really converged.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 2) by q.kontinuum on Saturday February 13 2016, @02:41PM

      by q.kontinuum (532) on Saturday February 13 2016, @02:41PM (#303676) Journal

      The software would still come from a central repository with the maintainers having tight control of what does or does not go into the code.

      ... which is a valid argument when you want to protect the user. But not when you want to prevent the user to modify the SW in order to receive higher scores with questionable data.

      They would certainly not distribute the keys any more than they are distributed for Linux.

      That would be different key of course. The binary is signed by the SW distributor, the returned data might be signed or encrypted by the SW running on the users computer and would need another key for that as well.

      I certainly would hope they verify their data. After all, intentional tampering is not the only way the data could get corrupted.

      For that a hash sum should suffice.

      The typical way to do this is to send the same work package to several clients, and compare the results. But there may also be checks that are less computationally expensive than doing the complete calculation again. I didn't check what they actually calculate, but if, for example, the algorithm is an iteration converging to the correct solution, then running the iteration step just once should be sufficient to check whether the iteration really converged.

      Basically my point: Arguing to avoid tempering by keeping the source closed is arguing for security by obscurity, which is wrong. Nevertheless the situation is slightly different from the case where the user is the one being protected, and the arguments need to be refined.

      Nitpick: Checking convergence might not be enough, since the user could also just "optimize" his version by running less iterations. But if the algorithms contain operations with properties like e.g. Prime-factorization, as in operation is way more expensive than reverse operation, the check might be simple, safe and cheap.

      --
      Registered IRC nick on chat.soylentnews.org: qkontinuum