= User Opt-in Consent = The [https://en.wikipedia.org/wiki/General_Data_Protection_Regulation 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 [wiki:TermsOfUse '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 [wiki: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 [wiki:TermsOfUse] mechanism. Thus when a user creates an account, s/he does not see any terms of use, even if it exists. == Technical Implementation == === Project config === A new project option will be included in `config.xml` for projects, `enable_record_optin_consent` option. This flag would toggle whether or not the project records the consent of users: basically it would toggle using this new feature. The default is false, or disabled. === Database === Two new tables: `consent` and `consent_type` * `consent` * `id` - primary key of table - a unique id for each row. Not used for the consent functionality. * `userid` - the user id * `consent_name` - consent name, corresponds to the 'shortname' in `consent_type` below. * `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. * `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 * `consent_type` * `consent_id` - consent id, also the primary key. * `shortname` - consent name, these should be short and in ALLCAPS, e.g., ENROLL, STATSEXPORTS, etc. * `description` - text field describing the consent that user gives (or has given). * `protected` - if true, this consent type is introduced by BOINC upstream. If false this consent type project-specific, and was added by the project via the ops pages. ==== 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 two record in `consent_type`: the main terms-of-use a user consents to when joining the project and a stats-exports consent type. 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_name`, whose description is stored in the `consent_type` table. The `protected` field indicated a consent type that is introduced by BOINC upstream for all projects. Re: `consent` table Entries to this table are to be inserted for a `userid` and `consent_name`. This way a single user may consent to multiple policies. If a user withdraws consent, a new entry should be added. Effectively, no rows should be deleted from this table, only added. There may be a situation where a user has dozens of rows since s/he has given and withdrawn consent multiple times. This acts as a record of the user's consent to policies. The latest row, that is the row with last datetime, represents the current consent status. The exception is when a user deletes his/her account. Then all `consent` table entries for that user's id are deleted. === 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_name` = 'string' - This is the shortname of the consent_type to insert a new entry for. * `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 is used to insert a new record into the `consent` table, but only if all four of these additional parameters are present. If one is not present, the `consent` table will not be modified. However, the RPC will not return a failure. This is to ensure backwards compatibility. If all four parameters above are set, as below, then the RPC will insert a new entry into the `consent` table. Example: {{{ am_set_info.php?consent_name=ENROLL&consent_flag=1&consent_not_required=0&consent_source=accountmanager }}} The RPC is attempting to set the consent information for a `consent_name` of ENROLL. It will check of consent_name ENROLL exists. If it does not an error message will be returned. === 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 [wiki: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 [wiki: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 shown 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)