PKP Turin 2024 Sprint notes: GDPR

The GDPR summary from the PKP Turin Sprint, hosted by the CRAFT-OA project in October 2024, is now available.

Sprints involve PKP community members joining diverse groups to work on PKP software and support. In October, the CRAFT-OA project and the University of Turin hosted eight working groups at the PKP Turin Sprint. This is a summary of one such group’s work.

Abstract

The General Data Protection Regulation (GDPR) has different use cases in various countries. There is more than a mere implementation requirement but the framework for use cases is complex.  The workload for system administrators could grow if the request volume is high and the workflows must be carefully crafted.  Possible legal actions are uncertain and journals may need individual legal advice when creating the contracts.

Working Group members

• Jonas Raoni Soares da Silva, Public Knowledge Project
• Tom Granroth, Federation of Finnish Learned Societies
• Dulip Withanage, TIB
• Ipula Ranasinghe, TIB
• Jyrki Heinonen, Federation of Finnish Learned Societies
• Gabriele Raimondi, University of Bologna

Background

An important issue is important for General Data Protection Regulation (GDPR) compliance and other personal data protection laws comes when maintaining the editorial history, as balancing the right to be forgotten with user merging functionality can become a challenge.

The current processes don’t preserve the historical contributions and edits when merging user accounts, causing discrepancies in editorial records. Another complex scenario comes when an individual has deceased, as these accounts can’t be anonymized but should not remain active. A permanent tag is necessary in those cases, as well as a workflow to finish any incomplete work by that person.

Goals

• To create a list of considerations and a specification for anonymizing metadata
  • Considerations
    1. Legal
       1. Do officials (e.g. police officers) have the right to deanonymize the data? If yes, and if it’s for a limited time (e.g. maximum 6 months), then we can keep the data encrypted instead of hashed, in a separate place and encrypted (so it’s possible to reverse).
       2. Can Agreements be made by the journal that from the time of asking “right to be forgotten”, the anonymization can happen? For earlier disseminated metadata, it may not be possible. Examples are archived tapes/backups, open-review metadata deposited in national or long-term archives
       3. Can Journals retain the right not to anonymize personal data contractually for already published formats e.g. PDF?
       4. Is GDPR a superset of the other privacy regulations? If not, it might be necessary to define which one the institution wants to follow.
          1. Can we get some help from PKP/SFU/TIB lawyers regarding the laws existing beyond GDPR e.g. https://oag.ca.gov/privacy/ccpa ?
    2. OJS
       1. When the user is anonymizing himself (e.g. “Delete my profile”), does it need to be approved by a manager?
       2. Should it allow the user to download their data before/after anonymization?
       3. Some users may ask to anonymize their activity in one journal.
       4. Can someone ask not only to anonymize but also to delete log entries?
       5. If encryption is used
          1. The encrypted value may be longer than the column
          2. The key has to be preserved permanently
       6. When thanking a reviewer, the user’s first and last name can be saved in the database. Are we allowed to change that, even in the GDPR context?
       7. Bots may create only users: can we delete such users instead of anonymizing them?
       8. What do we have to do when we are migrating data, and in the process, the journal manager wants some of the user data removed? Maybe we need a mechanism to exclude users by email or username
  • Suggestions:
    1. Allow the user to anonymize him/herself
    2. Allow journal manager to anonymize on request (legally binding)
    3. For multiple journals, an administrator request, the user may need to ask each journal manager where he/she is enrolled.
    4. For the future users’ table: maybe a tag to indicate “anonym_user”

Results

Current list of steps an administrator can do to anonymize a specific user

1. A system administrator can create an encryption key
   1. Depending on the context, the policy can be a
      1. random encryption key (truly anonymized)
      2. persistent key, so that can still recover (questionable GDPR)
2. Encrypt the following fields in the tables
   1. Users: Username, email (id is not changed), phone, mailing_address, billing_address
   2. User_settings: biography, signature, affiliation, givenName, familyName, preferredPublicName, ORCID,
   3. Event_log_settings: ****username, editorName
3. Disable the user by editing the users table
   1. Users: disabled, disabled_reason
4. Delete profile image (user_settings):profileImage and clear public folder
5. Delete User_settings: apiKey
6. Clear the logged-in sessions
7. Wrote SQL creates SQL queries
8. Converting to PHP

Demonstrations of the general workflow

Rewrite the Users Table to support the OJS 3.5 design

1. Demo: https://github.com/craft-oa/gdpr-invitation/issues/38#issuecomment-2402205319
2. Code: Commits https://github.com/withanage/ui-library/commits/9658-users-table

Other results

1. Discussed and analyzed the user-based settings in OJS 3.3 and 3.5
2. A list of requirements, that can be extended
3. Database-based proposal for a system administrator to anonymize user data

SQL script to list fields to anonymize. The list could be used in PHP to count lines and ensure that all fields have been handled:

SELECT
  users.user_id,
  username,
  email,
  phone,
  mailing_address,
  billing_address,
  disabled,
  disabled_reason,
  setting_name,
  setting_value
FROM `users`
JOIN user_settings ON users.user_id = user_settings.user_id
WHERE `email` = “email_address_in_variable”;

Next Steps

1. Create a discussion in pkp-lib with the proposals for the right to be forgotten
2. Parallelly contact known GDPR-Officers and known lawyers (help is welcome)
3. If agreed upon, the database-based solution can be documented as a first step
4. A ticket for implementing the solution into PKP-Software
5. Users table, API integration

Thank you

We once again thank the Sprint host institutions, and all participants for their valuable contributions to the PKP user community. Special thanks to the CRAFT-OA Project and the University of Turin for their support and partnerships.