Improve data protection and patron privacy

Just a starting point for - 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. 	
* - 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?
* - Print patrons before anonymise
* - More database cleanups (statistics, deleted catalog, deleted patrons, old issues, old reserves, item transfers)
* - More database cleanups (old messages).
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	
* Add a UI for this to staff client - with permission
* - More database cleanups (statistics, deleted catalog, deleted patrons, old issues, old reserves, item transfers)
4 	Prio 2 	 	Reports 	If you have access to write reports, you can gather all the personal information you want 	 	- 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 	 	- 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 	- 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. 	
* Add the age column to statistics table? And make storing age configurable
* Add new fields
* Also a good idea to add category code to statistics? Very important for academic libraries. (TBD) 
* 
* - More database cleanups (statistics, deleted catalog, deleted patrons, old issues, old reserves, item transfers)
8 	Prio 3 	 	Log 	Every run of koha-dump should be logged similar to cronjob log 	 	- 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. 	- 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) 	DONEUse 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 - GDPR: Add a consent field for processing personal data in account menu and self-registrationIntroduced 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. 	* - 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 for some discussion around this. 	DONE 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.	- 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.	 	- 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.	 	- 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.	 	- 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 	- 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.
Category:Development
Category:GDPR