Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .Improve data protection and patron privacy
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. |
|
| 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. |
|
||
| 4 | Prio 2 | Reports | If you have access to write reports, you can gather all the personal information you want | 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 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 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. |
|
| 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. |
| |
| 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 | DONE Bug 20819 - GDPR: Add a consent field for processing personal data in account menu and self-registration Introduced in Koha 18.11. |
||
| 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. | *Bug 19008 - More database cleanups (statistics, deleted catalog, deleted patrons, old issues, old reserves, item transfers) | |
| 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. | DONE Bug 19919 makes Koha stop using items.paidfor. This fix will be in Koha 19.11. |
|||
| 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.