Improve data protection and patron privacy

From Koha Wiki

Jump to: navigation, search
Home
Home > Documentation > GDPR
Koha > Technical > Development

Just a starting point for Bug 18081 - EU General Data Protection Regulation (GDPR) 2018

Number Priority Responsible Area Comment Current status Needs development
1 Prio 1 Josef deletedborrowers When borrowers are deleted, their data is not really deleted, but moved to the deletedborrowers table. No script for regularly deleting from the table.
  • Bug 13667 - Provide script to regularly clean deletedborrowers table
  • Bug 20604 - Provide script to anonymize instead of deleting (keep patron category, homebranch, bsort1, bsort1) to allow for use in statistics
  • Syspref to completely disable the use of the deletedborrowers table, so that deleted patrons are really deleted?
  • Bug 20645 - Print patrons before anonymise
2 Prio 2 Logs (action_logs) Some logs contain a connection between a patron and an item The cronjob cleanup_database.pl can delete log entries that are older than x days A script for anonymizing the logs, without deleting them completely?
3 Prio 2 Privacy/anonymization When a loan is returned, all data is moved to the old_issues table, potentially including the borrowernumber of the patron.
  • If the borrower has borrower.privacy = Never, the issue is anonymized when it is moved to old_issues.
  • If the borrower has borrower.privacy = Default, the issue is anonymized when the cronjob batch_anonymise.pl is run. This is not set up automatically. The cronjob can only anonymize old loans that are older than 1 day ("--days 0" gives an error).
  • If the borrower has borrower.privacy = Forever, the issue is not anonmized before the patron chooses to anonymiza it herself, or changes her privacy setting
  • Default privacy can be set by the library on a per patron category basis
  • Privacy can only be changed by the patron after logging in to the OPAC, not by librarians through the staff interface
Bug 20605 Add a UI for this to staff client - with permission
4 Prio 2 Reports If you have access to write reports, you can gather all the personal information you want Bug Bug 20026 - Add new permission related to personal data and ability to flag reports as containig sensitive data.
5 Prio 3 Plugins Plugins can contain queries that reveal any personal information Bug Bug 20026 - Add new permission related to personal data
6 Prio 4 Backups The package installs automatically create backups, one of the database, one of configs, logs etc. Backups are compressed but not encrypted Bug Bug 20024 - Backup files should be encrypted
7 Prio 1 Josef Statistics In Czech Republic, we need to know the age of patron at the time of checkout because of statistics for Ministry of Culture. When the history of patron is deleted, we do not have this information.
  • Bug 20606 Add the age column to statistics table? And make storing age configurable
  • Also a good idea to add category code to statistics? Very important for academic libraries. (TBD) Bug 7021
  • Bug 21055
8 Prio 3 Log Every run of koha-dump should be logged similar to cronjob log Bug 20025 - Log running koha-*
9 Prio 2 Administration Staff client should not be publicly accessed, even the access to login form should be restricted. Now we have only AutoLocation syspref, but it allows to define only one IP per library, and login form is always shown - koha database user could log in in every case, or somebody could try to guess the password.
  • We should at least make some documentation how to set up apache and other web servers to deny all IP and just white list IPs which could access
  • Two factor auth for staff client?
10 Prio 2 Patrons data portability We need one tool to export all patron related data in machine readable format at least CSV Art 20 We can export patron data from tools via staff client, but without all related data. We can print some data, but that is not machine readable. Bug 20028 - Export all patron related data as one file
11 Prio 2 Cookies Do we need one of those "This site uses cookies, click here to agree" thingies? [marcelr: AFAIK we only use functional cookies in Koha. And those do not need a banner.]
12 Prio 2 BSZ Cookies Maintaining documentation about the use of cookies in Koha (description of use, storage duration, values) DONE
Use of Cookies and DOC1 in Coding Guidelines
13 Prio 3 Privacy statement/Agreement We need a way of presenting a privacy statement/agreement that outlines all the private information that is being collected by the system and what the institution will do with that data. The agreement must be explicitly accepted by a self-registered user and a record of that acceptance must be stored (potencially as a log entry - Art 7 the consent can be undone and a checkbox is ok if this is clear). For users that are created administratinvely, I guess the agreement can be presented and accepted by other means (e.g. paper). Art 6.1.a  ? Bug 20819 - GDPR: Add a consent field for processing personal data in account menu and self-registration
14 Prio 4 Apache access logs Can correlate an IP address (which is usually PII) with records viewed Having a strict by default logrotate policy or something could be good
15 Prio 1 old_reserves old_reserves keeps the link to borrowers until the borrower is deleted. Need a way to anonymize. Needs investigation on how best to implement it: new script or enhance existing.
16 Fines When a fine is paid, information like "paid for by (Patron name and barcode) DATE TIME" is added to items.paidfor. It is unclear why this information is stored, and there is no way to (periodically) clean it. See Bug 19919 for some discussion around this. What to do? Remove items.paidfor? Make it optional via a syspref?
17 TBD Marcel Request account deletion Art 17 - Right to erasure "Right to be forgotten" See bug 20819. I propose to add a consent tab in opac-user and also a pref GDPR_Policy. If you set the pref to Enforced, you can only continue after login when you give your consent. A refusal is interpreted as a request to unsubscribe. Bug 20819 - GDPR: Add a consent field for processing personal data in account menu and self-registration
18 Prio 1 Batch patron deletion/anonymization tool Add "preview" into Batch patron deletion/anonymization. Befere dete/anonymization user must see list of borrowes that match selected search parameters. This list should be exportable/printable because some libraries must shred paper contracts after anonymization of records in Koha.
19 TBD Patron password forced renew Under the auspices of the recently issued European legislation regarding data privacy (GDPR), the Portuguese government has issued a series of mandatory requirements, as well as general recommendations, for software applications that are implemented under the umbrella of public bodies (RCM 41/2018).

Since Koha is mostly used by municipalities and universities in Portugal, some of these mandatory requirements need to be address by Koha implementers in Portugal.

We believe that this requirement is also useful for the community at large. Here’s a description of the requirement.

Requirement description

The application MUST ensure that the user changes his password frequently. If the user doesn’t change is password it should be impeded from using the application until he does so.

Having a setting where one can define the number of days until a password becomes invalid is necessary. The recommendation is 6 months for standard users, and 3 months for administrators.

Scope

Only applicable for passwords managed by Koha. When using a centralized authentication system, this task should be managed by the central authentication system.

Bug 21187 - GDPR: GDPR: Force patrons password renew
20 TBD Log (CRUD patron data) Under the auspices of the recently issued European legislation regarding data privacy (GDPR), the Portuguese government has issued a series of mandatory requirements, as well as general recommendations, for software applications that are implemented under the umbrella of public bodies (RCM 41/2018).

Since Koha is mostly used by municipalities and universities in Portugal, some of these mandatory requirements need to be address by Koha implementers in Portugal.

We believe that this requirement is also useful for the community at large. Here’s a description of the requirement.

Requirement description

Every operation that has to do with creating, updating, deleting and changing permissions of user personal data should be logged.

One should know who, when, on who and from the operation has been performed.

Scope

Applies in all cases.

Bug 21189 - GDPR: Log all CRUD actions on patron data
21 TBD Log (Successful/unsuccessful login) Under the auspices of the recently issued European legislation regarding data privacy (GDPR), the Portuguese government has issued a series of mandatory requirements, as well as general recommendations, for software applications that are implemented under the umbrella of public bodies (RCM 41/2018).

Since Koha is mostly used by municipalities and universities in Portugal, some of these mandatory requirements need to be address by Koha implementers in Portugal.

We believe that this requirement is also useful for the community at large. Here’s a description of the requirement.

Requirement description

The application MUST log successful and unsuccessful authentication operations. This is useful, for example, to detect that a user account is being hacked.

Scope

Applies in all cases.

Bug 21190 - GDPR: Log successful/unsuccessful login attempts
22 TDB Patrons block Under the auspices of the recently issued European legislation regarding data privacy (GDPR), the Portuguese government has issued a series of mandatory requirements, as well as general recommendations, for software applications that are implemented under the umbrella of public bodies (RCM 41/2018).

Since Koha is mostly used by municipalities and universities in Portugal, some of these mandatory requirements need to be address by Koha implementers in Portugal.

We believe that this requirement is also useful for the community at large. Here’s a description of the requirement.

Requirement description

The application MUST record the time of a user last logged in. It should have a method to inactivate users that haven’t logged into the application for over X number of months (new setting).

Scope

Applies to implementations where user authentication is handled by Koha.

Relation with entry 21 Bug 21191 - GDPR: Script to block inactive users (with no successful logins on a defined period)

Questions

  • It is imperative that patron information is maintained for transaction audits. If we have to go back and look at who paid a particular fine or fee 2 years ago, we are in hot water if we can't pull up that information. Some libraries tied to government organizations (City government) are required to retain transaction information for x numbers of years. Perhaps patron information tied to transactions should be encrypted. So, even though it is in a table in the koha database, it can't be utilized for anything else besides looking up information linked to transactions.
  • How to present information to the borrower ? For the moment, we can use OpacLoginInstructions to display data at login. It could be great to link to a page explaining the things inside koha like a news. To link directly a news we should have something like [Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14980 14980]. How do you manage that in your libraries ? (Asking the consent is of course better and the bug 20819 :)


Notes

  • 6 and 14 can already be done by system administrators.

Andreas (andreashm) will try to make the time to test, if/when patches are available.

Open source CMS Joomla creates "[Privacy framework]https://docs.joomla.org/J3.x:Privacy". It's some things at core of system, developer guidelines. Maybe we can inspire. In short: all tyopes of private data was defined and if developer use them at any part of code (core, modules, plugins) must follow some gudelines. Core of system nac handle private data and provide basic tools and statistic.

Personal tools