diff --git a/checkin_notes b/checkin_notes index cb0c329bbc..dc4ac95589 100755 --- a/checkin_notes +++ b/checkin_notes @@ -5744,7 +5744,7 @@ Karl 2003/08/14 _autosetup, aclocal.m4, config.h.in (added) depcomp, install-sh, missing, mkinstalldirs (added) */Makefile.am, */Makefile.in (added) - */Makefile + */Makefile (removed) client/ ap_file_io.C diff --git a/doc/backend_functions.html b/doc/backend_functions.html index 2a6eee1a35..f47d8a0029 100644 --- a/doc/backend_functions.html +++ b/doc/backend_functions.html @@ -28,13 +28,13 @@ and the policy for deciding which are correct, are project-specific.

  • Grant credit. -Some users will attempt to get undeserved credit -by falsifying their CPU metrics or CPU times. -The back end -finds the minimum reported credit for the correct results of a given workunit, -and assigns this amount of credit to all the correct results. -This ensures that as long as a reasonable majority of participants -don't falsify credit, almost all credit accounting will be correct. + Some users will attempt to get undeserved credit by falsifying their CPU + metrics or CPU times. Each project and application can have its own + credit-granting algorithm, for example granting the minimum or the mean of + the median of all claimed credits (during validation time). The granted + credit is assigned to all correct results. This ensures that as long as a + reasonable majority of participants don't falsify credit, almost all credit + accounting will be correct.

  • Assimilate results.

    diff --git a/doc/security.html b/doc/security.html index 1af8168139..c5d09af935 100644 --- a/doc/security.html +++ b/doc/security.html @@ -1,9 +1,9 @@ -Security +Security -

    Security

    +

    Security

    Many types of attacks are possible in public-participation -distributed computing. +distributed computing.

    -BOINC provides mechanisms to reduce the likelihood of some of these attacks. +BOINC provides mechanisms to reduce the likelihood of some of these attacks.

    -Result falsification +Result falsification

    This can be probabilistically detected using redundant computing and result verification: if a majority of results agree (according to an @@ -50,7 +50,8 @@ application-specific comparison) then they are classified as correct.

    This can be probabilistically detected using redundant computing and credit verification: each participant is given the minimum credit from -among the correct results. +among the correct results (or some other algorithm, such as the mean of the +median claimed credits).

    Malicious executable distribution

    @@ -75,7 +76,7 @@ The core client will accept a new key only if it's signed with the old key. This mechanism is designed to prevent attackers from breaking into a BOINC server and -distributing a false key pair. +distributing a false key pair.

    Overrun of data server

    @@ -86,7 +87,7 @@ The public key is stored on the project's data servers. Result file descriptions are sent to clients with a digital signature, which is forwarded to the data server when the file is uploaded. The data server verifies the file description, and -ensures that the amount of data uploaded does not exceed the maximum size. +ensures that the amount of data uploaded does not exceed the maximum size.

    Theft of participant account information by server attack

    @@ -100,7 +101,7 @@ Projects should be undertaken only the organizations that have sufficient expertise and resources to secure their servers. A successful attack could discredit all BOINC-based projects, and -public-participation computing in general. +public-participation computing in general.

    Theft of participant account information by network attack

    @@ -109,7 +110,7 @@ public-participation computing in general. The input and output files used by BOINC applications are not encrypted. Applications can do this themselves, but it has little effect since data resides in cleartext in memory, where it is easy to access -with a debugger. +with a debugger.

    Intentional abuse of participant hosts by projects

    @@ -117,7 +118,7 @@ with a debugger. BOINC does nothing to prevent this (e.g. there is no "sandboxing" of applications). Participants must understand that when they join a BOINC project, -they are entrusting the security of their systems to that project. +they are entrusting the security of their systems to that project.

    Accidental abuse of participant hosts by projects

    @@ -126,4 +127,4 @@ The chances of it happening can be minimized by pre-released application testing. Projects should test their applications thoroughly on all platforms and with all input data -scenarios before promoting them to production status. +scenarios before promoting them to production status.