wiki:UserOptInConsent

Version 11 (modified by skwang, 3 years ago) (diff)

--

User Opt-in Consent

The European GDPR law requires users to opt-in to a terms of service. "Users who want to sign-up to a (BOINC) project need to give their informed explicit consent to how the project processes their data, before any personally identifiable information about that new user gets processed/stored by the project. This opt-in statement of consent then needs to tracked by the project as proof."

Additionally, existing users will need to opt-in to the same terms of service, with their consent date saved.

User Experience

When using the main BOINC manager to join a project (Add Project), the user is shown a Terms of Use / Porject policy text. S/he must accept the terms of use before the account is created. As part of the account creation process, the date-time of this consent is recorded in the project's database.

For account managers, AM can download a site's terms of use from get_project_config.php. Then present this to a user. It will be the responsibility of an AM to present the text along with a checkbox for the user to opt-in. (It must not be passive.) The create_account.php RPC will be modified slightly for AM to set a consent flag. Additionally, the am_set_info.php RPC will be modified to allow AM to update the a user's consent information.

For Web registration, the login page can provide the terms of use text. Users will have to accept the terms of use before creating an account.

Existing code

As of April 2018, BOINC already contains a 'terms of use' mechanism for the BOINC client when creating a new account. If the file 'terms_of_use.txt' (filename is hardcod-ed) is in the root of the project directory, the contents of the file will be presented to the user when s/he creates an account. However, there is no persistent 'storing' of the datetime the user consented to the terms of use.

For Web registration, the code does not use the TermsOfUse text. But it can be modified to do so.

Additionally, it is not known whether account managers, such as BAM!, use this terms-of-use mechanism.

boinccmd command-line client does not use the TermsOfUse mechanism. Thus when a user creates an account, s/he does not see any terms of use, even if it exists.

Technical Implementation

Database

Two new tables: consent and consent_type

  • consent
    • userid - the user id
    • consent_id - consent id
    • consent_time - datetime type attribute : unixtime of when user id gave consent to consent_id. If zero, user has not consented (yet).
    • consent_flag - the boolean which explicitly stats that this user id has given consent to this consent id. If this is 0 (FALSE), the following boolean should be 1 (TRUE).
    • consent_not_required - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special ...
    • source - text field containing the technology actor which the user gave consent. See below

userid and consent_id together make up the primary key of this table.

  • consent_type
    • consent_id - consent id, also the primary key.
    • description - text field describing the consent that user gives (or has given).

Discussion

Some discussion on source string.

Examples

  • If a user gives consent by registering for an account using the BOINC GUI client (BOINC manager), source would be set to 'client'.
  • If the account is created on a Web site registration page, source would be set to 'web'.
  • Account Managers should put their name in, e.g. source = 'BAM!' or source = 'GridRepublic?'.
  • command-line client uses 'boinccmd'.
  • In the case where source is not specified (but consent is being used) then a default source of 'URL' will be used.
    • 'URL' represents the fact that a user can create an account using the RPC by typing the correct parameters into the URL bar of a browser, or using a command line tool such as curl.

Re: consent_type table

At first there will be one record in consent_type: the main terms-of-use a user consents to when joining the project. The consent table uses id and consent_id as the primary key, so a single user may consent to multiple items. This allows for flexibility - a project may decide to present a user with multiple items to consent to. Each can be recorded in the consent table with a different consent_id, whose description is stored in the consent_type table.

Currently when a project is created, or updated to the latest database schema, the consent_type table will be:

SELECT * FROM testp1.consent_type\G
*************************** 1. row ***************************
 consent_id: 1
description: General terms-of-use for this BOINC project.

This consent type #1 should not be modified or deleted by projects!

Project config

A new project option will be included in config.xml for projects, a enable_record_optin_consent tag. This flag would toggle whether or not the project records the consent of users: basically it would toggle using this new feature.

RPC

RPCs that will need to change:

  • create_account.php
  • am_set_info.php

The main RPC that needs to be changed is create_account.php, which needs to insert a record into the consent table when the user creates his/her account- assuming s/he consents to a site's terms of use.

Additional parameters for create_account.php RPC are

  • consent_id = 'integer' - optional, defaults to 1 unless specified. If given a consent_id that does not exist in the consent_type table, then the RPC will return an error.
  • optin = 0|1 - If true, sets the consent_flag to 1. If false the consent_flag is set to 0 and consent_not_required is set to 1. See discussion of anonymous accounts above.
  • source = 'string'
    • example: 'client', see above discussion about source for more details.

am_set_info.php needs to be modified in order to contain a consent parameter, which also modifies the consent table in the database.

Additional parameters are

  • consent_id = 'integer' - required if any of the below are to be set. If this parameter is not present, the consent table will not be modified.
  • consent_settime = '0|1' - sets the consent_time to the current unixtime.
  • consent_flag - '0|1' - sets the consent_flag to 0 or 1.
  • consent_not_required - '0|1' - sets the consent_not_required flag to 0 or 1.
  • consent_source - 'string'
    • example: 'client', see above discussion about source for more details.

am_set_info.php can be used to update the consent table or to insert a new record. The user and consent ids are used as the primary keys of the consent table. Thus if both are given and found in already, the RPC will update the fields with the other consent_ parameters. Likewise if this is a new row, then the RPC will insert a new record into the table using the fields. Note: if inserting a new record the RPC will first check to see if the consent_id exists in the consent_type table. If not an (-1) XML error will be returned. If the consent_id does exist, the insertion of a new record requires the following parameters consent_id, consent_flag, consent_not_required, and consent_source. If any of the four are not present, an error is returned. The consent_settime boolean is ignored. The record is inserted with the current unixtime.

Example:

am_set_info.php?consent_id=99&consent_flag=1&consent_not_required=0&consent_source=accountmanager

The RPC is attempting to set the consent information for a consent_id of 99. First the consent table is checked with the userid corresponding to the authenticator and the consent_id. If a record is found, it is updated with the parameters in the RPC: e.g., flag, not_required, source.

If no record is found in consent, the consent_type table is checked to see if there a id of 99. If there is not, an error is returned.

If there is such a consent_id==99, then the RPC will insert consent_id=99 and userid (from authenticator) into the consent table setting the additional parameters: e.g., flag, source.

Web site

The Web site account registration page will have a new panel that includes the terms of use text. This will be the same text file as TermsOfUse. The text file is processed with PHP's nl2br() function in order to format the plain text into text that is readable in HTML. Admins should not put HTML tags into the plain text TermsOfUse file.

The registration page will have an additional checkbox that requires a user opt-in to the terms of use. If this is not checked, the account will not be created, and an error hsown to the user. Only when the checkbox is checked, will an account be created. A new record will be inserted into the consent table, in the same manner as the create_account RPC.

Anonymous Accounts

(to be written)