EU-GDPR - User consent

[brevilo]

On May 25th, 2018 a new General Data Protection Regulation (GDPR) is going to be effective in the EU. While most of its legal requirements only affect the projects themselves, at least one part affects BOINC directly - the sign-up process. As of that day users who want to sign-up to a 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.

Given the current way the BOINC Manager/Client project sign-up workflow is done, I think that (at least) all EU projects are basically forced to disable client-based login and only allow a (customized!) web sign-up process until the missing features got added. In order for BOINC being GDPR compliant I think the following needs to be changed (first rough sketch):

• During sign-up, request the project specific declaration of consent and checkbox label (see below) from the project (additional RPC) and display it to the user (multi-language support required, i.e. add language code to request)
• That dialog should support HTML such that links to, say, the external privacy policy could be included in the text
• Add an opt-in checkbox showing the label requested above (again, with link support)
• Allow sign-up only when checkbox is selected and transmit that as an additional boolean attribute in the account creation RPC
• Add an additional date type attribute privacy_consent_dt to the user table
• Store the datetime of the user's consent in the new attribute

The standard BOINC web interface also needs to support equivalently the above workflow. It might even be the case that we're required to get this consent from existing users as well, so the web interface should make the consent from equally available outside of the sign-up process (for a logged-in user in this case). We're already working on incorporating the necessary changes to the Drupal web interface.

Note to all account managers: you should be affected in the same way as the BOINC client!

[AenBleidd]

Correct me if I wrong but these changes mean that there will be no backward compatibility with old clients and there will be no possibility to attach to the project using old client? I think this will be a great issue for Android application and probably Raspberry Pi (as I can see Raspbian has 7.0.27 boinc client version only).

[tristanolive]

I think old clients could only attach to existing accounts, in that case. It might be possible for an attach error to include information about how to go to the project and create an account manually; or perhaps projects could create limited or disabled accounts in these situations that require manually logging in at the website in order to accept terms & conditions and activate the account.

[brevilo]

Correct, old clients mustn't be allowed to attach (read: create a new account) to any EU project - it's legally impossible.

think this will be a great issue for Android application

How's that different from the client or webpage? It also needs to be updated in a similar fashion as it's just another client (I already had tagged this issue accordingly).

[brevilo]

It might be possible for an attach error to include information about how to go to the project and create an account manually

That's the workaround we're going to implement as long as this very issue isn't resolved.

or perhaps projects could create limited or disabled accounts

That's highly unlikely since you're not allowed to store any personal information without prior consent. The only way this might be doable would be to create such an account and only store a random token in the user table. That token could be returned to the user and then later on be used to complete the sign-up via the webpage. But honestly, does that really gain you anything in terms of usability?

[tristanolive]

It depends on how clunky the workaround would be. If it's a generic error message without a link or anything in it, there may be some value in attaching a host in a limited way so that it can receive a notice from the project that says, "We need your consent to begin work on this project, click here!" That could potentially take the user directly to a registration form, complete with checkbox for meeting state regulatory requirements.

[brevilo]

I think, however, that the implementation of this would require an amount of work that's not significantly less than what's required to implement the actual solution. That's why I don't think this can be a viable workaround.

[RichardHaselgrove]

This discussion does tie in quite nicely with the new auto-attach facility being tested - in a very low-key way - with the next v7.10 of the BOINC client. But so far only one project (SETI@Home) and one forthcoming Account Manager (Science United - not yet released to the public) have been announced as ready for auto-attach.

Auto-attach implements the 'registration via project website' process being discussed here, but so far the SETI registration page hasn't been updated with the EU-GDPR requirements: I haven't looked at the SU registration page to assess compliance. And of course complying via auto-attach would require action by each and every participating public BOINC project.

[JuhaSointusalo]

There is an older issue about this #2332 although it is pretty light on content.

Projects can already request volunteers to accept terms of use before attaching to the project with Manager. TermsOfUse

Using that makes the Manager display following page after selecting project and before asking for account info:

HTML or links or anything else is not supported, just plain text. Translations aren't supported either. Peeking at code Android GUI seems to have something similar.

The project is not informed about the fact that the volunteer accepted the terms. And boinccmd can create accounts but I don't think it knows anything about terms. So the current implementation is a starting point at most.

I think @davidpanderson has had some thoughts about the usefulness of Manager creating accounts. The Manager, or the create accout RPC, does nothing to stop spammers from using it. One also can't use, say, Facebook or Google credentials to create an account.

[JuhaSointusalo]

@brevilo's opening post might make this sound like it applies to only EU based projects but I think it applies to all public BOINC projects. From the Wikipedia page: "The regulation also applies to organisations based outside the EU if they collect or process personal data of individuals located inside the EU." Public BOINC projects are open to volunteers worldwide, including EU.

[tristanolive]

Good find with the Terms of Use feature. Between that and auto-attach, there is a pretty good foundation to build on.

I think that point about GDPR application on the Wikipedia page is poorly worded. The EU has no regulatory authority over IBM in New York, for instance; they could just make life difficult for any IBM presence in the EU, if WCG refused to comply. I'd expect the same to be true of any public BOINC project outside of the EU, except most would not have any sort of international presence in the EU, so it would not be an issue for them.

[brevilo]

Thanks @JuhaSointusalo, that's really helpful.

[brevilo]

Since the terms of use feature is part of the get_project_config() RPC, does anyone know whether the various account managers out there integrate it as well?

[tristanolive]

No integration in GridRepublic or Charity Engine, but that could be very useful if projects report this compliance requirement in such a way. Account managers could then present users with a checkbox for granting explicit consent to the terms of use of the project, if needed.

[drshawnkwang]

I started writing a Design Document on the BOINC wiki - UserOptInConsent. It has a basic outline of what needs to be implemented.

The most important part - which is 'under the hood' is the database change to the user table adding an additional field to store the datetime the user has consented to the project's terms of use, privacy_consent_dt

Web and client implementation will build on this additional field.

[lfield]

Opt-in to the data export should also be included. This could be an option in the user preferences but may also need a flag in the user table.

[drshawnkwang]

@brevilo , that's a good question on whether or not projects need to (or just should) separately keep track of the datetime of opt-in of the data export preference.

I would think as long as the data export option is clearly spelled-out in the project's terms of use, then we only need to keep track of the initial datetime the user agrees to the overall terms-of-use. And then the user can toggle the data export preference as s/he sees fit.

Another way to saying the same thing: what would a project do with this piece of information- the second datetime of when a user opts-in to the data export preference?

[drshawnkwang]

After talking with @brevilo offline we came up with the following ideas that I'll put into the Design Document.

Instead of altering the user table, we will instead create a two tables: consent and consenttype. This table will have the following fields: id, datetime, and consentid (these names could change). This table will keep track of when a user consented to a certain policy, whether that be a general terms-of-use, or a data export preference, etc.

The consentid field can be used to match a new consenttype table, which contains consentid, description. The latter is a free-text field which has a description of what the user consented to.

This structure gives projects much more flexibility to record the consent of the users to a project different terms-of-use.

Additionally, a new project option will need to be included in config.xml for projects, a use_consent_table flag (name TBD). This flag would toggle whether or not the project records the consent of users: basically it would toggle using this new feature.

[tristanolive]

There is another "state of consent" to consider, which is consent given by an account manager on behalf of an end user. This could come about through a general consent release that the user gives the account manager and then the account manager would pass that consent to projects, as needed.

Further along those lines is the concept of anonymous accounts. An account manager can attach an end user to a project without giving that project any personally-identifying information. One possible breach of anonymity comes when the end user's host connects to the project server, as the IP address of the host is exposed to the project at that point (and the project logs it). However, barring that potential breach, it may be that anonymous accounts are exempt from the requirement of giving consent in order to participate in project work.

[davidpanderson]

I just changed Science United to create anonymous accounts; this simplifies things in general.

Host IP address and domain name are used to identify hosts to their owner; I think we need to keep them. But they can be erased if the user wants

On Fri, Apr 27, 2018 at 10:07 AM, tristanolive notifications@github.com wrote:

There is another "state of consent" to consider, which is consent given by an account manager on behalf of an end user. This could come about through a general consent release that the user gives the account manager and then the account manager would pass that consent to projects, as needed.

Another thing to consider is the concept of anonymous accounts. An account manager can attach an end user to a project without giving that project any personally-identifying information. One possible breach of anonymity comes when the end user's host connects to the project server, as the IP address of the host is exposed to the project at that point (and the project logs it). However, barring that potential breach, it may be that anonymous accounts are exempt from the requirement of giving consent in order to participate in project work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2413#issuecomment-385033742, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8KgV96bTYypf0rXG8-CAuKSc6HNpkqks5ts1A_gaJpZM4Sscdo .

[JuhaSointusalo]

What about BOINC-wide teams? team_import.php automatically creates an account for team founder, no consent asked.

The account data includes user name and email address so consent is needed. On the other hand, the whole purpose of BOINC-wide teams is to automatically create accounts.

[davidpanderson]

I think we explain things on the BOINC-wide teams site. The team creator may need to log in to each project to manage the team.

On Mon, Apr 30, 2018 at 1:39 PM, Juha Sointusalo notifications@github.com wrote:

What about BOINC-wide teams http://boinc.berkeley.edu/teams/? team_import.php https://github.com/BOINC/boinc/blob/master/html/ops/team_import.php automatically creates an account for team founder, no consent asked.

The account data includes user name and email address so consent is needed. On the other hand, the whole purpose of BOINC-wide teams is to automatically create accounts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2413#issuecomment-385521558, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8KgXv5I_qtag19MUbu2kdCwsg8b6Mjks5tt3ZrgaJpZM4Sscdo .

[drshawnkwang]

@JuhaSointusalo , thanks for informing me about BWTs.

My first thought is that I am introducing a new project config.xml boolean parameter: enable_record_optin_consent. The team_import RPC could be setup to not create the user's account if this parameter is set to TRUE, because of the need for the user to opt-in to the terms of use. However, this would be confusing as it would create an account on some projects and not others.

I think David is right, we will need to change the paradigm of BWTs to not create the user for each project. This involves disabling the make_user part of the import_team RPC. But this snowballs into the problem: you can't create a team on a project without a user. Thus one would have to diable the whole team_creation functionality. This of-course defeats the purpose of BWT, if you can't create the team on multiple projects! So I am not sure on the ideal course of action.

@tristanolive & @davidpanderson : I think the idea of an anonymous account would be good. The sticky detail is the host IP. Because GDPR requires consent when any type of personal information is given, I don't know of a way around having the user give consent.

Assuming that anonymous users are okay, we could use the consent table fields consent_flag and consent_not_required in a specific way:

• set consent_flag = 0
• set consent_not_required = 1

(The typical user when creating an account and consenting to the terms of use is given consent_flag=1 and consent_not_required=0.)

[davidpanderson]

Don't record IP or domain info for hosts w/ anonymous accounts.

[JuhaSointusalo]

About BWTs, I agree that BWT website explains how they work well enough. But I'm not a lawyer or GDPR expert.

@davidpanderson

Since you say SU is now creating anonymous accounts. What is an anonymous account? How they differ from normal accounts? How can I tell that an account is anonymous?

Also, just pointing out. Scheduler records IP address of incoming request in log. That's more or less temporary recording. I imagine it would be considered similar to the logging web servers do.

[davidpanderson]

For an anonymous account: email is su_(random string)@nonexistent.domain name is "Science United user (random string) password hash is random string.

This is my convention. If there are other uses for anonymous accounts, I suggest using the email addr convention.

On Wed, May 2, 2018 at 9:19 AM, Juha Sointusalo notifications@github.com wrote:

About BWTs, I agree that BWT website explains how they work well enough. But I'm not a lawyer or GDPR expert.

@davidpanderson https://github.com/davidpanderson

Since you say SU is now creating anonymous accounts. What is an anonymous account? How they differ from normal accounts? How can I tell that an account is anonymous?

Also, just pointing out. Scheduler records IP address of incoming request in log. That's more or less temporary recording. I imagine it would be considered similar to the logging web servers do.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2413#issuecomment-386035717, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8KgULPzRIBbyIaFji4ZxrKoIEivXqKks5tudyYgaJpZM4Sscdo .

[drshawnkwang]

re: anonymous accounts. If possible we should remove the last two octets from an IP (v4) address, e.g. 192.168.0.0, at least in the project database. This would anonymize things and help us with the GDPR requirements. There will still be Web server logging of IPs, e.g., apache, but these are often temporary (log rotated).

We should create a new Github ticket about Anonymous accounts. The User Opt-in code will have support for it (see https://boinc.berkeley.edu/trac/wiki/UserOptInConsent)

[brevilo]

I agree that BWT website explains how they work well enough

Having some explanation somewhere doesn't make it legally sufficient, unfortunately. The problem is that the data controllers (the individual projects) are responsible to get each user's informed consent. Any (non-anonymous) account that gets created automatically/remotely violates that. Also, consent needs to be given to each individual project's terms of use or privacy policy. Otherwise a project can't even assert what the user gave consent to.

remove the last two octets from an IP (v4) address, e.g. 192.168.0.0

I recommend to use 192.168.xxx.xxx to safely distinguish it from a full IP. Even 0 octets can obviously be actual IP values.

Scheduler records IP address of incoming request in log. That's more or less temporary recording.

FYI, the temporary nature doesn't cut it on its own. You need to state that temp. logging like this is done out of your "legitimate interest" to debug problems and ensure secure operations of your service.

[brevilo]

One more type of consent made possible by Shawn's revised design: stats exports. Those certainly should be separated from the general sign-up consent and have to be disabled by default (opt-in).

[drshawnkwang]

Re: BWT and import_team. There is a workaround but perhaps not ideal: If the project has the enable_record_optin_consent set to TRUE, then no user is created when the team is imported, and the team record will be userid=0. This means the team will exist but have no founder.

[davidpanderson]

This is infeasible because then the team founder is unable to manage the team on that project.

When someone creates a BWT, the name and email address they use become public; it spells this out on the BWT site. Deleting them later doesn't accomplish anything.

[JuhaSointusalo]

@drshawnkwang I have to ask about the database design. I don't really understand consent.consent_flag and consent.consent_not_required fields. To me a more natural design would be row present = consent given, row absent = consent not given. And if you want to record whether consent is required or not I would see that as a property of consent_type.

I'm not sure but I think you designed it that way to support anonymous user accounts. Now David has magic email address and name, you have magic consent to mark anonymous accounts. Why not make anonymous accounts a real properly supported thing? Add a field to user table that tells if account is anonymous and an extra parameter to create_account.php to set it.

I looked at your PR. In the PR, if anonymous user logs into project web site and gives consent then that account becomes non-anonymous. I don't know if you intended it that way or is it a consequence of your design but I like it that way. A user that starts as anonymous might later became more interested in the project and may want to get more involved with it.

(And sorry about taking this long to comment.)

[davidpanderson]

For the anonymous accounts created by Science United, the user has no way to log in to them. -- D

On Thu, May 17, 2018 at 12:57 PM, Juha Sointusalo notifications@github.com wrote:

@drshawnkwang https://github.com/drshawnkwang I have to ask about the database design. I don't really understand consent.consent_flag and consent.consent_not_required fields. To me a more natural design would be row present = consent given, row absent = consent not given. And if you want to record whether consent is required or not I would see that as a property of consent_type.

I'm not sure but I think you designed it that way to support anonymous user accounts. Now David has magic email address and name, you have magic consent to mark anonymous accounts. Why not make anonymous accounts a real properly supported thing? Add a field to user table that tells if account is anonymous and an extra parameter to create_account.php to set it.

I looked at your PR. In the PR, if anonymous user logs into project web site and gives consent then that account becomes non-anonymous. I don't know if you intended it that way or is it a consequence of your design but I like it that way. A user that starts as anonymous might later became more interested in the project and may want to get more involved with it.

(And sorry about taking this long to comment.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2413#issuecomment-389990090, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8KgYugDnBT08Y0PCga2mnkSdosh4nyks5tzdY-gaJpZM4Sscdo .

[drshawnkwang]

@JuhaSointusalo

Thanks for your comments. I'll try to answer some of your concerns:

To me a more natural design would be row present = consent given, row absent = consent not given.

I agree with you in principle, but we need to record the timestamp, as well as other data (see below). The fact that user's may revoke their consent, and projects must have a record of this, prevents the use of a simpler design (row present or absent)

I think you designed it that way to support anonymous user accounts.

Kind of: the motivation is account managers such as Charity Engine which has accounts which are anonymous, but not anonymous in the way David designed them for SU. Thus the additional record consent_not_required. In effect we wanted a 3-state flag, which requires 2 bits. Users may have no consent and consent_not_required is irrelevant (0,0); Users may have given consent and consent_not_required is irrelevant (1,0); Users may have not given consent but because they are using an Account Manager, consent is not required (0,1). (For completeness state (1,1) doesn't have any real meaning, it has the same meaning as state (1,0)).

if anonymous user logs into project web site and gives consent then that account becomes non-anonymous. I don't know if you intended it that way...

This was intended :smiley:, for exactly the reason you stated.

[JuhaSointusalo]

Thanks for explaining.

The fact that user's may revoke their consent, and projects must have a record of this

Ah, of course.

In effect we wanted a 3-state flag

Well... You could have made it a 3-state flag :)

I'm not sure if that would make it easier to understand or would it complicate something else. I need to think about it. (I'm not sure if two booleans is really that hard to understand, I can be thick sometimes.)

[brevilo]

To make things easier we could think about using consent_required instead of consent_not_required as negative/inverted boolean labels like that are unnecessarily confusing. In the end it doesn't really matter if most records sport a true or a false there.

Opinions?

[brevilo]

Regarding consent_time updates: I don't think those should be allowed as we need to have a record of when a user gave consent to what. We can't correlate given consent to a specific version of our privacy policy if timestamps can be updated. Ideally we would add additional entries for each time consent is given (needs an auto-increment PK and a user_id/consent_type combined index can't be unique anymore).

[JuhaSointusalo]

Copied from #2504.

About revoking consent. I don't think it's possible to just record the fact and then carry on. Revoking consent requires some more actions.

If we require third parties to remove any data about a user after the user deletes their account then I would expect that we need to do the same when the user revokes permission to export data about his account. The user_deleted and host_deleted that were added for deleting accounts would work for this too I think, even though nothing was really deleted. This needs to be handled in both am_set_info RPC and when saving project preferences.

As for revoking general terms of use, I don't think it's possible to handle that in am_set_info RPC at all. Revoking consent to TOU is the same as deleting account. Quite a bit of effort went into making delete account feature secure and if it were possible to revoke the consent with am_set_info then it would bypass the new security additions. I think revoking consent to TOU needs to be blocked entirely and user redirected to delete account feature.

[JuhaSointusalo]

About updating consent_time. Lets say on Friday 25.5.2018 I give you consent to export my data. A record is inserted with that timestamp. Week later I change my mind, consent_flag is updated but not consent_time. Then I could start complaining that you have exported data without my consent.

So I don't think not updating consent_time makes sense. If it's not updated then the only thing it tells is that the user had some opinion on that day.

Oliver makes good point about keeping records. Rows added to consent table need to be immutable and only inserting new rows is allowed (and maybe deleting when user account is deleted).

[drshawnkwang]

@JuhaSointusalo brings up an interesting point. However, I believe that revoking the terms-of-use is not the same as deleting the account. There can be a reason users revoke consent and then decide to "re-consent".

But whether we need to think through what exactly happens when someone decides to revoke consent is something that may need thought/discussion. I certainly welcome suggestions.

[JuhaSointusalo]

About consent types. Lets say a project adds a new consent type with id=3. Later on BOINC defines a new consent type with id=3. Now you can't tell what users consented to. BOINC can't reasonably choose another id because any id could be used by projects. You could have the project change their consent type id to something else. But the project would need to notice that they need to do that before updating server code.

So I think BOINC defined and project defined consent types need to live in different id space. That could be done by splitting the main id space to our half and their half.

[JuhaSointusalo]

However, I believe that revoking the terms-of-use is not the same as deleting the account. There can be a reason users revoke consent and then decide to "re-consent".

I just remembered Article 18 Right to restriction of processing. User can request that data is not processed but not deleted either. So yes, revoking consent is not necessarily the same as deleting account but could be request to not process.

What restrict processing means no idea. Hide user, posts etc? Refure to process sched request from user's hosts? What about processing results? If user's tasks can't be processed/validated would that violate wingmens rights?

[drshawnkwang]

How does this sound for a slight redesign for this issue:

1) consent table - make it so every new consent change, give or revoke, is a new row in the table. The only way rows are deleted for the user is when the user is deleted (function wipe_account()) [1]

2) I find myself agreeing with Juha, that consent_type id=1 through 10,000 could be BOINC upstream-defined and ids >= 10,001 are project-defined. I also agree this isn't 100% ideal. A truly flexible solution would have two tables for consent type: upstream and project defined, but this adds a lot of complexity. I highly doubt that there will ever be more than 10,000 consent types defined.

[1] I will have to add deleting entries in the consent table to this function.

What do people think of this?

[drshawnkwang]

What restrict processing means no idea. Hide user, posts etc? Refure to process sched request from user's hosts? What about processing results? If user's tasks can't be processed/validated would that violate wingmens rights?

These are open questions that future-law / court rulings will have to decide. For now we will have to do what we think is best.

[drshawnkwang]

needs an auto-increment PK

What does 'PK' stand for? Primary-key?

[brevilo]

Later on BOINC defines a new consent type with id=3. Now you can't tell what users consented to.

We could use shortnames (e.g. SIGNUP or STATSEXPORT) instead of numerical IDs (well, in addition to the auto-increment PK called id). Normally I'm not in favor of things like that but it seems to make sense in this case since they're are meaningful and collision-free (field needs a unique index). Again, any arbitrary numerical range is fragile and assumptions always end up wrong at some point.

make it so every new consent change, give or revoke, is a new row in the table

Agreed!

A truly flexible solution would have two tables for consent type: upstream and project defined

Apart from what I wrote above (use shortnames instead) I think adding a simple boolean attribute protected is easy enough. Set this to true for upstream (and thus hard-coded) values and don't allow those to be removed/changed by the consent type management form.

What does 'PK' stand for? Primary-key?

Yes.

[krzyszp]

W dniu 23/05/2018 o 03:37, Shawn Kwang pisze:

How does this sound for a slight redesign for this issue:

1.

|consent| table - make it so every new consent change, give or
revoke, is a new row in the table. The only way rows are deleted for
the user is when the user is deleted (function |wipe_account()|) [1]

2.

I find myself agreeing with Juha, that |consent_type| id=1 through
10,000 could be BOINC upstream-defined and ids >= 10,001 are
project-defined. I also agree this isn't 100% ideal. A truly
flexible solution would have two tables for consent type: upstream
and project defined, but this adds a lot of complexity. I highly
doubt that there will ever be more than 10,000 consent types defined.

Why not make separate table consent_types with ID, description and soource (project/upstream) fields?

Regards,

Krzysztof 'krzyszp' Piszczek

[1] I will have to add deleting entries in the |consent| table to this function.

What do people think of this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2413#issuecomment-391192742, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbTIl_RuqASw1ZCXk9PUwCEwDK34BJnks5t1L1TgaJpZM4Sscdo.

[brevilo]

That's already part of the proposal and what we're discussing right now. My protected suggestion would mimic your "upstream" source, yet in a more generic way.

[JuhaSointusalo]

consent table - make it so every new consent change, give or revoke, is a new row in the table.

Yes

We could shortnames (e.g. SIGNUP or STATSEXPORT) instead of numerical IDs.

Yes

adding a simple boolean attribute protected is easy enough.

Yes

[brevilo]

So yes, revoking consent is not necessarily the same as deleting account but could be request to not process. [...] What restrict processing means no idea.

Technically and legally you are correct and I could go on this but let's focus on a thing after another in order to get things done.

[brevilo]

For the sake of completeness: we must not confuse any optional "terms of use" (PP) and the "privacy policy" (PP) required by the GDPR [1]. A project can have the former but must have the latter. More importantly, while you can require the user to agree to your TOU to participate in your project, Art. 7 GDPR disallows you to require consent for all of your data processing as such consent isn't considered being "freely given" (4) nor does it distinguish between processing matters (2). That's why Facebook et al are facing official complaints as they don't adhere to these rules ("accept all processing or lose access to your account").

That being said, we're currently trying to establish for which parts of BOINC we have to require explicit consent and which parts could be covered by our contractual obligations. Ideally this will inform the list of default consent types (see below). Anyhow, the TOU are independent of that and we are only going to require those during sign-up and also once for existing users.

So, ideally, we shouldn't hard-wire any consent types. We might provide default entries that are usually applicable to all projects (eg. "TERMSOFUSE", "STATSEXPORT"), but no functions should require or depend on them as projects might want to remove them. There could still be dependent functions but those should always check for the availability of the respective type (eg. "add TOU checkbox to sign-up if consent type exists"). This we would gain maximum flexibility while providing basic functionality.

[1] I slightly rephrased/reordered Shawn's proposal to reflect that