Add a consent statement configuration option

[jmacgreg]

Similar but different to a privacy statement, a consent statement should be available for:

• user registration
• manuscript submission
• any eventual notification subscriptions that don't otherwise require user registration

Managers should be able to make consent mandatory for the above processes.

Some form of draft consent statement should be provided by default, but it should be editable - same as what we do with the current privacy statement. Some sample text to follow soon.

[NateWr]

So, we discussed user registration and submission. I've added an opt-out option for announcement and issue publication emails.

All of this is always-on. Is there anything else we need a journal setting for? Or will these items cover it once the user registration and submission parts are in place?

[jmacgreg]

I'm working on this issue ATM, @NateWr. The plan right now will be to allow JMs to write up a consent statement for user registration (configurable under Users -> Site Access Options, and added to the user registration page). I don't think it's necessary to have a different one for submission, so this could also be added to the submission page - or we could just let JMs add some sort of more specific consent statement in the submission prep checklist. Thoughts on that?

[NateWr]

I guess I misunderstood our conversation about the role adoption. Is the checkbox for opting into the email notifications not sufficient? What is this additional consent statement indicating that is not already indicated elsewhere and will it require another checkbox? Is there any way we can combine these things? Can the consent statement also include the email notification opt-in?

[jmacgreg]

Let me step back a bit and use the "As a ..." method to sketch out the problem area here.

"As a site registrant, I want to know exactly what I'm signing up for, how my information will be used, and how to manage this relationship."

"As publisher, I want to know that, if someone visits my site, they know exactly how we use their data, have given us explicit consent to use it in the way we specify, and have the ability to manage (to a degree) how we do so."

In my mind, the two things that need to be here are:

1. consent statement. (Or call it a data collection statement, or what have you.) This should be configurable by the publisher, as they are the ones managing the data. This shouldn't require a checkbox IMO, it should just be a text statement that is provided wherever a user does something to manage their account, as the act of managing should indicate that explicit consent. (Eg. if the statement appears just above the "Register" button, I'm comfortable at this time that we don't need an additional checkbox above for consent - the Register button provides that function. Others, maybe @ajnyga, may disagree on that.)

• Configure under: Users > Site access options
• Display on: User Registration page; User Profile pages

2. Opt-in and opt-out of certain actions, including having an account in the system, and notifications. If there's an opt-out option for announcement and publication emails, I think this one is resolved. (Users already explicitly double-opt-in during user registration, at least if the email validation option is enabled, and users can request that their account be deleted.)

Does that make sense? I'm a little all over the place this week (on semi-holiday) but could have a call tomorrow early-afternoon your time if you think it's worthwhile talking this over. The last thing I want to do is just throw a bunch of random configuration options all over the place without much consideration, as we've done that before (ie. with notifications, mailing lists, etc.) and have made a bad thing worse. So - please do continue to push back on this if warranted!

[ajnyga]

Of course I disagree!

I have to admit I do not fully follow how the consent statement is different from the privacy policy if the consent statement is also a piece text?

I have been thinking about a model where you have:

• site level privacy policy which is edited by the site managers
• context level privacy policy which makes a reference to the site level policy and defines, if any, the context specific changes and additions to the site policy
• the context level privacy policy (with the reference to the site level policy) is shown in the registration form, the submission form, the review form and basically in any place where the user acquires a role in a new context, meaning also the roles tab in the user profile settings. (So the fact that OJS allows the editors to create reviewer accounts really becomes a problem here)
• under the privacy policy there is a checkbox where the user gives consent to the policy described above. You can not send the form without checking that box. So I guess for me the consent statement means the short text next to that checkbox, but I think this could just be a general text saved as a translation to the xml files?
• when the user gives consent to the privacy policy, it is saved to the database. Note that it has to be context specific.

So my opinion on checkboxes is that they do not have those next to software policy texts by accident and GDPR does talk about explicit consent which usually means a checkbox in technical terms (https://wpforms.com/docs/how-to-create-gdpr-compliant-forms/)

Having just the submit button is basically the same thing as having a preselected checkbox - which is also not allowed (see https://www.itgovernance.eu/blog/en/the-gdpr-and-the-future-of-location-based-advertising).

If there is no checkbox, I believe the submit button itself should read something like "I give consent...".

The copyright statement has a setting where you can force the author doing a submission select a checkbox that they agree with the given terms. I think the privacy policy text should have a similar setting and enabling that setting would make OJS require the consent in the forms/situations I mentioned above.

[NateWr]

I spoke to James briefly and we settled on a v1 approach, with the acknowledgment that we can revisit it later:

• Add public page with privacy policy.
• Add required checkbox with link to privacy policy in user registration, submission and review form.
• Link to privacy policy in each user profile form, with a declaration that data is stored according to the privacy policy.

We can talk about saving the consent to the database, merging site and context privacy policies, and any further requirements in a later round if it is determined that they are necessary.

[ajnyga]

So what happens if the user is registering from the site level?

I mean are you planning to have a site level privacy policy, and if not, what privacy policy is linked in the site level registration form.

[NateWr]

Nothing changes for v1, but we will probably need to introduce a site-wide privacy policy for v2.

[ajnyga]

Ok, just to be sure: this means that with OJS 3.1.1.1, when user registers from the site level, there is no privacy policy or consent checkbox visible in the form?

[NateWr]

Correct.

[ajnyga]

Ok, I just need to do a hack for our site or just remove the whole site level registration form by D day.

[NateWr]

Here are PRs that combine @ajnyga and my work on several related issues (#3575, #3576, #3600, #2805).

PR:
#3682
pkp/ojs#1963
pkp/omp#537

These changes include:

• Users now opt into the Author role during submission.
• Users can now opt in/out of the public email notifications (announcements, issue published).
• Users are required to opt into public email notifications during registration.
• Users who register without requesting the reviewer role are assigned the reader role.
• Users must agree to the privacy statement during user registration, submission and review.
• The privacy statement now appears on it's own frontend page. This is linked to in the consent checkboxes as well as in the user profile forms.
• Also, I removed all the mailing list and /notification stuff as it is no longer used.

I may not be working tomorrow, Friday, so I wanted to get this ready in case Alec wants to get 3.1.1-1 out the door. However, I still haven't ported the changes to OMP. I can do that next week.

[ajnyga]

Great stuff, thanks @NateWr!

I have been thinking about it and I actually think that there is no need for the site level registration page in our case, so I will just remove the whole thing using our site theme plugin templates. I can also just create a normal custom page for the site level privacy policy and tell the journals to link to that in the beginning of their context privacy policy.

One small addition would be nice though (and fairly quick to implement):
In the user profile page you have the roles tab. In multijournal installations that is where users basically register to a new context by choosing available roles(besides the other routes built now). Could we have a consent box and the link to the privacy policy in that form as well? I think it would make sense.

Second thing: how do you feel about the block plugin for registering as reader/enabling public notifications I mentioned earlier? I could build that and I think journals would like something like that?

I am actually planning to look at the cookie policy thing, any chance you would have time to comment that issue before the weekend? Just what you think about the solutions suggested there. #3624

[ajnyga]

Sorry for posting again, but one related thing came to mind.

Should the announcement/new issue consent settings be in User profile => Notifications as well? Because now users can not opt-out later. If the setting would be there, the opt-out link would just be a link leading to that setting page, right?

And in multijournal installations, if the user has no roles in a context, would they be able to enable/disable the public notifications?

I would be happy to do these additions as well if you think they could make it to 3.1.1.1, you already pulled most of the weight here.

[NateWr]

In the user profile page you have the roles tab. In multijournal installations that is where users basically register to a new context by choosing available roles(besides the other routes built now). Could we have a consent box and the link to the privacy policy in that form as well?

I see what you're saying, but each context's privacy policy might be different. I think opting into other contexts requires more consideration, so let's consider this a v2 question, along with site-wide registration and admin role invites.

Second thing: how do you feel about the block plugin for registering as reader/enabling public notifications I mentioned earlier? I could build that and I think journals would like something like that?

I'm hesitant to endorse the use of OJS as a mailing list platform. I agree that it is a plugin that a lot of journals would like, though.

Should the announcement/new issue consent settings be in User profile => Notifications as well?

They're there and they can opt-out of either one.

And in multijournal installations, if the user has no roles in a context, would they be able to enable/disable the public notifications?

Yep, a user's notification settings are not specific to a context.

[NateWr]

All merged to master, ojs-stable-3_1_1 and omp-stable-3_1_1. 🎉