19:04:49 #startmeeting GDPR IRC meeting 26 February 2018 19:04:49 Meeting started Mon Feb 26 19:04:49 2018 UTC. The chair is josef_moravec. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:04:49 The meeting name has been set to 'gdpr_irc_meeting_26_february_2018' 19:05:10 josef_moravec++ 19:05:14 #topic Introductions (please use "#info" in front of your introduction to have it show up in the automatic minutes) 19:05:23 if you want help, use #chair nick 19:05:30 #info Jon Knight, Loughborough University 19:05:32 #info Katrin Fischer, BSZ Germany 19:05:39 #info Magnus Enger, Libriotech, Norway 19:05:50 #info Josef Moravec, Municipal Library Usti nad Orlici, Czech Republic 19:06:02 #info Michal Denar, Municipal Library Ceska Trebova, Czech Republic 19:07:39 last call for info 19:08:07 #info Pasi Korkalo, Koha-Suomi Oy, Finland 19:09:05 #topic Debate about improvements in Koha code that we collected https://wiki.koha-community.org/wiki/Improve_data_protection_and_patron_privacy 19:09:12 #link https://wiki.koha-community.org/wiki/Improve_data_protection_and_patron_privacy 19:09:39 I've added numbers to the wiki page for reference 19:10:15 josef_moravec++ 19:10:31 #topic Wiki page record 1 ;) 19:11:01 I remember that on last developers meeting there was also debate about this 19:11:14 yes, we discussed merging the tables 19:11:18 but it probably won't happen fast 19:11:31 yes, but that's not the point 19:11:58 the point is to somehow anonymize the data in deletedborrowers table 19:12:09 we need add more privacy = anonymization 19:12:10 I've added an option for anonymization instead of deletion to the wiki page 19:12:11 like remove names and dates of births and so on 19:12:39 cait: that's exactly what we need I think 19:12:43 maybe rewrite significant fields by mess 19:12:53 because i think atm some information would still be useful for statistics - ideally we should move the information into the statistics and action_logs tables maybe 19:12:58 #info Jonathan Druart 19:13:20 yes, we need it only for statictics 19:13:27 cait: please no more action_logs and statistics :D 19:13:52 out action_logs currently have aroung 36 million lines (two years worth), it's getting unmanageable 19:13:56 i think it should be possible to avoid using deletedborrowers at all too 19:14:28 magnuse: so delete patron record forever? 19:14:30 janPasi: thinking about additional columns - not sure how else to do it 19:14:37 could be an option 19:14:39 josef_moravec: yup 19:15:20 magnuse: if you have a lot of deletions, some statistics will be off because some missing 19:15:37 like checkouts by categories or age groups 19:16:06 we've been planning on having a separate mongodb database for "old" action logs and statistics 19:16:37 janPasi_ that is probably the way to go 19:16:48 there's probably gonna be some more logging with gdpr 19:16:54 date of birth should not be cleaned when anonymize, we need age for statistics too 19:17:19 but GDPR restricted saved data out of reason 19:17:23 anonymization should probably be configurable, then 19:17:45 janPasi_: I don't think it is realistic to have it in Koha in may... 19:17:49 magnuse: yes 19:18:21 date of birth is a good identifier - I like the idea of storing the age with the statistics instead 19:18:26 less problematic 19:18:36 cait: yes, that sounds better to me too 19:18:42 agree 19:18:49 josef_moravec: well, perhaps not, things take time with community koha, however we're probably going to do it in finland 19:18:50 we can't just put data off our eyes, into other part of db 19:19:03 true 19:19:04 but having a job that you just tell what NOT to delete might be good 19:19:15 yup 19:20:38 so in short, we need an option for deleting patron record instead moving, and an option to anonymize patron record - this should be configurable. Do we agree? 19:20:48 +1 19:20:51 Yeo 19:20:55 Yep 19:21:02 +1 19:21:20 sounds ok to me 19:21:20 +1 19:21:44 #info Koha need an option for deleting patron record instead moving, and an option to anonymize patron record - this should be configurable. 19:22:09 #action josef_moravec add bugs and describe it 19:22:45 #topic Wiki page record 2 19:23:16 I noticed we talk about patron data rethe 19:23:19 there 19:23:23 what about the link to the staff user? 19:23:47 Staffs are also protected by GDPR 19:23:50 I think ;) 19:24:01 it's what i've been told too 19:24:24 you will want to know who changed a record for a reasonable time, but probably not indefiniteyl 19:24:25 but at the same time we do have to know which staff members deal with with borrowers data 19:24:41 *with which borrowers data (sorry) 19:24:44 true 19:24:52 its about logs 19:24:57 It is ok when the staff is active, but when he/she end an contract? 19:25:34 m23_kohaCZ: so no rerfernces but log the name for example? 19:26:26 why not just anonymize the staff members data when the contract ends? 19:26:26 isn't that the same? both makes them identifiable 19:26:47 cait: probably yes 19:27:12 if staff member is out of job, its same like other borrower 19:27:22 oh, that will be a problem if you use the same account as both borrower and staff account 19:27:33 so the anonymization should work with staff references too 19:28:02 maybe haven options to set them up differently 19:28:30 probably we'd need to take closer look at the individual data 19:28:56 I think that staff rulez be managet by some legal notice with library 19:29:15 What happens if GDPR conflicts with a data retention order? In the UK the Government can demand logs to be kept (for anti-terror, etc reason). 19:29:20 but theis data about issues its same like regular borrower 19:30:23 to clarify, i was thinking about action_logs where you can see who did that checkout 19:30:36 very useful if you want to see what the self check user does... :) 19:31:05 and the self check user is probably not protected by gdpr ;-) 19:31:30 might be a real exception:) 19:31:33 maybe we should move on? 19:32:25 and than it is more on the library side, not on system side 19:32:25 janPasi_: good point, staff could end contract but still could be patron 19:32:27 in that case we need to anonymize just staff references 19:32:29 ;) 19:32:31 ok, moving on 19:32:33 #topic Wiki page record 3 19:32:54 #chair cait 19:32:54 Current chairs: cait josef_moravec 19:33:12 cait: have an unstable connection so if needed 19:33:20 ok 19:33:33 With item 3, we currently make use of old loan information to drive purchasing decisions. How would anonymisation work and would it affect that? 19:33:59 I think here we need just to add an UI to staff client... 19:34:21 josef_moravec: can you explain? 19:34:48 Especially as it says, "Privacy can only be changed by the patron after logging in to the OPAC, not by librarians through the staff interface" 19:34:54 greenjimll: anonymization just replaces the actual borrowernumber with the value of the AnonymousPatron syspref 19:34:55 greenjimll: why would anonymisation have effect on that, the data will still be there, just anonymised? 19:35:33 greenjimll: or do you make purchases based on loan histories of persons called Bob? ;D 19:35:38 patrons are able to change the privacy option in opac, but no all patron do that, they often need assistance, so that's the reason why we would like to be able make this setting in staff client 19:35:42 Because the borrower information is used to link the loan to someone one a particular module (part of University course) and thence to their department and thus purchasing budget(s). 19:35:43 you can see how often a book was borrowed, but not if it was borrowed by students or professors 19:35:47 records about issues will be in database but no linked to borrower 19:36:02 but the privacy functionalit in Koha is good 19:36:03 greenjimll: that's already how it works - so no change suggested here. if you allow users to change the PatronPrivacy settings 19:36:24 you might want to check that 19:37:05 I think we just need to fill a bug for this now 19:37:26 I agree 19:37:46 josef_moravec: what change are you suggesting for the bug? 19:38:39 add an UI for setting patrons privacy from staff client 19:39:12 Isn't that the opposite of what is suggested on the wiki? 19:39:38 which will then be the one we follow? the one set by the borrower or the one set by the staff? or the latest? 19:39:49 i think that was not done on purpose 19:39:58 the argumentation was that you shoudl not be able to change what the patron set 19:40:01 which purpose 19:40:02 ? 19:40:15 you can create them with a default, but not change their choice 19:40:50 we could still have a UI - maybe have a permission for it or setting 19:40:54 that does make sense for me, but it is a bit inpractical 19:41:08 cait: good point 19:41:17 Project Koha_17.11_D8 build #30: SUCCESS in 43 min: https://jenkins.koha-community.org/job/Koha_17.11_D8/30/ 19:42:14 it's similar for 'can i see the books of my guarantees' 19:42:23 this can also not be changed by staff, only by patrons themselve 19:42:23 s 19:42:50 the checkouts i mean 19:43:11 Not something that affects us at the University, but who gets to set the flag for minors? 19:43:15 and whats about borrowet that dont use their OPAC 19:44:04 i think you can argument both ways 19:44:06 staff shold have change this at staff client 19:44:08 just maybe has to be an option :) 19:44:11 like lots of things 19:44:26 #action josef_moravec added notes to wiki page and will fill a bug 19:44:38 yes, more options, more Koha ;) 19:44:47 yeah 19:44:50 +1 19:44:56 Koha is very flexibile 19:45:07 moving on 19:45:28 #topic Wiki page record 4 19:46:01 some concerns or questions here? 19:46:33 sec 19:46:52 ah, just about how to do that technically maybe? 19:47:14 i have no idea yet ;) 19:47:23 ok ;) 19:47:27 Is it a role for any reporting, or just ones that touch "personal data" holding tables? The former surely? 19:47:31 add new rule for staff and new option at report 19:47:48 hm 19:47:54 the on options could be a flag set by report creater? That's the easiest solution ;) 19:48:00 like have a flag on the report to suggest it contains personal information 19:48:13 and split permissions to run normal and 'personal' reports? 19:48:23 yeah 19:48:26 greenjimll: yeah, the reports wii personal data 19:48:28 i think we all agree :) 19:48:36 great! 19:48:52 So the report creator will need this role in order to make any reports? 19:48:56 yeah, it's just how to do it 19:49:00 so this would be for executing reports - probably not possible to restrict for creating? 19:49:24 yes, that's how it would work in that case 19:49:32 Allowing you to (potentially) create a report you can't run? 19:50:03 greenjimll: the problem is... how do you restrict writing reports to not contain personal inormation? 19:50:03 it would be hard to limit what the report creator can access in the database 19:50:04 you could try and look for reports that use e.g. the borrowers table 19:50:07 yes, or bypass the permission by not to flag it 19:50:18 janPasi_: yes exactly 19:50:23 but not sure how safely that can be done 19:50:30 you'd need two database users and then limit their permissions on the database tables 19:50:34 would also rule out reports that only group by patron category 19:50:45 If you need the new role in order to create reports, doesn't that solve the issue? 19:50:57 cait: good point 19:51:09 the new permission would be to be able to run reports marked with a special flag 19:51:33 But you could also say that to create a report you'd need to new permission too. 19:51:37 there is already separate permissions at the moment for running, creating and deleting reports 19:51:55 splitting creating into 'harmless' and 'not harmless' would be hard 19:52:17 not to mention it's hard to predict what will be harmless ;) 19:52:39 if somebody has rule for creating report, this person logically can make every report 19:53:10 you could 1. Start a transaction, 2. update borrowers set critical_fields=null; 3. execute the SELECT query 4. rollback 19:53:17 its no moblem, problem is to make smaller goour of staff that can run reports that contain personal data 19:53:26 Joubu: that does sound kind of scary 19:53:41 why that? 19:53:50 it's just an idea :) 19:54:51 I'm guessing #5 is going to have similar issues (hence the same bug number)? 19:55:00 greenjimll: yes 19:55:15 i think 5 would be even harder as we basically have no control on what a plugin does 19:55:31 Joubu: i don't see how that would work :D 19:55:51 Joubu: what is 15 other people access the borrowers table between the update and the rollback? 19:56:11 Joubu: won't they get bogus information then? 19:56:40 heh you will need to lock the table, which can be a problem for big queries 19:56:57 At what point is it the local Koha admin's responsbility to ensure that plugins/reports meet GDPR? We run the risk of creating unworkable complications when local policies might be better? 19:57:01 I don't think it's a practical solution right now 19:57:10 Joubu: but that will stop the whole system then, won't it? 19:57:16 creator of plugin flag it l= contains personal data, just staff with rule can run it 19:57:22 greenjimll: it#s totalyl in your responsibility to check the plugins you install 19:57:32 cait: exactly. 19:57:53 ideally a good plugin should include information about what data it touches, changes and maybe stores additionally 19:58:27 +1 19:58:27 so you have a good base for your own docs, but as anyone can provide plugins and they don't go through qa or code checking ... 19:58:41 maybe configuration of plugin can give control to liste staff IDs 19:58:54 yeah, plugins have to be out of scope, i think 19:59:00 m23_kohaCZ: you could implement that already, but it#s up tot he plugin writer 19:59:15 they are not restrictable in any way 19:59:30 cait: yes 19:59:41 i think best we could do is have recommendations 19:59:53 and maybe a list of 'good' plugins thatsomeone has checked with added documentation 20:00:02 yes, we can' control them, so it's alway admin responsibility, we could just provide a way how to declare that it contains personal data, but no more than this 20:00:59 i think the plugins ar just perl scripts... if they used the rest api you might be able to limit them at some point 20:01:13 move on #6? 20:01:18 like apps on your phone : wants access to... - but we are not there yet 20:01:28 yep 20:01:55 skipping 5 20:02:05 #topic Wiki page record 6 20:02:26 if you have a list of "good" plugins you will need to keep an eyes on them to make sure they are still "good" few months later 20:02:27 ü1 20:02:29 +1 20:02:57 now it is doable by server admin 20:03:32 but at least an enhancement to koha-dump would be nice 20:03:57 just add new option --encrypt dump 20:03:59 What encryption is used or is that configurable? Would it have export implications for some Koha sites? 20:04:25 m23_kohaCZ: 20:04:28 m23_kohaCZ: yes 20:04:41 but we need to configure a key somehow 20:04:49 greenjimll: this is just for your backups - emergency recovery 20:05:04 greenjimll: not for other types of exports 20:05:13 greenjimll: and not one way - you can unencrypt of course 20:05:16 decrypt? 20:05:39 Doesn't matter what its for: its restriction on code export in Koha or use of encrypytion in some places. 20:06:32 sorry, i might not understand you 20:07:03 encryption of backup is here for protecting of data in backup = I can decrypt it if I know paasword 20:07:05 For example doesn't France require export and import of cryptographic tools from foreign states to be declared or have explicit authorisation? 20:07:16 ? 20:07:20 sysadmins can take care of that, right? 20:07:23 https://en.wikipedia.org/wiki/Cryptography_law 20:07:39 Joubu: yes 20:07:58 greenjimll: i tihnk usually you'd use a standard encryption 20:08:40 i was told we HAVE to encrypt backups 20:09:25 Joubu: but the debian scripts offer out of the box backup/restore functionality, so they should be able to encrypt/decrypt to 20:10:46 cait: You may well have to encrypt backups. What I'm point out is that putting encryption code in Koha (rather than just letting the sysadmin encrypt with his normal tools) may pose some legal implications in some countries. 20:10:58 Note: I am not a lawyer though. :-) 20:11:16 we don't do that 20:11:26 i think mysql toold might allready support it 20:11:40 we are not implementing our own encryption 20:11:59 sorry for all the typos tonight 20:12:04 encrypt is option, if its not legal in some coutry, its admin decisition if use it 20:12:40 Its not the use: its the import/export. But I'll give up now. :-) 20:12:55 you'd need somekind of public-key encryption for it to make any sense, otherwise you'd have to store the password somewere to automate dumping 20:13:10 which would kind of defeat the purpose 20:13:22 but for GDPR point of view its protection for privat data stored on backup drive 20:13:28 janPasi_: true 20:14:18 just for interest https://mysqldump-secure.org/ 20:14:21 greenjimll: we might just be misunderstanding each other 20:14:49 moving on? 20:15:20 yeah 20:15:30 Yes 20:15:31 what's the conclusion? 20:15:38 Its complicated. :-) 20:15:52 good conclusion :D 20:15:53 we need this option :-) 20:16:11 you can create a wiki page to explain people how to excrypt their dump 20:16:24 if it is the point, but I am sure good sysadmins will use their own workflow 20:16:27 sorry, i gotta run, will read the log 20:16:30 Joubu: that's sounds like the best idea to me. 20:16:38 and will not use a possible --encrypt flag they do not know what it does 20:17:05 but yeah, move on, I will comment on the bug ) 20:17:30 Conclusion - start with a wiki page, it is enough for now, as it is a system admin responsibility 20:17:55 #topic Wiki page record 7 20:19:55 There is proposal of adding an age column to statistics table, for us it is very important, especialy when we remove date of birth during anonymization as discussed in one of previous topics 20:20:16 Sounds reasonable - could it just be an enhancement bug? 20:20:25 easy to implement it, but local use 20:20:43 josef_moravec: can't it be done locally in czech koha installations? 20:21:05 I vote for add it into master Koha 20:21:16 #action josef_moravec file bug for adding age to statistics table 20:21:52 because no all instalation in CZ use KohaCZ package 20:22:04 janPasi_: coud be, but I think it would be useful for others too 20:22:24 we'd be interested in it too 20:22:24 Might be of use in other countries too (I'm thinking public libraries more than Universities) 20:22:35 i know that another system is also using this approach 20:22:36 I agree with Josef 20:22:48 the age is not important for the academics so much, but for the public libraries 20:22:56 maybe I am completely out of context here but we could keep the date of birth on anonymizing a record 20:22:58 filling the column could be optional 20:23:07 Joubu: it's a sensitive data 20:23:09 if it is not linked with other info 20:23:18 too eay to figure out who it was 20:23:20 yes but you do not know who 20:23:41 ok 20:24:36 Joubu: imagine small village with 100 people, it is easy to know who it was, and we have many libraries in these villages here... 20:25:20 josef_moravec: it will probably be easy to guess that from plain age too, we have such villages also ;) 20:25:46 janPasi_: maybe ;) 20:25:46 :) 20:26:16 File a bug/enhancement then? 20:26:21 It is not so easy, when you start thinking about it... 20:26:29 * Joubu needs to set his paranoid mode on 20:26:33 #action josef_moravec fill a bug 20:26:57 move on? 20:27:11 josef_moravec: make it optional like storing the last user? 20:27:24 cait: yes 20:27:55 move on? 20:27:59 #topic Wiki page record 8 20:28:53 Logging of koha-* scripts, we now log just perl cronjobs 20:29:16 I have no idea how to do it yet ;) 20:29:56 rewrite koha-* scripts in perl, it will be easy then ;) 20:30:41 Are make a REST API endpoint? 20:30:51 s/Are/Or/ 20:32:46 you mean log running them in the database? 20:32:47 You can write a misc script in perl you will call from the koha-* scripts 20:33:10 that shouldn't be too hard with *sh either 20:33:25 Joubu: it does make sense, and will be easy 20:33:54 janPasi_: nope, but certainly easier in perl, and could be reuse 20:34:55 Yes would be easy, i see it now, but still better to do it in perl - better not to access database directly with sql, but use the koha code 20:35:17 moving on? 20:35:33 what info do we need to log concernign backups? 20:36:04 Radius_CZ: Just like other cronjobs, just the information it was run 20:36:16 ok then 20:36:30 But if you wan't to enhance it, you could make a patch ;) 20:36:55 moving on 20:37:33 #topic Wiki page record 9 20:37:48 staff client access restrictin 20:38:14 again maybe more for sysadmins 20:38:38 Should 2FA be handled through the web server or similar services (eg single sign on IdPs)? 20:38:40 we have used client certificates + apache configuration for one customer - but it's no easy to maintain 20:39:17 2f is combination of knowledge and possession, correct? 20:39:22 Cait: can you publish some tips on wiki? 20:39:37 not sure, we are trying to get rid of it actually 20:39:54 you could combine 2fa and ip restriction 20:39:57 2FA can mean lots of things. For example might be username+password, plus SMS code sent to phone (bad) or USB crypto dongle code (good) 20:39:58 and I think it might have problems with plack - but not sure 20:40:27 single sign on might not qualify then -it's just pw 20:41:22 whats about some IP whitelist? 20:41:33 i think improving autolocation could be a start 20:41:36 Single sign on can use 2FA - we've linked our development IdP to a test privacyIDEA server (https://www.privacyidea.org/) 20:41:42 i know a lot of kohas are still publicly available 20:41:50 cait: good idea 20:42:19 greenjimll: interesting 20:42:33 cait: Works with UbiKeys as well. :-) 20:42:44 the IP restrictions using apache configuration setup to allow whitelist seems also good to me. we shuld prepare some wiki howto as well. 20:43:17 some smaller libraries don't have static ips 20:43:27 that's right 20:43:31 I think we need also to somehow restrict the database user, when it is not needed after installation 20:43:44 so having another option as well would be good 20:44:01 so definitely some 2fa needed? 20:44:05 privacyIDEA is cool 20:44:42 hm, looks really interesting 20:44:50 2fa is very useful aditional security option 20:44:57 +1 for 2FA 20:45:17 i noticed koha has AllowPKIAuth - someone used this? 20:45:21 we've some bug about 2fa 20:45:52 client certificates could be good, but maybe koha supporting them not via apache only 20:46:15 https://screenshots.firefox.com/7IYEz32V51HxxHEK/hea.koha-community.org 20:47:13 hm that's not too bad 20:48:17 at least more then nothing ;) 20:48:27 :) 20:49:01 is it useful on shared staff pCs? 20:49:03 i thnk we need to gather some more ideas, maybe on the bug? 20:49:25 I agree with Cait 20:49:52 bug 19886 20:49:52 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19886 enhancement, P5 - low, ---, koha-bugs, NEW , Two Factor Authentication: Yubikey 20:49:56 bug 19887 20:49:56 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19887 enhancement, P5 - low, ---, koha-bugs, NEW , Two Factor Authentication: Google Authenticator 20:50:05 m23_kohaCZ: we used one for all i think... but that's not ideal 20:50:59 #action more investigatin of 2FA needed, we will collect information on bug reports 20:51:15 agree 20:51:51 #topic Wiki page report 10 20:52:57 i don't think it will be useful for anyone... but we have been asked about it already 20:53:12 a way to export all your data from somewher ein the patron account? 20:53:24 rest api endpoint? 20:53:25 if you take this serious, there is a lot of tables involved 20:53:27 cait: it is not very useful but needed by GDPR as I think 20:53:34 #10 cna be like new button on patron detail or some plugin 20:53:35 agreed 20:53:45 the problem is mkaing sure you include all data 20:53:56 ratings, reviews, checkouts, comments, address changes... 20:54:12 if you take it serious, it's a lot of tables to be checked for the patron number 20:54:17 holds, payments.... 20:54:24 yes, that's what i think is he way, but the main problem really is to define what should be in the export 20:54:25 loans that have been anonymised... oh, er, no. :-) 20:54:36 greenjimll: ;) 20:54:57 I would vote for a plugin ;-) 20:55:02 and should be machine readable so JSON or CSV 20:55:29 JSON would be more extensible in the future. 20:55:35 greenjimll: agree 20:55:48 it is more flexible 20:55:49 yes, plugin with JSON export to a file 20:55:58 so, mlutilanguague GDPR plugin? 20:56:19 Koha Take Out(tm). 20:56:32 why not provide the patron him/herself with access to her/his data directly via rest? 20:56:34 josno nice way to integrate plugins into the opac right now 20:56:42 we should avoid a solution that requires local changes 20:56:48 and also plugins are not translatable 20:56:51