Implement Purpose and Retention meta-meta-data to comply with GDPR

[emdalton]

Moodle is creating a data registry to comply with GDPR by recording a purpose and retention limit for data collected. I think it would be advisable to ensure that this feature complies: https://tracker.moodle.org/browse/MDL-61486

I realize that GDPR is most concerned with data about individuals, not other contexts, but I could see metadata about groups or cohorts falling into this category, and even courses effectively say something about users (both students and teachers).

[mchurchward]

Can you confirm that this request corresponds to implementing the Privacy API - https://docs.moodle.org/dev/Privacy_API ? If it doesn't, then is this something else all plugins will need to implement?
At this point, the only data I would think is relevant is the data stored in the user context.
Thoughts?

[emdalton]

Yes, privacy api. An instructor can request that content they entered into a course be deleted, for example. All plugins will need to address this, though a plugin that stores no data just needs to document that fact.

[mchurchward]

An instructor can request that content they entered into a course be deleted

But, I'm not sure that should include meta data. For example, a course could have metadata such as "number of credits", or "subject matter". Just because a teacher entered that, surely it should not be removed?

[emdalton]

The trouble is, we don’t know what is going to be implemented as metadata or who will be entering it. So it has to be possible for it to inherit category and purpose from the context it is attached to, and have a way to be included in data requests and archive expiration. An institution can declare courses exempt from deletion, in which case metadata on a course should inherit that exemption, but otherwise the course content has to support a retention date, like everything else. Fortunately, this is all set at the context level, so it doesn’t have to be coded per individual field, at least not yet.

As for a use case, imagine an adjunct faculty member creates their first course, and it’s not that great. In particular, let's say they did a poor job estimating time required for each assignment in an activity metadata field, and maybe they also had pasted a course objective list from a different institution by accident. Later they want to be hired for a tenure track position, and they want that old course removed from their history. Whether the institution allows this depends on local policies and regulations, but I suspect in much of the EU that would fall under "right to be forgotten."

But even if every institution using Moodle decides that courses can’t be deleted, the instructor may still have a right to request a copy of the course content as data they entered into the system. There might be a dispute over whether the instructor has met contractual obligations by entering all the course materials on time. The instructor has a right to request a download of their course content, including any metadata they entered about the course.

It’s best to simply ensure that all data stored in a site supports the privacy API.

[mchurchward]

So, does core work that way now? If there are several teachers in a course and one of those teachers changes the course description. If that same teacher then "asks to be forgotten", is the course description erased? I cannot find it listed in the data privacy plugin registry, so I'm pretty sure its not. Course metadata is the same idea.
I believe the same holds true for data associated with activities. Surely a teacher asking to be forgotten who had input on an activity, cannot force all of the activity's information to be erased.

the instructor may still have a right to request a copy of the course content as data they entered into the system

That's a valid point, so I probably need to implement an "export" for all of the metadata contexts.

It’s best to simply ensure that all data stored in a site supports the privacy API.

Yes, but that can include implementing the "null_provider", indicating no personal data is recorded.

[emdalton]

Good questions. I will check and get back to you.

[mchurchward]

I have a release for the user context here - 475b96d

[emdalton]

Still checking on how to handle when a person requests that their content be forgotten but there is potentially more than one editor of the content. I do see that teachers can request that questions be deleted, for example. But you need to be able to delete the content at the end of the retention period, anyway.

[mchurchward]

I think it goes further than if there's more than one editor. I'm surprised that teachers can request that questions be deleted. What if the course is still in progress and students have answered? That would be deleting their work.
Deleting the content at the end of the retention period is a good point. Modules could have metadata which would have to be deleted. Interesting because I don't think that's covered now even if a module is deleted the normal way. Probably need to implement some event hooks.

[emdalton]

Evidently if there is more than one editor, it is more usual to remove the user's attachment to the data, e.g. anonymize the requesting teacher's name. Perhaps that is also what is done with questions. But there are issues whenever one person is able to request their data to be deleted from a shared system. Suppose a student drops a course and wants their forum posts deleted while the course is still in progress? Other students will be affected. What if the user was part of a group and there was a group assignment, or they participated in Workshop and provided grades and comments to another student?

Sometimes the response will not be to delete content the user created, but to remove that user's connection with the content. But sometimes this is not sufficient-- forum posts are quite likely to have personally identifying information in them. I think this is an untested area of law. If I were handling such a request, absent specific legal advice, I would need to look at the situation and perhaps respond according to the individual circumstances. I suppose case law will progress over time and then we'll refine our tools as needed. Maybe everything to do with formal education will end up being called an "exemption," though I think that would be too simplistic.

I think it's more of a priority to focus on end-of-retention and request-copy situations right now... but that should provide all the pieces that would be needed to respond to a data-deletion request anyway.

[mchurchward]

Okay. Given that, it should not be a problem. The plugin doesn't record who adds the data to the context. So there is no way to know if a given used was involved in assigning a specific piece of metadata to a course (for example). So, I probably only need to worry about the export part.

[emdalton]

Don't forget, the whole context the metadata is attached to has a retention date, so you still need to be able to follow deletion rules when that happens. :)

[mchurchward]

At the moment, I'm not sure how the Privacy API informs me of context deletions other than users. See - https://moodle.org/mod/forum/discuss.php?d=372700

[emdalton]

Fair enough. Hopefully the answers will be forthcoming....