Is OJS GDPR compliant?

I missed that one. That would really be a shame since most of the changes are easily applicable to OJS 2, such as the registration checkboxes, privacy statements, cookie notices, etc.

I would really like if someone from PKP can confirm whether GDPR obligations will be implemented in OJS 2 on time, so that we can know if we should develop our own solutions.

Hi all,

James from PKP here. We’ll be releasing our recommendations, and plans for code changes, in the near future via our blog. I’ll also notify folks here via this thread.

There isn’t going to be very much in the way of actual code changes at this time, and the good news is that OJS 2 is actually a bit better placed than OJS 3 - it already includes the journal’s privacy statement in the required spots (which can be extended to include an explicity consent statement as a workaround to not having a discrete consent policy field). So I suspect that you will have to do very little, if anything at all, code-wise in OJS 2 to comply, and we’ll provide suggested steps for configuration for OJS 2 users.

Given that, we will focus any compliance improvements and additions to the OJS 3 line.

NB: there is also already a cookie policy plugin for OJS 2: GitHub - ictineo/ojs-cookiesAlert: CookiesAlert plugin for OJS

Cheers,
James

Thanks for the quick answer! That’s good to know, especially since (I assume) most folks are still on OJS 2. Also, didn’t know about that plugin, so thank you for that as well. Do you know if there’s an OMP cookie notice plugin as well?

Hi jmvezic,

There isn’t an OMP cookie notice plugin, but I’ll be suggesting to the core dev team here that the OJS 2 cookie plugin, which has to be updated to work with OJS 3, be updated so that it will also work with OMP. (Both OJS 3 and OMP 3 are so close, code-wise that this should be easy to do.) I can’t guarantee that this will be done by May 25, but I will see what I can do. :slight_smile:

James

Although, from what I understand about the “cookie notice requirement”, session cookies, login cookies and similar, which are neccesary for a site to be functional are exempt from the rule (meaning, obviously, you can’t opt-out from them).

Still, it’s always nice to have the option to display the notice.

In my specific case, though, we have a site which incorporates both OMP and OJS platforms on the same domain (https://morepress.unizd.hr/), and there will probably be a Wordpress installation as a main “landing” site, so I’ll probably be making a custom site-wide cookie notice.

Hi @jmvezic, all,

I thought about this a bit more for the OJS 3 context, and tried the new OJS 3 Custom Header plugin to implement a cookie policy. It works - see Open Journal Systems Demonstration Journal. This cookie policy was derived from the following site/javascript: https://cookieconsent.insites.com/download/#. It comes with its own problem, namely the usage of the Cloudflare CDN, but this could be resolved using another similar cookie policy code snippet. Just a quick proof of concept; I’ll include some additional instructions for OJS/OMP 3 in the Guide once I have a better solution.

Cheers,
James

1 Like

Thank you for the suggestion! It works very well!
http://journal.seriousgamessociety.org/
Looking forward also for additional instructions!

1 Like

Hi all,

A few new notes after a PKP Technical Committee meeting yesterday.

  1. We have identified a few items from the Project that we will develop for OJS 3.1.1-1. This point release should come out in a few weeks, before the May 25 deadline. The best way to get ready would be to upgrade to 3.1.1 now-ish, so that the update to 3.1.1-1 will be easy.

  2. The most important items will be included in OJS 3.1.1-1, namely: a configurable consent statement, available on registration and author submission pages; the addition of the privacy statement to the registration page; and the return of opt-in for author/reader roles in registration.

  3. We have decided against back-porting any code to the OJS 2 line. Reasonable workarounds already exist for this line.

  4. We also discussed the cookie policy issue briefly (and informed by Antti-Jussi’s comments on this topic) and concluded that a simple acknowledgement statement is not sufficient for cookies. Cookies should not be created until explicit consent has been given. I have filed this here: Add cookie consent option · Issue #3624 · pkp/pkp-lib · GitHub. We may not be able to get this done for May 25, in which case the above-described solution will have to suffice.

Cheers,
James

Hi all,

Thank you for your efforts regarding the GDPR. Just pop up to my mind: Are you going to take care about the OMP as well?

Best regards, Primož

Hi @primozs,

Yep, we’ll be considering and releasing for OMP as well!

Cheers,
James

Sounds great, thank you PKP/@jmacgreg , it looks like there is no need for any GDPR plugins. All the main concerns are basically there.

An actual cookie consent where no cookies are created automatically is definitely the best solution. I wonder where you store the user information whether the user approves cookies? In a cookie? :joy:

^ Thankfully I will not be the one to determine the solution to this. :smiley:

Hi all, getting back into the conversation…

So it seems that for OJS2 (vanilla) the only thing to do is to add a (required) checkbox in the registration form with a text that says something like “I agree with the privacy statement”?

As for any user data, any registered user can remove or change his/her data, so if for any reason they want to anonymize themselves, they can.

However, there is the issue of user data added via QuickSubmit plugin. IMO, the journal should have, in its privacy statement, a sentence which says “Any author or contributor not registered in the system that wishes to anonymize their data can contact the journal editorial team who will do it for them”.

Also @PKP kudos for making the e-mail optional for authors and contributors in the future. This will save many headaches for journals that wish to put their 40+ year old content (scanned and OCR-ed) into OJS. Authors from 40+ year-old articles obviously didn’t have emails :wink:

Hi!
@ajnyga @jmacgreg @jmvezic
I am not sure about GDPR compliance regarding efforts to remove email requirement for contributors, but I strongly believe that at least it should not be removed from author submission form (may be removed from quick submit form) as adding email id of all contributors during submission by author is very useful in preventing author dispute/fake authorship.
There are multiple cases in COPE’s forum regarding authorship dispute and in this regard, the forum strongly adviced to email all authors regarding papers submitted for publication at all stages of the editorial communication.
Currently due to the mandatory addition of email ids for all contributors, it’s possible to send the email by OJS to all co-authors e.g. submission acknowledgment, editor decision email which is in line with core practice of COPE.
Even its mandatory still many authors add fake/nonexisting email ids of co-authors and a significant number of such authorship dispute exist. But if this email field would not exist at all there would be more chances to have submission without co-author’s knowledge and more author dispute cases will emerge.

1 Like

Hi @aabahishti,

Many thanks for this note - it’s not a use case I had considered, and it provides a solid counterpoint. I think we can (must) find some sort of balance between these particular use cases. I think we can make an argument for keeping the author field for “in production” submissions for the reasons you state, but maybe relax it for historical back issues that are uploaded by editorial staff (eg. by the quick submit plugin, or by the XML import/export process). Thoughts on that?

Also - would you mind if I copied your comments over to the github issue you link to (and actually, would you consider posting issue-specific comments there)? It would help us track this concern with the issue specifically.

Thanks again!
James

Hi all,

One further note: PKP has released a guidebook on working with GDPR in PKP applications. Blog post is here:

It’s “v1”, and I expect will be revised over time, but I think it’s a pretty good collection of the current thinking on how to best comply with GDPR at this time. I would welcome any comments on this document, and on GDPR in general. Many thanks to everyone in this thread, along with our EU-based development and community partners, for providing (and continuing to provide) such useful feedback!

Best,
James

1 Like

Thanks! Sure, you may copy to the relevant issue post in github.

Yes, I think contributor’s email field should keep (also mandatory) for “in production” submission where article directly submitted by the author and in “Metadata Edit form” which is done by Editors after author submitted article.
Yes, I will try to post there however I avoid to post in github as its more relevant to the developers and I dont want to spam any issue there.
Appreciate work of all developers in PKP community.

Regards,
Dr. Adam

I think most of the requests concerning the removal of the email requirement are connected to situations where journals are importing old archives. So I definitely agree with @aabahishti that it should only be removed from the quicksubmit form and the xml import.

Thanks, Dr. Adam and @ajnyga! I’ll add these notes to the issue.

James

Another thing I haven’t seen crop up in this discussion is double consent. Users that register should be sent an email to verify that they intended to sign up.