New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a consent statement configuration option #3575

Closed
jmacgreg opened this Issue Apr 10, 2018 · 21 comments

Comments

@jmacgreg
Copy link
Member

jmacgreg commented Apr 10, 2018

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.

@jmacgreg jmacgreg changed the title Add a consent statement Add a consent statement configuration option Apr 10, 2018

@jmacgreg jmacgreg added this to To Do in GDPR Compliance Enhancements via automation Apr 10, 2018

@NateWr NateWr added the Enhancement label Apr 13, 2018

@jmacgreg jmacgreg self-assigned this Apr 19, 2018

@jmacgreg jmacgreg added this to the OJS/OMP 3.1.1-1 milestone Apr 19, 2018

@jmacgreg jmacgreg moved this from To Do to In Progress in GDPR Compliance Enhancements Apr 20, 2018

@NateWr NateWr added this to To do in Nate's wee project via automation May 9, 2018

@NateWr NateWr moved this from To do to In progress in Nate's wee project May 9, 2018

@NateWr

This comment has been minimized.

Copy link
Contributor

NateWr commented May 9, 2018

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

This comment has been minimized.

Copy link
Member

jmacgreg commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor

NateWr commented May 10, 2018

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

This comment has been minimized.

Copy link
Member

jmacgreg commented May 10, 2018

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
  1. 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

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

NateWr commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

NateWr commented May 10, 2018

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

@ajnyga

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

NateWr commented May 10, 2018

Correct.

@ajnyga

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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

NateWr added a commit to NateWr/pkp-lib that referenced this issue May 10, 2018

pkp#3575 Add privacy consent to user data forms.
- Adds a privacy policy page on the frontend.
- Adds a consent checkbox to registration, submission and reviewing.
- Adds a policy notice to user profile forms.

NateWr added a commit to NateWr/ojs that referenced this issue May 10, 2018

NateWr added a commit to NateWr/pkp-lib that referenced this issue May 10, 2018

pkp#3575 Add privacy consent to user data forms.
- Adds a privacy policy page on the frontend.
- Adds a consent checkbox to registration, submission and reviewing.
- Adds a policy notice to user profile forms.

NateWr added a commit to NateWr/ojs that referenced this issue May 10, 2018

@NateWr

This comment has been minimized.

Copy link
Contributor

NateWr commented May 10, 2018

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.

@NateWr NateWr moved this from In progress to Ready in Nate's wee project May 10, 2018

@ajnyga

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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.
nayttokuva 2018-5-10 kello 22 28 41

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

This comment has been minimized.

Copy link
Contributor

ajnyga commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

NateWr commented May 14, 2018

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 added a commit to NateWr/pkp-lib that referenced this issue May 23, 2018

NateWr added a commit to NateWr/ojs that referenced this issue May 23, 2018

NateWr added a commit to NateWr/omp that referenced this issue May 23, 2018

NateWr added a commit that referenced this issue May 24, 2018

Merge pull request #3682 from NateWr/i3575_consent
#3575 GDPR privacy and consent considerations

NateWr added a commit to pkp/omp that referenced this issue May 24, 2018

Merge pull request #537 from NateWr/i3575_consent
 pkp/pkp-lib#3575 Add consent statements to user registration and notifications

NateWr added a commit to pkp/ojs that referenced this issue May 24, 2018

Merge pull request #1963 from NateWr/i3575_constent
pkp/pkp-lib#3575 GDPR privacy and consent considerations

NateWr added a commit to NateWr/pkp-lib that referenced this issue May 24, 2018

pkp#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history look at related
commits in the master branch

NateWr added a commit to NateWr/ojs that referenced this issue May 24, 2018

pkp/pkp-lib#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history see related commits
in master branch.

NateWr added a commit to NateWr/omp that referenced this issue May 24, 2018

pkp/pkp-lib#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history, look for related
commits in the master branch

NateWr added a commit that referenced this issue May 24, 2018

NateWr added a commit to pkp/ojs that referenced this issue May 24, 2018

NateWr added a commit to pkp/omp that referenced this issue May 24, 2018

@NateWr

This comment has been minimized.

Copy link
Contributor

NateWr commented May 24, 2018

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

@NateWr NateWr closed this May 24, 2018

GDPR Compliance Enhancements automation moved this from In Progress (3.1.1-1) to Done May 24, 2018

Nate's wee project automation moved this from Ready to Done May 24, 2018

NateWr added a commit to NateWr/pkp-lib that referenced this issue May 24, 2018

pkp#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history look at related
commits in the master branch

NateWr added a commit to NateWr/pkp-lib that referenced this issue May 24, 2018

pkp#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history look at related
commits in the master branch

NateWr added a commit that referenced this issue May 24, 2018

Merge pull request #3733 from NateWr/i3575_stable_omp
#3575 GDPR privacy and consent considerations.

ppv1979 pushed a commit to ppv1979/pkp-lib that referenced this issue May 25, 2018

mtub added a commit to mtub/pkp-lib that referenced this issue Jun 2, 2018

pkp#3575 en_US locale update
* minor update to pkp#3575, clarify language, s/Policy Statement/Privacy Policy Statement

mtub added a commit to mtub/pkp-lib that referenced this issue Sep 11, 2018

pkp#3575 en_US locale update
* minor update to pkp#3575, clarify language, s/Policy Statement/Privacy Policy Statement

ambs added a commit to ambs/pkp-lib that referenced this issue Oct 16, 2018

pkp#3575 GDPR privacy and consent considerations.
This commit has been squashed. For full commit history look at related
commits in the master branch

ambs added a commit to ambs/pkp-lib that referenced this issue Oct 16, 2018

pkp#3575 en_US locale update
* minor update to pkp#3575, clarify language, s/Policy Statement/Privacy Policy Statement
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment