19:04:49 <josef_moravec> #startmeeting GDPR IRC meeting 26 February 2018
19:04:49 <huginn> 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 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:04:49 <huginn> The meeting name has been set to 'gdpr_irc_meeting_26_february_2018'
19:05:10 <magnuse> josef_moravec++
19:05:14 <josef_moravec> #topic Introductions (please use "#info" in front of your introduction to have it show up in the automatic minutes)
19:05:23 <cait> if you want help, use #chair nick
19:05:30 <greenjimll> #info Jon Knight, Loughborough University
19:05:32 <cait> #info Katrin Fischer, BSZ Germany
19:05:39 <magnuse> #info Magnus Enger, Libriotech, Norway
19:05:50 <josef_moravec> #info Josef Moravec, Municipal Library Usti nad Orlici, Czech Republic
19:06:02 <m23_kohaCZ> #info Michal Denar, Municipal Library Ceska Trebova, Czech Republic
19:07:39 <josef_moravec> last call for info
19:08:07 <janPasi_> #info Pasi Korkalo, Koha-Suomi Oy, Finland
19:09:05 <josef_moravec> #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 <josef_moravec> #link  https://wiki.koha-community.org/wiki/Improve_data_protection_and_patron_privacy
19:09:39 <josef_moravec> I've added numbers to the wiki page for reference
19:10:15 <cait> josef_moravec++
19:10:31 <josef_moravec> #topic Wiki page record 1 ;)
19:11:01 <josef_moravec> I remember that on last developers meeting there was also debate about this
19:11:14 <cait> yes, we discussed merging the tables
19:11:18 <cait> but it probably won't happen fast
19:11:31 <josef_moravec> yes, but that's not the point
19:11:58 <josef_moravec> the point is to somehow anonymize the data in deletedborrowers table
19:12:09 <m23_kohaCZ> we need add more privacy = anonymization
19:12:10 <cait> I've added an option for anonymization instead of deletion to the wiki page
19:12:11 <josef_moravec> like remove names and dates of births and so on
19:12:39 <josef_moravec> cait: that's exactly what we need I think
19:12:43 <m23_kohaCZ> maybe rewrite significant fields by mess
19:12:53 <cait> 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 <Joubu> #info Jonathan Druart
19:13:20 <josef_moravec> yes, we need it only for statictics
19:13:27 <janPasi_> cait: please no more action_logs and statistics :D
19:13:52 <janPasi_> out action_logs currently have aroung 36 million lines (two years worth), it's getting unmanageable
19:13:56 <magnuse> i think it should be possible to avoid using deletedborrowers at all too
19:14:28 <josef_moravec> magnuse: so delete patron record forever?
19:14:30 <cait> janPasi: thinking about additional columns - not sure how else to do it
19:14:37 <josef_moravec> could be an option
19:14:39 <magnuse> josef_moravec: yup
19:15:20 <cait> magnuse: if you have a lot of deletions, some statistics will be off because some missing
19:15:37 <cait> like checkouts by categories or age groups
19:16:06 <janPasi_> we've been planning on having a separate mongodb database for "old" action logs and statistics
19:16:37 <magnuse> janPasi_ that is probably the way to go
19:16:48 <janPasi_> there's probably gonna be some more logging with gdpr
19:16:54 <josef_moravec> date of birth should not be cleaned when anonymize, we need age for statistics too
19:17:19 <m23_kohaCZ> but GDPR  restricted saved data out of reason
19:17:23 <magnuse> anonymization should probably be configurable, then
19:17:45 <josef_moravec> janPasi_: I don't think it is realistic to have it in Koha in may...
19:17:49 <m23_kohaCZ> magnuse: yes
19:18:21 <cait> date of birth is  a good identifier - I like the idea of storing the age with the statistics instead
19:18:26 <cait> less problematic
19:18:36 <magnuse> cait: yes, that sounds better to me too
19:18:42 <josef_moravec> agree
19:18:49 <janPasi_> josef_moravec: well, perhaps not, things take time with community koha, however we're probably going to do it in finland
19:18:50 <m23_kohaCZ> we can't just put data off our eyes, into other part of db
19:19:03 <magnuse> true
19:19:04 <cait> but having a job that you just tell what NOT to delete might be good
19:19:15 <magnuse> yup
19:20:38 <josef_moravec> 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 <cait> +1
19:20:51 <greenjimll> Yeo
19:20:55 <greenjimll> Yep
19:21:02 <m23_kohaCZ> +1
19:21:20 <janPasi_> sounds ok to me
19:21:20 <magnuse> +1
19:21:44 <josef_moravec> #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 <josef_moravec> #action josef_moravec add bugs and describe it
19:22:45 <josef_moravec> #topic Wiki page record 2
19:23:16 <cait> I noticed we talk about patron data rethe
19:23:19 <cait> there
19:23:23 <cait> what about the link to the staff user?
19:23:47 <josef_moravec> Staffs are also protected by GDPR
19:23:50 <josef_moravec> I think ;)
19:24:01 <cait> it's what i've been told too
19:24:24 <cait> you will want to know who changed a record for a reasonable time, but probably not indefiniteyl
19:24:25 <janPasi_> but at the same time we do have to know which staff members deal with with borrowers data
19:24:41 <janPasi_> *with which borrowers data (sorry)
19:24:44 <cait> true
19:24:52 <m23_kohaCZ> its about logs
19:24:57 <josef_moravec> It is ok when the staff is active, but when he/she end an contract?
19:25:34 <josef_moravec> m23_kohaCZ: so no rerfernces but log the name for example?
19:26:26 <janPasi_> why not just anonymize the staff members data when the contract ends?
19:26:26 <cait> isn't that the same? both makes them identifiable
19:26:47 <josef_moravec> cait: probably yes
19:27:12 <m23_kohaCZ> if staff member is out of job, its same like other borrower
19:27:22 <janPasi_> oh, that will be a problem if you use the same account as both borrower and staff account
19:27:33 <josef_moravec> so the anonymization should work with staff references too
19:28:02 <cait> maybe haven options to set them up differently
19:28:30 <cait> probably we'd need to take closer look at the individual data
19:28:56 <m23_kohaCZ> I think that staff rulez be managet by some legal notice with library
19:29:15 <greenjimll> 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 <m23_kohaCZ> but theis data about issues its same like regular borrower
19:30:23 <cait> to clarify, i was thinking about action_logs where you can see who did that checkout
19:30:36 <cait> very useful if you want to see what the self check user does... :)
19:31:05 <magnuse> and the self check user is probably not protected by gdpr ;-)
19:31:30 <cait> might be a real exception:)
19:31:33 <cait> maybe we should move on?
19:32:25 <josef_moravec> and than it is more on the library side, not on system side
19:32:25 <josef_moravec> janPasi_: good point, staff could end contract but still could be patron
19:32:27 <josef_moravec> in that case we need to anonymize just staff references
19:32:29 <josef_moravec> ;)
19:32:31 <josef_moravec> ok, moving on
19:32:33 <josef_moravec> #topic Wiki page record 3
19:32:54 <josef_moravec> #chair cait
19:32:54 <huginn> Current chairs: cait josef_moravec
19:33:12 <josef_moravec> cait: have an unstable connection so if needed
19:33:20 <cait> ok
19:33:33 <greenjimll> 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 <josef_moravec> I think here we need just to add an UI to staff client...
19:34:21 <cait> josef_moravec: can you explain?
19:34:48 <greenjimll> 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 <magnuse> greenjimll: anonymization just replaces the actual borrowernumber with the value of the AnonymousPatron syspref
19:34:55 <janPasi_> greenjimll: why would anonymisation have effect on that, the data will still be there, just anonymised?
19:35:33 <janPasi_> greenjimll: or do you make purchases based on loan histories of persons called Bob? ;D
19:35:38 <josef_moravec> 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 <greenjimll> 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 <magnuse> you can see how often a book was borrowed, but not if it was borrowed by students or professors
19:35:47 <m23_kohaCZ> records about issues will be in database but no linked to borrower
19:36:02 <josef_moravec> but the privacy functionalit in Koha is good
19:36:03 <cait> greenjimll: that's already how it works - so no change suggested here. if you allow users to change the PatronPrivacy settings
19:36:24 <cait> you might want to check that
19:37:05 <josef_moravec> I think we just need to fill a bug for this now
19:37:26 <m23_kohaCZ> I agree
19:37:46 <cait> josef_moravec: what change are you suggesting for the bug?
19:38:39 <josef_moravec> add an UI for setting patrons privacy from staff client
19:39:12 <greenjimll> Isn't that the opposite of what is suggested on the wiki?
19:39:38 <janPasi_> 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 <cait> i think that was not done on purpose
19:39:58 <cait> the argumentation was that you shoudl not be able to change what the patron set
19:40:01 <josef_moravec> which purpose
19:40:02 <josef_moravec> ?
19:40:15 <cait> you can create them with a default, but not change their choice
19:40:50 <cait> we could still have a UI - maybe have a permission for it or setting
19:40:54 <josef_moravec> that does make sense for me, but it is a bit inpractical
19:41:08 <josef_moravec> cait: good point
19:41:17 <jenkins> 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 <cait> it's similar for 'can i see the books of my guarantees'
19:42:23 <cait> this can also not be changed by staff, only by patrons themselve
19:42:23 <cait> s
19:42:50 <cait> the checkouts i mean
19:43:11 <greenjimll> Not something that affects us at the University, but who gets to set the flag for minors?
19:43:15 <m23_kohaCZ> and whats about borrowet that dont use their OPAC
19:44:04 <cait> i think you can argument both ways
19:44:06 <m23_kohaCZ> staff shold have change this at staff client
19:44:08 <cait> just maybe has to be an option :)
19:44:11 <cait> like lots of things
19:44:26 <josef_moravec> #action josef_moravec added notes to wiki page and will fill a bug
19:44:38 <josef_moravec> yes, more options, more Koha ;)
19:44:47 <m23_kohaCZ> yeah
19:44:50 <magnuse> +1
19:44:56 <m23_kohaCZ> Koha is very flexibile
19:45:07 <josef_moravec> moving on
19:45:28 <josef_moravec> #topic Wiki page record 4
19:46:01 <josef_moravec> some concerns or questions here?
19:46:33 <cait> sec
19:46:52 <cait> ah, just about how to do that technically maybe?
19:47:14 <josef_moravec> i have no idea yet ;)
19:47:23 <cait> ok ;)
19:47:27 <greenjimll> Is it a role for any reporting, or just ones that touch "personal data" holding tables? The former surely?
19:47:31 <m23_kohaCZ> add new rule for staff and new option at report
19:47:48 <cait> hm
19:47:54 <josef_moravec> the on options could be a flag set by report creater? That's the easiest solution ;)
19:48:00 <cait> like have a flag on the report to suggest it contains personal information
19:48:13 <cait> and split permissions to run normal and 'personal' reports?
19:48:23 <m23_kohaCZ> yeah
19:48:26 <josef_moravec> greenjimll: yeah, the reports wii personal data
19:48:28 <cait> i think we all agree :)
19:48:36 <josef_moravec> great!
19:48:52 <greenjimll> So the report creator will need this role in order to make any reports?
19:48:56 <magnuse> yeah, it's just how to do it
19:49:00 <cait> so this would be for executing reports - probably not possible to restrict for creating?
19:49:24 <josef_moravec> yes, that's how it would work in that case
19:49:32 <greenjimll> Allowing you to (potentially) create a report you can't run?
19:50:03 <cait> greenjimll: the problem is...  how do you restrict writing reports to not contain personal inormation?
19:50:03 <janPasi_> it would be hard to limit what the report creator can access in the database
19:50:04 <magnuse> you could try and look for reports that use e.g. the borrowers table
19:50:07 <josef_moravec> yes, or bypass the permission by not to flag it
19:50:18 <cait> janPasi_: yes exactly
19:50:23 <magnuse> but not sure how safely that can be done
19:50:30 <janPasi_> you'd need two database users and then limit their permissions on the database tables
19:50:34 <cait> would also rule out reports that only group by patron category
19:50:45 <greenjimll> If you need the new role in order to create reports, doesn't that solve the issue?
19:50:57 <magnuse> cait: good point
19:51:09 <cait> the new permission would be to be able to run reports marked with a special flag
19:51:33 <greenjimll> But you could also say that to create a report you'd need to new permission too.
19:51:37 <cait> there is already separate permissions at the moment for running, creating and deleting reports
19:51:55 <cait> splitting creating into 'harmless' and 'not harmless' would be hard
19:52:17 <janPasi_> not to mention it's hard to predict what will be harmless ;)
19:52:39 <m23_kohaCZ> if somebody has rule for creating report, this person logically can make every report
19:53:10 <Joubu> you could 1. Start a transaction, 2. update borrowers set critical_fields=null; 3. execute the SELECT query 4. rollback
19:53:17 <m23_kohaCZ> its no moblem, problem is to make smaller goour of staff that can run reports that contain personal data
19:53:26 <cait> Joubu: that does sound kind of scary
19:53:41 <Joubu> why that?
19:53:50 <Joubu> it's just an idea :)
19:54:51 <greenjimll> I'm guessing #5 is going to have similar issues (hence the same bug number)?
19:55:00 <josef_moravec> greenjimll: yes
19:55:15 <cait> i think 5 would be even harder as we basically have no control on what a plugin does
19:55:31 <janPasi_> Joubu: i don't see how that would work :D
19:55:51 <janPasi_> Joubu: what is 15 other people access the borrowers table between the update and the rollback?
19:56:11 <janPasi_> Joubu: won't they get bogus information then?
19:56:40 <Joubu> heh you will need to lock the table, which can be a problem for big queries
19:56:57 <greenjimll> 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 <cait> I don't think it's a practical solution right now
19:57:10 <janPasi_> Joubu: but that will stop the whole system then, won't it?
19:57:16 <m23_kohaCZ> creator of plugin flag it l= contains personal data, just staff with rule can run it
19:57:22 <cait> greenjimll: it#s totalyl in your responsibility to check the plugins you install
19:57:32 <greenjimll> cait: exactly.
19:57:53 <cait> ideally a good plugin should include information about what data it touches, changes and maybe stores additionally
19:58:27 <magnuse> +1
19:58:27 <cait> 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 <m23_kohaCZ> maybe configuration of plugin can give control to liste staff IDs
19:58:54 <magnuse> yeah, plugins have to be out of scope, i think
19:59:00 <cait> m23_kohaCZ: you could implement that already, but it#s up tot he plugin writer
19:59:15 <cait> they are not restrictable in any way
19:59:30 <m23_kohaCZ> cait: yes
19:59:41 <cait> i think best we could do is have recommendations
19:59:53 <cait> and maybe a list of 'good' plugins thatsomeone has checked with added documentation
20:00:02 <josef_moravec> 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 <cait> 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 <m23_kohaCZ> move on #6?
20:01:18 <cait> like apps on your phone : wants  access to... - but we are not there yet
20:01:28 <cait> yep
20:01:55 <josef_moravec> skipping 5
20:02:05 <josef_moravec> #topic Wiki page record 6
20:02:26 <Joubu> 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 <cait> ü1
20:02:29 <cait> +1
20:02:57 <josef_moravec> now it is doable by server admin
20:03:32 <josef_moravec> but at least an enhancement to koha-dump would be nice
20:03:57 <m23_kohaCZ> just add new option --encrypt dump
20:03:59 <greenjimll> What encryption is used or is that configurable? Would it have export implications for some Koha sites?
20:04:25 <josef_moravec> m23_kohaCZ:
20:04:28 <josef_moravec> m23_kohaCZ: yes
20:04:41 <josef_moravec> but we need to configure a key somehow
20:04:49 <cait> greenjimll: this is just for your backups - emergency recovery
20:05:04 <cait> greenjimll: not for other types of exports
20:05:13 <cait> greenjimll: and not one way - you can unencrypt of course
20:05:16 <cait> decrypt?
20:05:39 <greenjimll> Doesn't matter what its for: its restriction on code export in Koha or use of encrypytion in some places.
20:06:32 <cait> sorry, i might not understand you
20:07:03 <m23_kohaCZ> encryption of backup is here for protecting of data in backup = I can decrypt it if I know paasword
20:07:05 <greenjimll> 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 <cait> ?
20:07:20 <Joubu> sysadmins can take care of that, right?
20:07:23 <greenjimll> https://en.wikipedia.org/wiki/Cryptography_law
20:07:39 <josef_moravec> Joubu: yes
20:07:58 <cait> greenjimll: i tihnk usually you'd use a standard encryption
20:08:40 <cait> i was told we HAVE to encrypt backups
20:09:25 <josef_moravec> 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 <greenjimll> 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 <greenjimll> Note: I am not a lawyer though. :-)
20:11:16 <cait> we don't do that
20:11:26 <cait> i think mysql toold might allready support it
20:11:40 <cait> we are not implementing our own encryption
20:11:59 <cait> sorry for all the typos tonight
20:12:04 <m23_kohaCZ> encrypt is option, if its not legal in some coutry, its admin decisition if use it
20:12:40 <greenjimll> Its not the use: its the import/export. But I'll give up now. :-)
20:12:55 <janPasi_> 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 <janPasi_> which would kind of defeat the purpose
20:13:22 <m23_kohaCZ> but for GDPR point of view its protection for privat data stored on backup drive
20:13:28 <josef_moravec> janPasi_: true
20:14:18 <josef_moravec> just for interest https://mysqldump-secure.org/
20:14:21 <cait> greenjimll: we might just be misunderstanding each other
20:14:49 <josef_moravec> moving on?
20:15:20 <m23_kohaCZ> yeah
20:15:30 <greenjimll> Yes
20:15:31 <Joubu> what's the conclusion?
20:15:38 <greenjimll> Its complicated. :-)
20:15:52 <janPasi_> good conclusion :D
20:15:53 <m23_kohaCZ> we need this option :-)
20:16:11 <Joubu> you can create a wiki page to explain people how to excrypt their dump
20:16:24 <Joubu> if it is the point, but I am sure good sysadmins will use their own workflow
20:16:27 <magnuse> sorry, i gotta run, will read the log
20:16:30 <greenjimll> Joubu: that's sounds like the best idea to me.
20:16:38 <Joubu> and will not use a possible --encrypt flag they do not know what it does
20:17:05 <Joubu> but yeah, move on, I will comment on the bug )
20:17:30 <josef_moravec> Conclusion - start with a wiki page, it is enough for now, as it is a system admin responsibility
20:17:55 <josef_moravec> #topic Wiki page record 7
20:19:55 <josef_moravec> 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 <greenjimll> Sounds reasonable - could it just be an enhancement bug?
20:20:25 <m23_kohaCZ> easy to implement it, but local use
20:20:43 <janPasi_> josef_moravec: can't it be done locally in czech koha installations?
20:21:05 <m23_kohaCZ> I vote for add it into master Koha
20:21:16 <josef_moravec> #action josef_moravec file bug for adding age to statistics table
20:21:52 <m23_kohaCZ> because no all instalation in CZ use KohaCZ package
20:22:04 <josef_moravec> janPasi_: coud be, but I think it would be useful for others too
20:22:24 <cait> we'd be interested in it too
20:22:24 <greenjimll> Might be of use in other countries too (I'm thinking public libraries more than Universities)
20:22:35 <cait> i know that another system is also using this approach
20:22:36 <m23_kohaCZ> I agree with Josef
20:22:48 <cait> the age is not important for the academics so much, but for the public libraries
20:22:56 <Joubu> maybe I am completely out of context here but we could keep the date of birth on anonymizing a record
20:22:58 <cait> filling the column could be optional
20:23:07 <cait> Joubu: it's a sensitive data
20:23:09 <Joubu> if it is not linked with other info
20:23:18 <cait> too eay to figure out who it was
20:23:20 <Joubu> yes but you do not know who
20:23:41 <Joubu> ok
20:24:36 <josef_moravec> 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 <janPasi_> josef_moravec: it will probably be easy to guess that from plain age too, we have such villages also ;)
20:25:46 <josef_moravec> janPasi_: maybe ;)
20:25:46 <Joubu> :)
20:26:16 <greenjimll> File a bug/enhancement then?
20:26:21 <josef_moravec> 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 <josef_moravec> #action josef_moravec fill a bug
20:26:57 <m23_kohaCZ> move on?
20:27:11 <cait> josef_moravec: make it optional like storing the last user?
20:27:24 <josef_moravec> cait: yes
20:27:55 <cait> move on?
20:27:59 <josef_moravec> #topic Wiki page record 8
20:28:53 <josef_moravec> Logging of koha-* scripts, we now log just perl cronjobs
20:29:16 <josef_moravec> I have no idea how to do it yet ;)
20:29:56 <Joubu> rewrite koha-* scripts in perl, it will be easy then ;)
20:30:41 <josef_moravec> Are make a REST API endpoint?
20:30:51 <josef_moravec> s/Are/Or/
20:32:46 <janPasi_> you mean log running them in the database?
20:32:47 <Joubu> You can write a misc script in perl you will call from the koha-* scripts
20:33:10 <janPasi_> that shouldn't be too hard with *sh either
20:33:25 <josef_moravec> Joubu: it does make sense, and will be easy
20:33:54 <Joubu> janPasi_: nope, but certainly easier in perl, and could be reuse
20:34:55 <josef_moravec> 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 <josef_moravec> moving on?
20:35:33 <Radius_CZ> what info do we need to log concernign backups?
20:36:04 <josef_moravec> Radius_CZ: Just like other cronjobs, just the information it was run
20:36:16 <Radius_CZ> ok then
20:36:30 <josef_moravec> But if you wan't to enhance it, you could make  a patch ;)
20:36:55 <josef_moravec> moving on
20:37:33 <josef_moravec> #topic Wiki page record 9
20:37:48 <josef_moravec> staff client access restrictin
20:38:14 <josef_moravec> again maybe more for sysadmins
20:38:38 <greenjimll> Should 2FA be handled through the web server or similar services (eg single sign on IdPs)?
20:38:40 <cait> we have used client certificates + apache configuration for one customer - but it's no easy to maintain
20:39:17 <cait> 2f is combination of knowledge and possession, correct?
20:39:22 <m23_kohaCZ> Cait: can you publish some tips on wiki?
20:39:37 <cait> not sure, we are trying to get rid of it actually
20:39:54 <josef_moravec> you could combine 2fa and ip restriction
20:39:57 <greenjimll> 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 <cait> and I think it might have problems with plack - but not sure
20:40:27 <cait> single sign on might not qualify then -it's just pw
20:41:22 <m23_kohaCZ> whats about some IP whitelist?
20:41:33 <cait> i think improving autolocation could be a start
20:41:36 <greenjimll> Single sign on can use 2FA - we've linked our development IdP to a test privacyIDEA server (https://www.privacyidea.org/)
20:41:42 <cait> i know a lot of kohas are still publicly available
20:41:50 <josef_moravec> cait: good idea
20:42:19 <cait> greenjimll: interesting
20:42:33 <greenjimll> cait: Works with UbiKeys as well. :-)
20:42:44 <Radius_CZ> 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 <cait> some smaller libraries don't have static ips
20:43:27 <Radius_CZ> that's right
20:43:31 <josef_moravec> I think we need also to somehow restrict the database user, when it is not needed after installation
20:43:44 <cait> so having another option as well would be good
20:44:01 <josef_moravec> so definitely some 2fa needed?
20:44:05 <m23_kohaCZ> privacyIDEA is cool
20:44:42 <josef_moravec> hm, looks really interesting
20:44:50 <m23_kohaCZ> 2fa is very useful aditional security option
20:44:57 <Radius_CZ> +1 for 2FA
20:45:17 <cait> i noticed  koha has AllowPKIAuth - someone used this?
20:45:21 <m23_kohaCZ> we've some bug about 2fa
20:45:52 <cait> client certificates could be good, but maybe koha supporting them not via apache only
20:46:15 <josef_moravec> https://screenshots.firefox.com/7IYEz32V51HxxHEK/hea.koha-community.org
20:47:13 <cait> hm that's not too bad
20:48:17 <josef_moravec> at least more then nothing ;)
20:48:27 <cait> :)
20:49:01 <m23_kohaCZ> is it useful on shared staff pCs?
20:49:03 <cait> i thnk we need to gather some more ideas, maybe on the bug?
20:49:25 <m23_kohaCZ> I agree with Cait
20:49:52 <josef_moravec> bug 19886
20:49:52 <huginn> 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 <josef_moravec> bug 19887
20:49:56 <huginn> 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 <cait> m23_kohaCZ: we used one for all i think... but that's not ideal
20:50:59 <josef_moravec> #action more investigatin of 2FA needed, we will collect information on bug reports
20:51:15 <m23_kohaCZ> agree
20:51:51 <josef_moravec> #topic Wiki page report 10
20:52:57 <cait> i don't think it will be useful for anyone... but we have been asked about it already
20:53:12 <cait> a way to export all your data from somewher ein the patron account?
20:53:24 <janPasi_> rest api endpoint?
20:53:25 <cait> if you take this serious, there is a lot of tables involved
20:53:27 <josef_moravec> cait: it is not very useful but needed by GDPR as  I think
20:53:34 <m23_kohaCZ> #10 cna be like new button on patron detail or some plugin
20:53:35 <cait> agreed
20:53:45 <cait> the problem is mkaing sure you include all data
20:53:56 <cait> ratings, reviews, checkouts, comments, address changes...
20:54:12 <cait> if you take it serious, it's a lot of tables to be checked for the patron number
20:54:17 <m23_kohaCZ> holds, payments....
20:54:24 <josef_moravec> 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 <greenjimll> loans that have been anonymised... oh, er, no. :-)
20:54:36 <josef_moravec> greenjimll: ;)
20:54:57 <Radius_CZ> I would vote for a plugin ;-)
20:55:02 <josef_moravec> and should be machine readable so JSON or CSV
20:55:29 <greenjimll> JSON would be more extensible in the future.
20:55:35 <josef_moravec> greenjimll: agree
20:55:48 <josef_moravec> it is more flexible
20:55:49 <Radius_CZ> yes, plugin with JSON export to a file
20:55:58 <m23_kohaCZ> so, mlutilanguague GDPR plugin?
20:56:19 <greenjimll> Koha Take Out(tm).
20:56:32 <janPasi_> why not provide the patron him/herself with access to her/his data directly via rest?
20:56:34 <cait> josno nice way to integrate plugins into the opac right now
20:56:42 <cait> we should avoid a solution that requires local changes
20:56:48 <cait> and also plugins are not translatable
20:56:51 <cait> which is a major flaw
20:57:18 <janPasi_> vomit out "everything" as json via rest-endpoint?
20:57:37 <cait> janPasi: I think you need a 'button'
20:57:38 <greenjimll> A REST endpoint would seem ideal. We provide the service but don't clutter the UI for 99.9% of users that won't need it.
20:57:57 <cait> if we have the endpoint, a button with a prf is easy?
20:58:02 <cait> not a lot of code clutter
20:58:15 <josef_moravec> I woud base it on REST API, you can reuse it in staff client, opac, standalone access... and does generate JSON, we just will probably need to filter out some data - like database ids
20:58:16 <janPasi_> button can simply access that endpoint then
20:58:18 <cait> but json doesn't give you a file, so a bit of code is needed
20:58:45 <cait> i haven't checked if there are requirement sin the law besides machine-readable
20:58:48 <m23_kohaCZ> API poitn will be great, beuase it can be used in other systems like VuFind for example
20:58:58 <janPasi_> cait: it gives you json output on the browser though, just save it and you have a file
20:58:58 <josef_moravec> just a bit to set a mime type and so
20:59:25 <cait> janPasi_: i am all for it - just thnk we need to make sure it's easy enough to make us comply
20:59:38 <cait> and we have the goethe institute now... i like buttons in templates that can be translated
20:59:41 <m23_kohaCZ> Cait: GDPR talk abotu machine format
21:00:14 <cait> m23_kohaCZ: true, but still might have to provide an easy enough way to get it
21:00:26 <cait> something obvious
21:00:31 <greenjimll> https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-data-portability/
21:01:01 <greenjimll> CSV explicitly mentioned there (ICO is the UK Gov's body that is handling GDPR)
21:01:57 <m23_kohaCZ> GDPR dont specify format, but CSV, XML or JSON will be great
21:02:32 <greenjimll> "You must provide the personal data in a structured, commonly used and machine readable form." I'd say JSON is pretty commonly used.
21:02:44 <cait> agreed
21:02:51 <m23_kohaCZ> agreed
21:03:31 <Radius_CZ> JSON or XML, CSV does not offer as good structure as those two
21:03:38 <greenjimll> First, data controllers should offer a direct download opportunity for the data subject and,
21:03:38 <greenjimll> second, they should allow data subjects to directly transmit the data to another data controller.
21:03:38 <greenjimll> This could for example be implemented by making available an Application Programming
21:03:38 <greenjimll> Interface.
21:03:50 <greenjimll> (that's from: http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_annex_en_40854.pdf)
21:04:07 <greenjimll> So looks like RESTful API with JSON will do that.
21:05:10 <m23_kohaCZ> ok, Josef?
21:05:25 <josef_moravec> ok, moving on
21:05:27 <josef_moravec> #action josef_moravec will add a short comment to bug report 20028 about this
21:06:04 <josef_moravec> #topic Wiki page record 11 and 12
21:07:02 <greenjimll> Ah, the annoying cookie banners that nearly everyone just ignores or clicks through. :-)
21:07:23 <josef_moravec> I think we need a short notice about cookies and personal data management with link to page with documentation about using personal data.
21:07:35 <josef_moravec> greenjimll: exactly! ;)
21:07:46 <janPasi_> we've just added a bit of javascript to opacuserjs
21:07:48 <josef_moravec> m23_kohaCZ?
21:07:51 <cait> I've started to document our cookies: https://wiki.koha-community.org/wiki/Use_of_Cookies
21:07:52 <janPasi_> that works
21:07:56 <cait> it's turning into something horrible
21:08:14 <cait> i think you might need opt-in
21:08:18 <cait> not just inform them
21:08:28 <janPasi_> which will soon be abandoned as we have a new opac based on vufind
21:08:45 <josef_moravec> jso the discussion here is - do we need something to develop in koha? Or is wiki page ok and we leave it on libraries?
21:09:03 <greenjimll> Good point - we use VuFind with Koha rather than the OPAC UI.
21:09:14 <josef_moravec> we too ;)
21:10:08 <m23_kohaCZ> wiki page is very useful, but with some JS for presentation for patron in OAPC will be great
21:11:05 <josef_moravec> libraries shoud probably have a page on website with this documentation, so thay can link here
21:11:33 <greenjimll> Lots of Koha cookies are exempt cookies anyway (session id, language, etc).
21:11:34 <m23_kohaCZ> anf if we store some cookies, we should provede some easy tool (link) for delete this from patron computer
21:12:10 <josef_moravec> m23_kohaCZ: with an warning that something will not work then, right?
21:12:18 <greenjimll> See section on exempt cookies: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
21:12:23 <Radius_CZ> josef_moravec: I like the idea of linking library website with a cookies wiki page
21:13:24 <cait> we use the Koha OPAC
21:13:33 <cait> and i think soemthing in Koha is better
21:13:42 <cait> a lot of libraries are affected by this and again: translations
21:14:10 <greenjimll> Which of the OPAC cookies are non-exempt though?
21:14:19 <cait> non-exempt?
21:14:27 <josef_moravec> cait: I agree, if we can solve it for "everyone" at once, it is more effective way to do it
21:14:33 <greenjimll> cait: see http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm]
21:15:09 <greenjimll> cait: specifically the bit on "Cookies clearly exempt from consent according to the EU advisory body on data protection- WP29 include:"
21:15:32 <cait> thx for the links btw
21:15:38 <greenjimll> cait: many of the OPAC cookies fall into those categories it seems to me.
21:15:44 <cait> greenjimll: i just started documenting them
21:15:57 <cait> i have not identified all yet - it's hard
21:16:08 <cait> hm link is not working from above
21:16:29 <greenjimll> Oops - slipped a ] at the end. Try: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
21:16:46 <cait> i think session cookies are safe
21:16:51 <cait> more worried about the extra features
21:17:26 <cait> i have not identified yet what form_serialized does
21:17:33 <cait> i think it#s going back to your last opac search maybe
21:17:37 <cait> and bib_list...?
21:18:08 <cait> of course the best is if we can stick to cookies that don't require us to ask permission
21:18:56 <Joubu> bib_list is the list of bibnumber in the basket/cart
21:19:29 <Joubu> form_serialized is the elements you filled in the adv search
21:19:45 <greenjimll> So is 11 and 12 under way anyway then (he says looking at his watch and feeling his tummy rumbling. :-) )
21:19:53 <cait> heh
21:19:57 <cait> it's 10pm here... :)
21:20:07 <cait> so i see what you mean
21:20:13 <cait> yes let's move on
21:20:18 <greenjimll> 21:20 and I've not had my tea yet. :-)
21:22:21 <cait> t
21:22:22 <m23_kohaCZ> #13?
21:22:49 <cait> #topic Wiki page record 13
21:23:26 <cait> is this about generating the content for hte page or just a way to have a page in the OPAC?
21:23:59 <cait> ok, should be tied in with self registration
21:23:59 <m23_kohaCZ> Cait propably just some content in OPAC
21:24:07 <janPasi_> isn't that sort of responsibility of libraries?
21:24:13 <cait> and maybe an option to document signature from staff client?
21:24:22 <greenjimll> I would assume that the content is something that each organisation will need to create or at least customise?
21:24:32 <cait> yep i'd say so
21:24:39 <m23_kohaCZ> agrred
21:24:43 <cait> so an optional step in the workflow with the option to add custom text and log
21:25:08 <greenjimll> And in the case of our users, its something they sign up to when they join the Uni, so no need for a separate sign up when they start to use the library.
21:25:37 <greenjimll> Yes to optional step.
21:25:45 <josef_moravec> But for self-registration and public libraries, it could be very useful
21:25:48 <Radius_CZ> This should be printed as a letter, I think. Similarly to patron's issue list. At least during administrative registration process.
21:26:42 <m23_kohaCZ> <Radius_CZ: But it should be electronical too, like for self-registration
21:27:18 <josef_moravec> but new letter system use template toolkit so could be printed or presented as web page I think
21:27:22 <cait> you could add something to the patron account
21:27:27 <cait> when they first log in to have them accept
21:27:41 <cait> not sure what works best legally
21:28:24 <cait> we have a patron attribute in one of hte libraries 'signed registration form?' - maybe something like this for the manual option
21:29:18 <josef_moravec> good idea cait
21:30:18 <josef_moravec> anybody something to add, to can we move on?
21:30:34 <m23_kohaCZ> move on
21:30:38 <cait> yep
21:30:52 <josef_moravec> #topic wiki page record 14
21:31:19 <greenjimll> Some (hopefully relevant) info: https://www.ctrl.blog/entry/gdpr-web-server-logs
21:32:14 <m23_kohaCZ> thx for link, interesting
21:33:14 <greenjimll> Though I should point out that that blog doesn't have a cookie warning and does have third party tracking cookies. :-)
21:33:26 <cait> heh
21:33:27 <janPasi_> does apache have any kind of ip-masking options for the logs?
21:33:45 <cait> ip-masking?
21:34:02 <eythian> @later tell wizzyrea https://www.reddit.com/r/newzealand/comments/80a77o/aucklands_worldbeating_library_fines/
21:34:02 <huginn> eythian: The operation succeeded.
21:34:03 <janPasi_> yep, i mean is it possible to hide ip-addresses and such from apache logs
21:34:13 <greenjimll> Yes: https://stackoverflow.com/questions/19452624/apply-a-mask-to-ip-with-logformat
21:34:30 <janPasi_> ok, thanks greenjimll :)
21:34:40 <greenjimll> Thank Mr Google. :-)
21:35:14 <cait> thx!
21:35:27 <janPasi_> follow up question would be, should this be the default? ;D
21:35:46 <cait> i think it might be ok to keep logs short term for it security reasons
21:35:53 <cait> but on need to keep them longer than strictly necessary?
21:36:05 <cait> like identify a possible attack
21:36:17 <janPasi_> yep
21:36:19 <josef_moravec> so then it is necessary ;)
21:37:04 <cait> maybe a sysadmin thing again that needs some docs and recommendations on the wiki?
21:37:08 <m23_kohaCZ> we should declare reason and time frame, and delete logs after
21:37:10 <janPasi_> but if the ip addresses are masked, it may make it to identify the attacks
21:37:47 <janPasi_> *may make it difficult
21:37:58 * eythian wonders about a logrotate config that masks the IP addresses after say a week
21:38:14 <janPasi_> eythian: do you think that could be done with logrotate?
21:38:24 <josef_moravec> eythian: it would be ideal ;)
21:38:35 <eythian> Not an expert, but probably
21:38:36 <janPasi_> that would be perfect
21:38:50 <josef_moravec> maybe some postrotate script?
21:38:58 <eythian> Exactly what I was thinking
21:39:31 <josef_moravec> eythian: would you mind to investigate it more? ;)
21:39:53 <janPasi_> you can't really compress the logs on rotate then
21:40:03 <eythian> I doubt I'll get the chance. Not really doing Koha stuff atm
21:40:10 <josef_moravec> ok
21:40:16 <janPasi_> or you'd have to have the postrotate first decompress, then rewrite and then compress them again
21:40:27 <eythian> janPasi: compress them after the mask time, or decompress/recompress
21:40:27 <Radius_CZ> https://serverfault.com/questions/358398/how-do-i-remove-ip-addresses-from-log-files
21:40:27 <Radius_CZ> Citation: I don't think logrotate will do it; you may need to look at creating a script that will decompress the files, process them through awk or sed to strip the IP's out, then recompress them. Just can't do it on "active" log files.
21:40:56 <eythian> Yeah, but a script log rotate calls can do it
21:41:00 <janPasi_> i'm working with logrotate at them moment for our koha, so i can look into that a bit
21:41:10 <janPasi_> *at the moment (damned)
21:41:33 * eythian resumes lurking
21:42:00 <greenjimll> Don't forget its not just IPv4 addresses that will need masking but IPv6 ones too.
21:42:01 <josef_moravec> #action janPasi_ will investigate how to remove/mask IP from older log when logrotate
21:42:31 <josef_moravec> something more to this topic?
21:42:42 <Radius_CZ> yes, will this be implemented ina cronjob?
21:43:08 <janPasi_> Radius_CZ: well, technically logrotate works with cron, so yes
21:43:13 <josef_moravec> Radius_CZ: why cronjob, if you have logrotate?
21:43:36 <josef_moravec> yes, logrotate is ran by cron ;)
21:43:45 <Radius_CZ> well, I meant we need some kind of documentation at least or will it be a default setup?
21:44:41 <janPasi_> Radius_CZ: basically you just link or copy the logrotate script under /etc/logrotate.d, so not that difficult
21:45:14 <janPasi_> Radius_CZ: it will be picked up by the logrotate the next time it gets run (from cron.daily typically)
21:45:26 <greenjimll> Some more handy Apache GDPR log config ideas: https://www.helpnetsecurity.com/2017/08/28/integrating-gdpr/
21:45:35 <Radius_CZ> I understand it, but I see s problem for "common" Koha admin who needs to know ho to comply with GDPR
21:46:38 * eythian would have a set of privacy sysprefs that control this stuff plus some documentation.
21:46:46 <greenjimll> Rightio... I've got to go: bye everyone!
21:46:58 <Radius_CZ> bye :)
21:47:01 <cait> enjoyyour tea :)
21:47:04 <m23_kohaCZ> bey
21:47:08 <josef_moravec> eythian: that's the plan
21:47:08 <m23_kohaCZ> bye
21:47:14 <josef_moravec> I think
21:47:17 <josef_moravec> ;)
21:47:23 <josef_moravec> moving on
21:47:32 <josef_moravec> #topic General discussion, questions, and answers about General Data Protection Regulation (GDPR) and Koha
21:47:52 <josef_moravec> Anybody anything? Or are we too exhausted after this meeting?
21:48:00 <cait> exhausted :)
21:48:06 <m23_kohaCZ> exhausted too
21:48:08 <josef_moravec> cait++
21:48:09 <Radius_CZ> it's late enough ;-)
21:48:20 <josef_moravec> agree, I am sleepy
21:48:21 <josef_moravec> so
21:48:22 <m23_kohaCZ> GDPR marathon
21:48:29 <josef_moravec> #endmeeting