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!

[brevilo]

@drshawnkwang you proposal currently states that the terms_of_use.txt must not contain any HTML. That's correct today since the BOINC manager can't handle it. However, I think we should consider changing that as having HTML (particularly links, also lists and rich text) supported would be a great benefit in for presenting the TOU. If we decide to change that, we should add that to the proposal.

Opinions?

[drshawnkwang]

I agree in principle that we should support HTML in the terms of use. We just need to understand what is required from the client-side. The web-site part should be simple to add.

[AenBleidd]

Sorry, guys, side question: do we have some project (test project is ok) that uses terms-of-use during sign-up process? I need to verify Manager Wizard behavior. Thank you in advance.

[drshawnkwang]

@AenBleidd - I don't have a public project that you can connect to for testing right now.

I realized that our test project Albert@Home uses the terms of use. Meaning the get project config Web RPC returns a 'terms of use' in the XML: https://albert.phys.uwm.edu/get_project_config.php . Is that enough?

[drshawnkwang]

After discussion, we came up with the following changes.

The terms of use (TOU) is independent of any (GDPR required) privacy policies. Projects may decide whether they want a terms of use or not. As a result...

I am removing the configuration option enable_record_optin_conset. Instead the consent_type table will have a column enabled, which is a boolean. The OPS page for consent types will allow the admin to choose what consent types to enable. Additionally, a privacyprefs column will be added. This is to help generate the privacy preferences form.

In the config.xml, there will be a new boolean enable_termsofuse_existingusers. This will turn on a feature where when an existing user signs-in, s/he will be presented with a Terms of Use to agree to. But projects may decide this on a case-by-case basis.

[CharlieFenton]

@AenBleidd - The BOINC alpha test project http://isaac.ssl.berkeley.edu/alpha uses terms-of-use.

[brevilo]

Additionally, a privacyprefs column will be added. This is to help generate the privacy preferences form.

FYI, this covers all potential GDPR-relevant consent types a given project might (optionally) require.

[AenBleidd]

@CharlieFenton, Thank you

[brevilo]

@AenBleidd let me know if you need HTML in the TOU returned by the RPC. Just in case you're working on integrating that...

[brevilo]

@AenBleidd even easier: just use https://albertathome.org instead.

[AenBleidd]

@brevilo, I'm not working on HTML support in TOU but I can start working on it too. Looks like not a hard task. Also thank you for another link, it always better to use more than one for testing :)

[brevilo]

Sure, thanks. You might have missed it above, the non-HTML version can be found here: https://albert.phys.uwm.edu

[JuhaSointusalo]

If project has terms of use, you want to record that user agreed to terms when user's account is created, correct? If that is the case then get_project_config.php needs to tell old Managers/clients that sign up is available only on website. This would require versioning the API.

About HTML TOU.

The HTML syntax needs to be limited to what wxHtmlWindow supports. wxWidgets can use proper browser engines but not on some Debian and openSUSE versions and maybe somewhere else neither.

Is the HTML TOU to be just some piece of HTML or an HTML page on its own right? In other words, will it begin with <html>? If you want to have it embeddable to website sign up page then just piece of HTML sounds better to me.

Old Manager needs plain text TOU. XML escaped HTML TOU just looks gibberish. I'm thinking having a new element in the XML for HTML TOU would work best. Something like term_of_use_html. This would also solve the problem of how to know if the TOU is plain text or HTML.

Alternatively, get_project_config.php could return different XML on a case by case basis. Plain text for old Manager, HTML for new Manager. This would require versioning the API and would make it harder to tell plain text and HTML TOU apart.

In both cases there needs to be two different versions of TOU. Maybe the plain text version can be autogenerated from HTML. Or project admin needs to provide two versions and risk having them out of sync. If two versions can't be had then get_project_config.php needs to tell old Manager that sign up is available only on website. This would again require versioning the API.

To keep things simple and stupid, I'm thinking versioning would be core_client_major_version, core_client_minor_version and core_client_release (without _version) parameters added to the request. The client already uses similarly named XML tags when talking to the server. The client includes its version number in user agent string but that's not easily changed for one web API call. Since the client is acting on behalf of Manager, and the client needs to support everything the Manager supports, the version number needs to be the lower of client's and Manager's version.

[AenBleidd]

@brevilo, why did you mention HTML TOU? I just wanted to fix TOU field size in the Wizard (joke)

[AenBleidd]

Looks like this pr #2547 is now connected to this issue

[brevilo]

why did you mention HTML TOU? I just wanted to fix TOU field size in the Wizard

@AenBleidd I'm mean by mother nature so blame it on her 😬

[brevilo]

If that is the case then get_project_config.php needs to tell old Managers/clients that sign up is available only on website. This would require versioning the API.

@JuhaSointusalo Hm, this really depends on the individual projects on how they want to handle that case. Versioning the API is always a good idea but in this case you could just extend the create_account() RPC to accept the TOU-agreement (as a bool) that uses a backwards-compatible default (i.e. false). New clients could use it, old clients don't. Projects could reject a false if they wanted.

Is the HTML TOU to be just some piece of HTML IHMO, that's sufficient. Keep it simple. That way this fragment could also be reused and embedded in other (HTML) places.

I'm thinking having a new element in the XML for HTML TOU would work best.

Doesn't sound like a bad idea, but...

This would require versioning the API and would make it harder to tell plain text and HTML TOU apart.

... I like this idea better: if you release HTML support for the Manager alongside a revised API which provides get_project_config.php with a new parameter called, say, html-support then this shouldn't be a problem.

I'm thinking versioning would be core_client_major_version, core_client_minor_version and core_client_release (without _version) parameters added to the request.

That would probably be best as it would facilitate a number of other compatibility checks. I'm all for it.

[drshawnkwang]

Juha:

If project has terms of use, you want to record that user agreed to terms when user's account is created, correct? If that is the case then get_project_config.php needs to tell old Managers/clients that sign up is available only on website. This would require versioning the API.

Oliver:

this really depends on the individual projects on how they want to handle that case. Versioning the API is always a good idea but in this case you could just extend the create_account() RPC to accept the TOU-agreement (as a bool) that uses a backwards-compatible default (i.e. false). New clients could use it, old clients don't. Projects could reject a false if they wanted.

See the following from PR #2504, new create_account.php

At the end, line 99 is a section where the terms of use is set. If there is a series of parameters in the HTML POST for setting consent/agreement to the terms of use, the database is updated. If there is no such series of parameters the account is still created; this ensures backward-compatibility

We could change this logic a bit as Oliver suggests, so a project would demand that the consent parameters are passed in order to create an account. This would probably be a new setting (foo) in config.xml, which would control this logic. If foo=TRUE, then only Web registration and newer clients/AM which can set these parameters may create accounts. If FALSE, then any method, including older clients, may create an account.

[JuhaSointusalo]

About agreeing to terms of use.

My bad. I had not read the latest changes carefully and had myself confused. Sorry about that.

About HTML terms of use.

So get_project_config.php input parameters:

core_client_major_version=x
core_client_minor_version=y
core_client_release=z
html_support=0|1

Where core_client_* is the lower of client or Manager version. html_support defaults to false.

And output XML:

<project_config>
    ...
    <terms_of_use>plain text or HTML</terms_of_use>
    <term_of_use_format>text|html</term_of_use_format>
</project_config>

Element for the format so that it won't be necessary to guess the format. If term_of_use_format is not present then it's assumed to be text.

How plain text and HTML is best handled server side something for you @brevilo and @drshawnkwang to decide.

[brevilo]

<term_of_use_format>: I'd name that <terms_of_use_format> for consistency.

That said, I don't think that's necessary. If you do support HTML then it doesn't really matter what you get back. IOW, you don't need to know. If you don't support HTML you'll get plain text by default - and you aren't even aware of <terms_of_use_format>'s existence anyway (old client). Did I miss anything?

On the server side I support the idea of having a dedicated term_of_use_html.txt parallel to the plain text one to keep it simple (Drupal can likewise use a separate config variable).

[JuhaSointusalo]

Line breaks in plain text are not line breaks in HTML. In order to show plain text in HTML component Manager needs to convert line breaks to <br/> tags. In #2547 @AenBleidd made it so that Manager checks if XML escaped terms is byte by byte identical to XML unescaped terms to see if it's plain text. That feels fragile to me.

I suppose you could dictate that starting with server version X terms are always HTML if the Manager supports it. But then you need to include server's version in project config reply.

[brevilo]

Line breaks in plain text are not line breaks in HTML.

You're right.

[brevilo]

Just to make sure we don't drift too far off: the whole HTML/plain-text TOU discussion was just a tangent off this issue. How about the main topic, the proposed consent feature itself? What's actually still pending discussion or holding up #2504 from being finally reviewed?

[drshawnkwang]

What's actually still pending discussion or holding up #2504 from being finally reviewed?

We're waiting for review. I've pinged Kevin.

[AenBleidd]

Is there something left here or this ticket can be closed?

[drshawnkwang]

I think we can close this ticket, now that #2504 is merged. Any new issues should be opened in a new ticket.

[brevilo]

Strictly speaking I think that the BOINC client still needs to be modified such that the extended create_account.php RPC is used.

That in turn requires that get_project_config.php gets extended in a way that let's the client know that the project supports (or even requires) the new API.

That would also allow account managers like BAM! to do the same.

Until this is done we (E@H) are forced to suspend client/AM-based account creation and will only allow to sign-up via our website. Otherwise we can't prove that consent was given.

Since this is part of the original issue description, I don't think we can close it already.

[RichardHaselgrove]

How does that impact on Science United, which uses the AM API, but handles GDPR by creating pre-anonymised accounts?

And which, incidentally, prevents any SU user making use of any project-level preferences (because they can't log in to the website).

[JuhaSointusalo]

@brevilo

2835 adds support for consent stuff in Client and Manager. I was going to have the PR ready before the server side code was merged, but... Oh, I'm five minutes late from everything :)

[brevilo]

How does that impact on Science United, which uses the AM API, but handles GDPR by creating pre-anonymised accounts?

As discussed in yesterday's call: this means SU won't be able to interface with us for the time being. I see two ways to resolve that:

1. augment the create_account.php RPC such that it can be configured to accept only requests with consent_flag and source being set.
2. provide a way to distinguish SU request from all the others and bypass any consent checks

Any of the two solutions would SU to get through. I for one strongly favor the first one as it's generic (client agnostic).

And which, incidentally, prevents any SU user making use of any project-level preferences (because they can't log in to the website).

As I pointed out yesterday, that's an independent problem and also one at SU's design level.

[brevilo]

2835 adds support for consent stuff in Client and Manager.

Thanks Juha! I'll have a look and comment on it over there...

[RichardHaselgrove]

It was also suggested during yesterday's call that the account key could be used to access an anonymised account. But #2371 and related has already disabled that back door, and despite @Ageless93's comment, trying it today at SETI rejects it with

Unable to handle request You must supply an email address and password

The account key is also not (currently) visible on the face of the Manager, and retrieving it from a file requires accessing the (by default) hidden C:\ProgramData\BOINC folder - not something the target SU audience could be expected to know about.

Back to the drawing board.

[JuhaSointusalo]

1. augment the create_account.php RPC such that it can be configured to accept only requests with consent_flag and source being set.
2. provide a way to distinguish SU request from all the others and bypass any consent checks

Any of the two solutions would SU to get through. I for one strongly favor the first one as it's generic (client agnostic).

Wouldn't option 1 mean that SU would have to present to its users terms of each project and require accepting the terms? But I think SU was supposed to be the only thing its users see. The users weren't supposed to need to know that there is something behind SU.

[brevilo]

Hm, my original idea was that SU accepts the TOUs on behalf of its users as it guarantees to propagate anonymized account details only and doesn't allow community participation anyway.

However, the TOUs are naturally project-specific, so SU might in fact not be able to accept them by default after all. For instance, does SU ensure all users are at least 16 years old?

[JuhaSointusalo]

account key

Well it's a back door key (though I haven't gotten a confirmation yet) and it won't work in the front door lock. You need to use one the back doors:

Stock BOINC web code: Set cookie with name=auth and value=your_authenticator. Or go to project_url/login_auth.php and fill in Authenticator.

Drupal web code: Go to Login -> Request new password -> authenticator-based login (project_url/user/login/auth) and fill in Log in with authenticator.

Both: Go to project_url/account_finish.php?auth=your_authenticator .

And David, please don't take away the back door. I really strongly feel that SU users should be able to take control of the accounts SU creates for them if they want it. Or if you take away the back door implement something to replace it.

[RichardHaselgrove]

Working through those.

I don't think we can ask SU users to create their own cookie.

Stock BOINC web code (@ SETI): /login_auth.php exists (for the time being) and works, but is not linked from any of the obvious pages.

That's testing with my standard account: I'll switch and try my SU test account later, and see if I can post to the message board. I wonder where PM email notifications would end up?

I'll leave https://setiathome.berkeley.edu/forum_thread.php?id=83445&postid=1968027#1968027 hanging...

[brevilo]

@JuhaSointusalo / @RichardHaselgrove you're starting to get off-topic I think. Maybe you should open a dedicated issue to discuss these things?

[brevilo]

1. augment the `create_account.php` RPC such that it can be configured to accept only requests with `consent_flag` and `source` being set.

I added this now via PR #3049.

[AenBleidd]

I'm closing this as 'Done' since all the required (and even more) actions to comply with the GDPR were already made, and all needed implementations were several years ago merged.