In May 2018 the “General Data Protection Regulation” (GDPR) of the European Union takes effect. This has consequences for any system that keeps track of user information.
Does OJS comply with these requirements?
Hi there,
We are aware of the GDPR regulation and deadline, and we are researching the potential implications the GDPR might have for our software and hosting services. We will be releasing our findings, including any issues and resolutions for compliance, in due course via our public website.
I should also note that OJS on its own can’t satisfy GDPR compliance: the publisher, as well as the service provider, will be required to make some reasonable changes to their systems and methods, and will have to communicate that to their users. We will include some suggested follow-up in this regard when we release our findings publicly.
Cheers,
James
3 Likes
Thank you, I’ll be looking forward to that.
Best wishes,
Claus
I would also like a response PKP sooner rather than later; it seems to me right now that what this impacts the most is:
- User registration (a specific checkbox that says something like "I agree my personal information will be used in OJS/OMP for this and that purpose)
- Cookie notice and ability to opt-out of using cookies
- Ability to remove your own personal data from OJS/OMP (maybe even be able to delete the account entirely)
- Automated removal of personal data after a certain amount of time (right to be forgotten)
If I’m wrong about this, I hope someone joins the discussion and corrects me, but this seems to be a pretty major factor in further development of OJS/OMP and even in patching OJS/OMP version 2.
My question is simply does PKP plan on implementing changes which are required by GDPR or will folks have to get dirty with the code and do it themselves on their own installations?
1 Like
Would be great to get an update on this, basically what are the things that PKP will do before May?
After finding this out, I will start preparing a GDPR plugin for OJS that will fill in the gaps, if there are any left (thank you for @jmvezic for listing probably the most important items!). But doing this will of course take some time so I really hope that we hear from PKP soon.
The idea is to have one plugin that fills all the needed requirements instead of having several plugins doing separate things (like cookies warning etc.).
3 Likes
Hi all,
Apologies for the delayed reply here. We’re still getting a handle on the exact spots that will need addressing in OJS, and what kind of addressing they will need (eg. does it just need some sort of published policy, or is there a need for some code changes). I’ll be getting back to this thread with some further comments towards the end of the week.
Cheers,
James
Hi all,
I am not sure if this two points are necessary i.e. how they should/can be solved:
As far as I understand from here https://gdpr-info.eu/art-17-gdpr/: the users do not have to be able to delete their accounts on their own – they could ask the journal manager. And, only the data that is not needed any more in relation to the purposes for which they were collected, can/should be removed. Right?
For OJS/OMP it means: the user can changed and remove his/her optional data alone and can require that the journal manager removes his/her account. The data published till then can and should stay as they are – they were collected for that purpose.
The data are collected with the purpose of continuous? publishing – for example how to automatically know that a user does not need it’s account any more? Or can we say: “After 10 years of inactivity, the user account can/should be removed?”
Best,
Bozana
I agree, although I think that it would be fairly easy to add a “remove this account” button as well. This would mean erasing personal data from the user and user_settings table and disabling the account. I think that removing the whole account (row from the users table) would cause problems. You would just end up having an user X who has done certain things in the past. Of course there is the option of merging, but with which account?
But this can not include data in the authors tables. I would compare this data to the data maintained by libraries. I do not think that GDPR can mean that an author can demand that her personal data (name etc.) is removed from a library database if she has authored a book.
Agree… Good that authors and users data are separate… 
Also with the cookies policy, I am not sure if we need to give the ability to opt-out from using cookies. I think that many cookie dialogs just say that “accept or leave” 
Or by using the site you agree to storing cookies…
Hello,
I think the right to be forgetten coud be done easily “anonymizing” the users, something like this:
update users set username=“XXXXXXX”,first_name=“XXXX_XXXXX”,last_name=“XXXXXXX_XXXXXX”,email=“XXXXXXXX@XXXXX” where user_id=<user_id>;
or generating values by some hash or obfuscation function.
When a users demands it explicitly.
We are looking forward any update.
Thank you.
Kind regards,
Jose Angel Navalón.
ojs@uv.es
Yes excatly + possibly disabling the account. Or maybe just erasing all active roles.
But this can only be done in the users table, the authors table is a different story and as I said above, no way can GDPR mean that authors can demand their name to be removed from library databases.
Please also remember that users have the right to request a copy of all information stored about them. (Article 15 section 3.) We must have a simple way to retrieve that information.
1 Like
I wonder if this also includes the actions they have done inside OJS. I mean is it enough to have easy access to
a) all profile information stored in OJS (this is all visible in the profile page) OR
b) do we also need a simple list that includes things like “User X submitted a new manuscript on 12 February 2018”.
Yes, I think you’re right in that they don’t need to be able to delete the accounts, but rather, as the GDPR states, “pseudonymise” their personal data. I must admit I don’t quite understand what they mean by that. Perhaps scrambling the identifiers such as ORCiD, name, surname, email, etc.? Hash them perhaps?
1 Like
I think that is fairly easy to do, but as I said above, only in the users table. The author metadata is a different story. I have to discuss this with some people I know at the Finnish National Library (how they see GDPR). Because I really see a parallel between OJS author data and library data.
Does anyone have any thoughts about PKP PN and GDPR compliance? Even though it’s mostly “library data” only (see above), the native XML export (which I think is the same data that the PKP PN plugin takes) includes some personal information about uploads (uploader, file name including user name, etc.).
Disclaimer: Not well-read on GDPR yet …
This is something what I have been thinking for a long time now. Specifically the situation where an European journal activates PKP PLN and the data is moved to a server situated in USA or Canada.
The Safe Harbor agreement between the US and EU used to cover this until 2015, but not anymore Safe harbor (law) - Wikipedia.
See PKP PLN, EU and data privacy for an earlier topic. I have not found an answer for this question yet.
For Canada, see https://gowlingwlg.com/en/insights-resources/articles/2015/is-canada-safe-from-the-safe-harbor-decision
Paging @mjordan here. It’s a good question. We may be able to walk back some of the information that’s included in the export file to satisfy GDPR - OJS 2.x didn’t have that info, and I’m not sure how necessary it is for 3.x.
I’m arranging for an informal working group on this general topic - I’ll be reaching out in this thread with some more information shortly. My hope is to meet and get answers (or at least a good start to answers) next week, and determine what work needs to be done in the next couple of months on our end, or on publishers’ ends.
Cheers,
James
@jmacgreg thanks for confirming that 2.x doesn’t include any personal info. For the OJS3.x PN plugin, we already decided in Extend native import/export plugin to include additional entities · Issue #3261 · pkp/pkp-lib · GitHub that we will need to filter some things out of the XML that gets included in the deposits. If that includes information that violates GDRP, we should start the work of filtering out now, before we release the plugin. I’ll link to this thread from the Github issue.