If you are interested in making your plugin compliant with GDPR and staying on the European Moodle admins’ friendly side, the latest screencast by Moodle HQ is a must-see. It guides you towards implementing the Privacy API, Moodle’s solution for a compliant process of personal data management and traceability. Plugins can use the Privacy API to route user information in a way that lets users know its specific destination and purposes, and lets Data Privacy Officers inspect them.
- Create a “Privacy Provider” for your plugin. These providers send, or “export,” the personal data and keep track (“metadata”) of when it is accessed. They also delete the data after it is no longer needed.
- Describe any data exported for plugin use, including the destination (such as other plugins or third parties) and the context, on a “granularity” that is able to single out data points in the Moodle database. Nichols suggests practices that help streamline this potentially performance-taxing operation, including “data bundling” and keeping queries to a minimum.
These two steps guarantee Privacy API implementation during plugin use. When a user requests information about data use, download, or erasure by the Moodle site, the API must be able to reach into your plugin when the request is approved by the admin. Here is where the metadata and the collected list come into play. You should include Privacy API methods within your plugin’s Privacy Providers that facilitate the tasks, which should count as step 3.
The process will make sure your plugin activity can take part of any privacy review as well as user requests, which are handled through the new visual Data Privacy interfaces. Nichols warns that even if your plugin does not store personal data, you should still create a provider declaring so, otherwise the plugin (and a site that installs it) will fail any privacy testing. The API offers a “Null Provider” for these cases.
It is worth pointing out that enabling Privacy API on your plugin fashions it as a “privacy by design” type of development. Broadly speaking, this means the default scenario protects personal data, deletes it unless it is explicitly set as needed —in a given time frame— and as soon as it no longer is in use.
In the case of “Right to be forgotten” requests, Nichols explains a few technical limitations of the Privacy API that prevent it from deleting every trace of the user, which are still compliant with GDPR. For example, if a teacher makes the demand, their dataset will not include grades or feedback they have given to students.
The Privacy API is included in Moodle 3.5. For Moodle 3.3.6 and 3.4.3 or later it can be added with the Data Privacy and Policies plugins. As it takes advantage of features from PHP 7, it does not offer backwards compatibility. A “Legacy Polyfill,” was devised to offer a partial solution for Moodle 3.3 sites in PHP 5.6. In any case the official advise is to upgrade to Moodle 3.5 to ensure compliance.
For more information, visit the following resources:
Moodle Tracker “GDPR Subject Access Request and Data Registry” Issue, MDL-61306. You might also be interested in “Create new ‘privacy’ subsystem” (MDL-61307) and “Implement core_privacy for assignment plugins” (MDL-61918).