12:00:03 <cait> #startmeeting GDPR IRC meeting 9 July 2018
12:00:03 <huginn> Meeting started Mon Jul  9 12:00:03 2018 UTC.  The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:03 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:03 <huginn> The meeting name has been set to 'gdpr_irc_meeting_9_july_2018'
12:00:09 <cait> #topic Introductions
12:00:17 <cait> #info Katrin Fischer, BSZ, Germany
12:00:20 <marcelr> #info Marcel de Rooy, Rijksmuseum
12:00:24 <cait> please introduce yourself using #info!
12:00:26 <talljoy> #info Joy Nelson ByWater Solutions
12:00:28 <greenjimll> #info Jon Knight, Loughborough University
12:00:36 <cait> #link https://wiki.koha-community.org/wiki/GDPR_IRC_meeting_9_July_2018#Agenda Today's agenda
12:00:39 <m23> #info  Michal Denár, KohaCZ
12:00:46 <cc_> #info Colin Campbell, PTFS-Europe
12:01:03 <cait> giving it another minute or so
12:01:13 <anne-claire> #info Anne-Claire Bernaudin, librarian, University Rennes 1, France
12:01:54 <cait> #topic Status update on planned developments and road map
12:02:14 <cait> #link https://wiki.koha-community.org/wiki/Improve_data_protection_and_patron_privacy Road map
12:02:40 <cait> maybe first some updates then move to the questions?
12:03:01 <marcelr> bug 20819 is in needs signoff
12:03:01 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20819 enhancement, P5 - low, ---, m.de.rooy, Needs Signoff , GDPR: Add a consent field for processing personal data in account menu and self-registration
12:03:03 <cait> #info 12 - documentation about cookies used in Koha is done
12:03:34 <cait> #info there is also a cookie coding guidelines now, that says that developers have to update the documentation
12:03:44 <cait> i will update the table later
12:03:53 <cait> marcelr: do you have the number this is referring to?
12:04:11 <marcelr> i wrote it at the end of the table
12:04:33 <cait> i think it might fit with 13
12:04:33 <marcelr> but it touches a few points
12:04:51 <ashimema> #info Martin Renvoize - PTFS Europe
12:05:07 <cait> i can move it into the table later if you agree
12:05:14 <marcelr> yeah fine
12:05:43 <marcelr> it combines consent and account deletion request
12:05:47 <cait> ok, any other updates on the work underway?
12:05:49 <cait> oh that's interesting
12:05:52 <cait> because that was on my list
12:05:52 <m23> What about add some new guidelines about private data into development gudelines?
12:06:10 <cait> m23 I think that would make a good next topic
12:06:29 <m23> cait ok
12:06:50 <cait> #info bug 20819 deleing with patron self registration (consent) and patron deletion is ready for sign off
12:07:22 <marcelr> note that adding a deletion request and processing it are two things
12:07:32 <marcelr> this is the first part
12:07:38 <cait> but you can request one?
12:07:42 <marcelr> yeah
12:07:46 <cait> that's a good first step
12:07:57 <marcelr> you either give a consent or ask to delete your acoount
12:08:15 <marcelr> you cannot work without answering
12:08:30 <cait> any more updates to the table?
12:08:33 <anne-claire> In the table in the wiki page, I don't see anything about old_issues and statistics tables. They need to be anonmyized too, as old_reserves.
12:08:49 <cait> anne-claire: there are some entries
12:08:57 <anne-claire> Missed it, sorry
12:09:00 <cait> number 3
12:09:05 <marcelr> is anonimizing the borrower not enough?
12:09:06 <cait> and 7 i think
12:09:24 <cait> marcelr: at the moment we are not doing that
12:09:32 <cait> but it depends on how long you want to store data
12:09:42 <cait> there is actually no need to store issues data as logn as the patron exist
12:10:00 <marcelr> maybe statistical purposes
12:10:09 <cait> yeah, but then you can work with anonymized data too
12:10:18 <cait> the idea was to move patron category and age to the statistics table
12:10:22 <cait> to remove the need for the link with the patron
12:10:23 <anne-claire> For statistics, pseudnomymization would be a need
12:10:31 <anne-claire> To identify a single user
12:10:46 <cait> and borrowernumber could be removed after some time frame
12:10:59 <cait> ok, i will add a new topic then for coding guidelines?
12:11:05 <greenjimll> We'd need to be able to tie an old-issue down to the department that the user who made it was in for example, as part of our purchasing system.
12:11:16 <cait> where do you store department?
12:11:28 <greenjimll> In the attributes for the borrower.
12:11:33 <cait> hm
12:11:37 <talljoy> ack
12:11:57 <cait> maybe we'd need a way to map some data to statistics by configuration
12:12:13 <cait> let the library decide what we copy from the patron record
12:12:25 <anne-claire> cait: yes
12:12:30 <talljoy> have a 'free' field in statistics like sort1, sort2 ?
12:12:37 <cait> something like that
12:12:42 <cait> what do you think
12:12:43 <cait> ?
12:12:51 <talljoy> it allows for flexibility for sure
12:13:06 <cait> i can add the idea to 7 latr
12:13:15 <drojf> #info Mirko Tietgen, late
12:13:52 <cait> #topic Coding Guidelines for privacy
12:14:19 <cait> m23?
12:15:06 <m23> We mabe should inspire by https://github.com/joomla-projects/privacy-framework
12:15:55 <cait> #link https://github.com/joomla-projects/privacy-framework
12:16:22 <m23> Its integrated into core of Joomla, every new plugin, feature or code must corresponded into privacy framework.
12:16:30 <cait> #idea (from earlier) Add some columns to statistics that can be mapped to patron data by the library
12:16:56 <m23> If some law change it can be easier to implement it into system
12:17:12 <greenjimll> I like the privacy of the Joomla version history: https://docs.joomla.org/Joomla_3.9_version_history
12:17:13 <cait> can you give an example?
12:17:38 <cait> hm empty for me?
12:17:44 <talljoy> me too
12:17:48 <greenjimll> Exactly.
12:17:50 <greenjimll> :-)
12:17:52 <marcelr> private :)
12:18:14 <cait> I think i don't understand
12:18:23 <m23> if privacy data are in log, tables developrs know it and know how hadle this data
12:18:55 <m23> all provate data are mapped
12:19:32 <m23> its clear?
12:19:45 <cait> sorry, not yet
12:19:55 <cait> just hiding the information seems a bit like  Security by obscurity to me
12:20:05 <talljoy> yes
12:20:09 <cait> security through obscurity (had to look it up)
12:20:16 <talljoy> i like that phrase cait!
12:20:39 <greenjimll> Not terribly obscure if its documented though.
12:20:48 <cait> but what exactly are we not seeing?
12:20:50 <drojf> nor secure
12:20:54 <m23> we cant just hide private data, its agianst rules of GDPR
12:21:09 <m23> we must be able to remove or anonymise them
12:21:47 <marcelr> m23: do you have specific suggestions for new coding guidelines ?
12:22:32 <m23> marcelr Im not sure .... how specify it
12:22:38 <cait> hm maybe something like: don't add more data without a deletion/anonymization stretegy?
12:22:58 <cait> like if we added a message_queue again, we'd immediately also provide a script to delete the date/clean up
12:23:11 <cait> or... deal with what happens when the patron is deleted
12:23:17 <cait> we don't always do that cleanly in the codebase
12:23:36 <marcelr> cascaded deletes clean up a lot ..
12:23:39 <cait> for example the messages to patrons (the notes) are never cleaned, they remain linked to deletedborrowers
12:23:49 <cait> yep, but they are holes currently
12:23:52 <marcelr> ok
12:23:55 <m23> every new functionality, plugin thaht hande privacy data must do it clear
12:23:57 <cait> so it might be worth giving it some thought implementing new features
12:24:19 <greenjimll> And should the method for making patron data anonymous be implemented in the Koha core modules, so that new additions can make use of these rather than reinventing the wheel?
12:24:30 <m23> so first step is mapping privacy date in system/databese
12:24:36 <cait> #idea provide a way to clean up/anonymize data at the time of adding new features as well
12:25:33 <m23> private data can be at easy identify tables, but hiden at logs, messages, etc.
12:25:46 <cait> #idea clean up/anonymize data when patron is deleted for new features/tables
12:25:58 <cait> we have a list of tables that have links to patron data
12:26:03 <cait> not sure if that would be helpful?
12:26:16 <m23> cait, yes, it can help
12:26:17 <cait> there are also several cronjobs that can create logs containing patron information
12:26:30 <cait> maintaining the list is a bit... hard
12:26:31 <m23> exactly
12:26:32 <cait> but i can try to put it on my to do list
12:26:52 <cait> an automatic way of documenting this might be nicer
12:26:59 <m23> some kidn "privacy framework" can help in future
12:27:04 <cait> we have https://schema.koha-community.org for example
12:27:18 <cait> m23 i think it#s not clear from the page you linked how that works
12:27:27 <cait> the readme below is only about Joomla in general
12:27:52 <clrh> #info CLaire Hernandez, BibLibre  (bad connection)
12:28:00 <m23> Im not able now to find better info, I'll try
12:28:01 <cait> welcome clrh
12:28:02 <drojf> m23: do you work with joomla? could you give some more info on how the framework works? as cait said, the repository has no information about it
12:28:13 <drojf> in the readme at least
12:29:18 <cait> maybe we can discuss next time with some more info on the agenda?
12:29:26 <cait> i'd like to move on to the general discussion
12:29:36 <greenjimll> This may be more useful for Joomla GDPR support: https://data2.eu/en/gdpr-tips/146-joomla-gdpr-compliance
12:29:50 <cait> #link  https://data2.eu/en/gdpr-tips/146-joomla-gdpr-compliance
12:29:57 <m23> cait, OK, if I add some new better info about Joomla or similar solution, I'add link into wiki
12:30:07 <cait> thx m23
12:30:08 <drojf> link in german about joomla https://www.joomla.de/news/joomla/496-joomla-3-9-und-joomla-3-10-dsgvo
12:30:10 <cait> m23++
12:30:18 <cait> #link https://www.joomla.de/news/joomla/496-joomla-3-9-und-joomla-3-10-dsgvo (German)
12:30:21 <cait> moving on
12:30:27 <cait> #topic General discussion
12:31:22 <greenjimll> Should I carry on waiting for REST APIs for bug 20028, or put some place holder code in to extract and generate some JSON data directly?
12:31:22 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028 enhancement, P5 - low, ---, koha-bugs, NEW , Export all patron related personal data in one package
12:31:39 <cait> i think waiting for all rest apis needed might take too long
12:31:47 <cait> having something a little earlier might be good
12:31:50 <greenjimll> OK
12:31:56 <cait> what do others think?
12:32:38 <m23> This feature in API can be very useful if library use for exaplet VuFind
12:32:39 <greenjimll> I can always do a first cut without the REST APIs and replace it with them when they arrive.
12:33:42 <m23> Solution to provide personal data to download via user accout is very nice to users
12:33:44 <cait> i'd use rest api wherever possible
12:33:54 <talljoy> What data are you extracting?
12:33:56 <cait> but i think having it complete for what we need will take more than this year
12:34:04 <cait> talljoy: the rule is everything we store about a patron
12:34:07 <talljoy> demographic, fines, circ, old circ, reserves, etc...
12:34:12 <cait> has to be provided ina machine readable format
12:34:15 <talljoy> the whole kit and kaboodle eh.
12:34:16 <cait> for download
12:34:18 <greenjimll> It will have to (eventually) extract all information related to the borrower that we hold.
12:34:27 <cait> everything
12:34:30 <cait> reviews, tags, ...
12:34:31 <m23> especially, issue history, reservation history, payments history ...
12:34:39 <cait> star ratings
12:34:42 <talljoy> that would be a messy csv, or multiple csvs yes?
12:34:51 <cait> we were thinking messy json
12:34:54 <greenjimll> I was thinking more JSON than CSV to be honest.
12:34:56 <talljoy> :D
12:35:06 <ashimema> Can one not already do that using reports
12:35:11 <drojf> star ratings …
12:35:11 <greenjimll> Should we change it from CSV to JSON in the wiki?
12:35:13 <talljoy> a better messy in json.  agreed
12:35:32 <m23> "in one package" can thing more packaes but from one point
12:36:14 <cait> i think coudl also be a zip file?
12:36:20 <drojf> a zip with a lot of files is a package
12:36:23 <drojf> heh
12:36:25 <talljoy> :D
12:36:25 <cait> i think reports would be hard because lots of unions
12:36:32 <cait> not easy to provide a big one
12:36:41 <m23> zip are best for bigger files
12:36:42 <talljoy> would be an unwiedly report.
12:36:46 <cait> ashimema: do you have something developed maybe?
12:37:02 <cait> i think maybe we hsould not overthink it
12:37:07 <cait> but try to get something in place so we comply
12:37:09 <cait> and then refine
12:37:44 <greenjimll> OK, I'll make a start on extracting some data so there's something to test and build upon.
12:38:00 <cait> greenjimll++
12:38:25 <cait> I think marcelr's development might be dealing with my 'request account deletion'
12:38:28 <cait> can you confirm marcel?
12:38:58 <cait> #info see bug 20819 for requesting account deletion
12:38:58 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20819 enhancement, P5 - low, ---, m.de.rooy, Needs Signoff , GDPR: Add a consent field for processing personal data in account menu and self-registration
12:39:02 <cait> i think he said he only had half an hour
12:39:12 <cait> the other thing came up here in discussion about anonymizing automatically using the cronjobs
12:39:23 <m23> What about some extension of current anonymisation tool? Like list of anonymised patrons, because some library must be able to finf paper contract to remove them after anonymise "digital" data in Koha.
12:39:56 <cait> a new patron registerts at the library, they fill out a form and sign it, it's stored, the patron expires, the automatic deletion happens after x months... the paper remains
12:40:04 <cait> m23: using the tool that works, but what about using the cronjob?
12:40:42 <m23> Tool os betetr for this scenary insn!t it?
12:41:03 <cait> not sure, i think it's easy to forget
12:41:08 <cait> every manual process is
12:41:57 <m23> Cronjob is good, but how list names that was/waill be anonymised?
12:41:59 <cait> #info What happens to registration forms when a patron is deleted automatically (expired since...)
12:42:05 <cait> yeah exactly
12:42:15 <cait> i was hoping someone could provide a good idea :)
12:43:03 <talljoy> sounds like the cron would need to have a 'report' option that could be emailed once it runs and anonymizes patrons
12:43:16 <talljoy> report containing the list of names so the library could remove paper contract?
12:43:30 <m23> automatic way willl be better ... maybe Koha can send list by mailer, what do You think?
12:43:53 <cait> talljoy: emailing is not quite what we want... (privacy) but maybe a file that can be accessed
12:44:04 <m23> yeah
12:44:13 <talljoy> again back to manual.
12:44:16 <cait> because you'd email patron names and cardnumbers i think... as a minnum
12:44:21 <talljoy> someone has to go get the file
12:44:22 <greenjimll> The UK ICO says that you need to keep consent forms: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent/
12:44:31 <talljoy> or automate another process to grab the file and move it somewhere else
12:44:32 <cait> yep - just email is not encrypted usually or signed
12:44:36 <cait> or at least that's harder to do
12:44:46 <cait> getting a file from the server might be easier in a safe way
12:45:18 <cait> hm something to think about :)
12:45:23 <cait> someone got something else?
12:45:54 <m23> so tool can be other solutio :-)
12:46:06 <m23> wit caledar reminder :-)
12:46:28 <cait> #idea add a tool to remind of tasks regularly (like anonymizing data)
12:46:59 <m23> cait great!
12:47:06 <anne-claire> great idea, a reminder !
12:47:06 <talljoy> that's what google calendar is for.
12:47:16 <cait> talljoy: you are killing our fun :)
12:47:24 <talljoy> heh
12:47:32 <cait> maybe repariing the scheduler could already hlep
12:47:37 <m23> and extend anon toll with list of patrons to view/download
12:47:44 <talljoy> NOW there is a good idead Cait!
12:47:54 <cait> #info idea repair the scheduler!
12:47:55 <talljoy> m23 yes!
12:48:08 <cait> hm i am getting confused with infos and ideas
12:48:12 <cait> maybe time to end the meeting?
12:48:20 <m23> :-)
12:48:24 <cait> we'll have a poll about the next data again i think if noone is opposed?
12:48:32 <talljoy> add m23 idea about the tool providing a preview
12:48:52 <cait> oh yes
12:49:10 <cait> #idea Provide a review of patrons to delete or a list of patrons deleted when running the patron deletion/anonymizing tool
12:49:13 <cait> hope that made sense
12:49:23 <cait> hm review preview...
12:49:23 <cait> gah.
12:49:29 <cait> #idea review = preview
12:50:05 <cait> ending in a minute or so if nothing else comes up
12:50:36 <m23> thanks for debate :-)
12:50:45 <cait> thx all for attending!
12:50:50 <greenjimll> In bug 20819 do we store the consent form they consented to?
12:50:50 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20819 enhancement, P5 - low, ---, m.de.rooy, Needs Signoff , GDPR: Add a consent field for processing personal data in account menu and self-registration
12:51:00 <cait> i think marcelr is no longer around
12:51:03 <cait> maybe leave him a later?
12:51:09 <greenjimll> OK
12:51:10 <cait> or comment on the bug
12:51:13 <cait> might be more efficient
12:51:17 <talljoy> thanks cait!  good meeting.  til next time.
12:51:23 <cait> #endmeeting