Forums | Mahara Community
Mahara and the GDPR (new privacy regulation in the EU)
15 November 2017, 7:49 PM
A number of you, i.e. pretty much everyone in the EU, are probably antsy about learning how Mahara will deal with the stricter privacy regulation that is going into effect in the EU on 25 May 2018, the GDPR.
We are in the process of reviewing the regulation's text and interpreting it in order to figure out where we may need to make changes. Mahara is already pretty good in a number of areas as you can export your personal data, but we'll have to take a closer look at the "right to be forgotten" and in how far that applies to content created in groups and also to logs, especially the new advanced reporting features as some identify individuals specifically.
We'll have some information on the wiki within the next few weeks after an internal review to consolidate our interpretation. If you already looked into the GDPR and want to send through your thoughts, please do so (thanks to Ralf Hilgenstock) who's already done so.
We are planning on making changes for Mahara 18.04 so that this version is compatible (there might still be some things that need to be done manually when information is requests by a user). We can aim for an earlier release date in April than end of the month to give institutions that are affected a bit more time for the upgrades. You can always do test upgrades with the release candidate that will be out before the stable release in order to ascertain the effort needed for a production upgrade. We have not yet looked into what could also go into current stable releases. New features and extensive changes will only make it into 18.04.
If you'd like to discuss any of that in person, I'll be attending Mahara Hui EU in Kassel from 30 November to 2 December 2017.
15 November 2017, 10:08 PM
Thanks Kristina, It's good to know you're addressing the GDPR. I'll look forward to hearing more.
Newman University, Birmingham UK.
22 November 2017, 7:42 AM
We've compiled a list of necessary and nice-to-have changes to comply with the GDPR. Since no specific examples are given, the regulation is open to interpretation, and a bunch of the articles are still debated on what they mean in real life, there may still need to be some more changes.
We wanted to publish some initial thoughts though to get the discussion started and see if anybody wants to help speed up implementing some of the technical changes.
22 November 2017, 9:18 AM
thanks for this thoughts. Here my comments.
Non technical ...
The provider (site admin) needs a contract with institutions.
Must do technical...
- Explicit consent checkbox / Yes/No switch.
Its undefinmed what happen sif a users set checkbox later to 'no'. From my opinion the account should be blocked. Should we add a special confirmation for users younger than 16?
- It needs to be possible for anybody to delete their account, no matter whether registration is allowed on the site or not.
hmm: This is one option. It should be possible to configure it.
Users with external auth can't be deleted. There are massive interests by site owner to keep data.
Nice to have
If the deletion of forum posts and other group artefacts created by a user should be allowed (institution setting), we'd need a placeholder
There are German interpretations that collaborative content is not in the sole ownership of a specific user. So there is no need to delete it it with the users data. An other argumentation is that the right to be forgotten is for information that are published to a large public. I can not see that any portfolio system is meant here.
Log events are personal data if they can be connected with a specific user. Its common sense that IP data that are reduced to a few signs are anonymous. May be its an option to delete IP addresses in log data partially after a defined period.
I've never heared that people ask for access to log data or to export them. I think this should be implemented only if there is a real need.
Remove gender, marital status and visa as resume fields as they are not needed.
That will create conflicts in existing portfolios. Lets make them configurable only.
Did you discuss comments in export files?
23 November 2017, 7:43 AM
Thank you for your additional comments. The non-technical info is a non-exhaustive list of things that should be covered in the T&C and it's up to an institution to ensure that it covers everything that is needed.
- Good point about revocation. It should probably be possible to make the implications clear, i.e. account suspension at minimum at this stage.
- Consent for under 16 (or in other countries 13): Currently, we don't collect the date in Mahara. The idea is to make it flexible to add consent switches and thus an institution catering to under-age students could set up an additional consent box.
Account deletion: That is the polar opposite what an institution may want. The same goes for logs of course. I think we will need that option though in general as the user should have the right to be forgotten.
Deletion of group content: This is in the nice-to-have as it caters to the right to be forgotten, which mentions all user content, but is not required at the moment as we see it as it does impact the work of other people an thus an institution could argue that the GDPR does not count. Since more than the owner of the content has access to it, it would be public (not public in the sense that we use it in Mahara).
Log events: If you are strict, they would be user data as they are tied to specific user events. An institution could argue again that IP addresses for example couldn't be obscured even after a long time if they need it for reporting purposes. We are not looking into including log events into the right to be forgotten category of things to delete as they are often outside of Mahara and are also essential for institutions to provide their service to students and staff.
Removing fields: We had not looked into how best to do it without losing them for existing portfolios. A more flexible system in which user fields can be defined may be an option.
We did not discuss exported comments. They are already optional in HTML reports. Some people do want to keep them as they are integral part of the portfolio and learning journey. As you mentioned to me initially, the regulation wasn't written with learning systems in mind. Thus, a number of cases that we are stumbling upon now may not yet have an answer but need to be solved over time.
24 November 2017, 4:50 AM
On the matter of not accepting consent, or revocation of consent, I think we have to consider it much like a request for deletion much as I think we talked about for Moodle. This still presumes that consent is even applicable because it's certainly a point to be made that processing of data would be required as part of provision of learning (i.e. the 'required as part of fulfilling a contract' rather than actual consent argument)
I hadn't come across the 'right to be deleted' vs 'a large public' argument before but it's valid - and more so for Mahara than for Moodle.
The subject of collaborative content is proving very difficult for me to get any definitive answers - I'm sure we've talked about it for Moodle, but it's at least as - if not more - relevant to Mahara. Have the BfDI published any specific guidance on collaborative works or is that a broader concept in German law? (The ICO certainly haven't published anything in either direction and enquiries that I've raised on forums in general with them have been non-committal and vague to say the least.)
On the right for deletion, we have to look at receiving the request - it's up to the institution whether they choose to implement that request or not, or exactly what level of compliance they choose to go with. I see it with Mahara how I really see it with Moodle: that institutions need to have the tools to be able to implement it, and to be able to decide what the scope of deletion really is based on their requirements.
Log events - yes, IP addresses are personal data especially when connected to other data; and I think this might fall into the scope of having a defined data retention policy and the administrator advising that after a certain period of time, logs will be purged. This should of course be configurable, but could easily be tied into a general 'delete logs after x days/weeks/months' option to implement such a policy.
24 November 2017, 6:16 AM
On the subject of log deletion, we can already purge log events from the DB in an automatic fashion. :-) It would then only need to be the server logs that will need to be dealt with.
28 November 2017, 4:42 AM
Server logs aren't really Mahara's problem. From a purely technical perspective, there's absolutely no reasonable way to implement it such that Mahara can clean out different log formats in other systems (Apache, nginx etc.)
On a different level, it's a reasonable argument for a data controller to make that they need to preserve some of the system logs, e.g. for ensuring that someone doesn't have all their traces removed before going on some kind of cyber attack and not having the evidence for it. (Which on the surface feels like a catch-22 in general in this law: you aren't supposed to keep data longer than necessary but you can guarantee that there's going to be cases of being asked to provide data that was already requested to be deleted, and there's no way to know what's appropriate yet. Having a reasonable data retention policy that covers logs will be important.)
It's really good that Mahara supports the clean-up of the DB logs automatically though, very encouraging to hear!
04 December 2017, 9:14 AM
Yeah, there seem to be a few contradictory things in the regulation when looking at it from an institution's support perspective that will need to be sorted through further interpretation or clear direction from the law makers in some cases.