MoodleNet/1.0/DPIA
Data Protection Impact Assessment
Current version: 0.1 (June 2019)
According to the UK's Information Commissioner's Office (ICO) a Data Protection Impact Assessment (DPIA) is "a process to help you identify and minimise the data protection risks of a project". Under the terms of the EU's General Data Protection Regulation (GDPR) is mandatory to create a DPIA "for processing that is likely to result in a high risk to individuals". However, it is also "good practice to do a DPIA for any other major project which requires the processing of personal data".
As a result, this DPIA for MoodleNet aims to:
- describe the nature, scope, context and purposes of the processing
- assess necessity, proportionality and compliance measures
- identify and assess risks to individuals
- identify any additional measures to mitigate those risks
We are
How to provide feedback on this document
(coming soon!)
Identify the need for a DPIA
MoodleNet is a social network for educators. They can engage in discussions and share resources with one another. What makes MoodleNet different is that it is a federated network, so individuals and organisations can install and set up their own ‘instance’.
Moodle HQ (Moodle Pty Ltd) will run a special instance of MoodleNet that indexes some of the data shared from the federated instances who wish to participate. There is also a class of information that is ‘private’ and isn’t accessed by Moodle HQ. The instance of MoodleNet run by Moodle HQ (the “Mothership”) will store data such as metadata about groups, resources, and public user profiles from third-party instances. This will be covered under a ‘ Terms of Service’ agreement between Moodle HQ and the entity operating the instance. Moodle HQ will also run one or more of its own instances, each of which will store personal data related to its users (such as contact details and discussions). This will be covered under a user agreement (Code of Conduct and Privacy Policy).
We believe that a DPIA is necessary because we are processing personal data at scale, including processing sensitive personal data. Moodle is committed to privacy-enhancing technology, which give its users choices about their personal data, and process that data only insofar as is necessary and proportionate for the services offered.
Further details may be found at: https://moodle.com/moodlenet
Describe the processing
MoodleNet is first and foremost a software application which allows for the creation of a federated network, as shown in the diagram below. An organisation can install a MoodleNet instance to allow their users to share resources and ideas with one another, but also potentially with the users of any other MoodleNet instance. A MoodleNet instance consists of a 'database', a ‘backend’ and ‘frontend’ which are typically deployed via Docker containers on servers hosted either on-site or in a data centre.
The main uses of MoodleNet are:
- Joining communities of users
- Curating educational resources into ‘collections’
- Engaging in discussions
Each instance of MoodleNet can be run independently, and can (optionally) connect to a service run by Moodle HQ ( which we refer to as the ‘Mothership’). This will be separate from any regular MoodleNet instances run by Moodle HQ to which end users may sign up.
The administrator of a MoodleNet instance may request a Mothership API key, subject to agreeing to Terms of Service. This does two things:
- Allows the HQ Mothership to receive public metadata from the instance (relating to communities, collections, resources, and user profiles) and store that in a search index
- Provides users of the instance the ability to search across the federated network, meaning they can discover communities, collections, users, and content from other instances.
The HQ Mothership stores a copy of the metadata from the federated instances which are connected via an API key. Search results provided to connected instances link directly to content on the originating federated instance.
Although a lot of the richness of search will come through tagging, we will also index public fields from user profiles. This is to surface the most relevant information to users.
The HQ Mothership indexes the public data provided by connected instances, making it quickly and easily searchable (using Algolia, a third party search engine service). This data includes information such as username, profile images, location, comments, and communities joined.
Even instances that are not connected to the HQ Mothership are nevertheless connected to one another thanks to the ActivityPub protocol. In fact, whether connected to the HQ Mothership or not, because of the way ActivityPub works, they are potentially connected to any other ActivityPub-enabled server (including servers running software other than MoodleNet).
MoodleNet will carefully differentiate between structured personal data fields and data that the individual contributes as part of their participation within communities. For example, users will be able to delete their account at any time. However, deleting their account will not delete any contributions they may have made to collections of resources.
To explain further, there are two main types of contributions to MoodleNet: adding resources, and adding comments. While comments are text-based and always attributed to a user, adding resources can happen in one of two ways:
- URL - the user points to a resource which is available on the open web. The metadata from the site hosting the resource is automatically pulled in by MoodleNet.
- Upload - the user uploads a resource and adds it to a collection using an open license. This is a similar process to uploading resources to Wikimedia Commons, the process for which will inform our work and which is detailed here: https://commons.wikimedia.org/wiki/Commons:Project_scope/Summary
The highest risk for users could arise if they are unaware that comments they add in discussion areas on one instance of MoodleNet are potentially viewable and storable by any application or server running the ActivityPub protocol (e.g. Mastodon, Pleroma, Osada). We will take steps to make sure this is clear to users, both through the user agreement but also through the visual and textual elements in the User Interface of the application.
Our proposed moderation flow for content or metadata on MoodleNet is outlined in the diagram below:
If a user ‘flags’ a resource, collection, comment, or profile, this is reviewed by the moderators of the relevant community. They may choose to take action, which could include removing content and/or warning a user. Ultimately, moderators may choose to ban a user from a community.
Should a community not be moderated effectively, users have the option of flagging that to the instance administrator. They can review the complaint and choose to warn the moderators, warn or ban the offending users from the instance, directly remove content, or close the community.
If an entire instance is problematic, users of other instances may complain (preferably through their instance admin) to Moodle HQ, who runs the ‘HQ Mothership’. Moodle HQ will review the complaint and, if appropriate, issue a warning to the admin of the problematic instance. Should the problem persist, or if the initial complaint was serious enough, Moodle HQ would revoke the instance’s API key and delete its copies of data from that instance from the HQ Mothership (including any search indexes stored via third-party services such as Algolia).
While this would not fully shut down the instance, it would stop being included in the search results on other MoodleNet instances. Moodle HQ does not process any of the data from federated instances without an API key, including those instances whose API key has been revoked.
