GDPR and Privacy - What it means to be plugin developers. Urgent request for comments

Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments

by Michael Hughes -
Number of replies: 0
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

I'm not sure that there is *general* guidance on this, you can only work with specific guidance for the case in question.

We had a similar concern with one of our internal plugins where user's are asked to rate other members of their group and provide a comment. The task can be configured by the teacher so the subject and conditions the student is making a judgement on can't be known by the plugin.

The guidance we've had is that:

  1. The rating *of* a student is personal data of the student *being* rated because it is applying a judgement to them which they may ask to be aware of.
  2. The comment made is personal data of the student *doing* the rating. However if the comment contains something *about* another student then it would *also* be the personal data of the other student. 

So as a plugin developer we need to have made this consideration for the specifics of our plugin. 

This is a big problem with everything that may be considered user-generated content, the author is probably easily tracked, but the subject of the content may not be. So it's problematic to include comments held in this tool as part of an SAR, where the Access Request is *not* the rating student.

The decision we're pondering, under the right to be deleted conditions, is whether or not to apply something like Moodle's forum rules and blank the comment if the rating student makes a deletion request (subject the the category & purpose applied to the context).

There is also no tool in Moodle that would allow user-generated content to be attached (manually) to a context (e.g. attach a comment about a user to the target user's user context).

Hope this helps (or at least shares some pain!)


M