Note: I’m writing this post on my personal blog as I’m still learning about GDPR. This is me thinking out loud, rather than making official Moodle pronouncements.
I have to admit to EU directive fatigue when it comes to technology (remember the ‘cookie law‘?) so when I heard about the General Data Protect Regulation (GDPR), I didn’t give it the attention it deserved.
The GDPR is actually pretty awesome, and exactly the kind of thing we need in this technologically-mediated world. It has wide-ranging impact, even beyond Europe. In fact, it’s likely to set the standard for the processing of user information, privacy, and security from May 2018 onwards.
So, on the advice of Gavin Henrick, I’m in the midst of Futurelearn’s course on Understanding the General Data Protection Regulation. The content is great but, unlike Mary Cooch‘s excellent videos for the Learn Moodle Basics 3.4 course (which I’m also doing at the moment) I don’t find the videos helpful. They don’t add anything, so it’s a more efficient use of my time to read the transcripts.
All of this is prologue to say that GDPR affects the work I’m leading at the moment with Project MoodleNet. It may be in its early stages, but privacy by design (PDF) means that we need to anticipate potential issues:
The Privacy by Design approach is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events before they happen. PbD does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred − it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.
Project MoodleNet is a social network for educators focused on professional development and the sharing of open content. As such, it’s a prime example of where GDPR can protect and empower users.
Article 5(1) from the official document states:
Personal data shall be:
(a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
(b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);
(c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);
(d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);
(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);
(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
We’re kicking off Project MoodleNet by looking at all of the different components we’ll be building, and really zeroing-in on user control. A key part of that is the way(s) in which users can authenticate and are authorised to access different parts of the system. We’re exploring open source approaches such as gluu (which has been GDPR-ready since November) that make it both easy for the user while protecting their privacy.
In addition, and as I’ve touched on while writing at the project blog, we’re going to need to ensure that users can, at the very least:
- see what data is held on them
- choose whether to revoke consent around storage and processing of that data
- request a data export
- ask for any of their personal data to be securely destroyed.
I actually think Google do a pretty good job with most of this with Download your data in your account settings (formerly ‘Google Takeout’).
One challenge, I think, is going to be global search functionality. To make searching across people, resources, and news reasonably fast, there’s going to be some pre-caching involved. We need to explore to what extent that’s compatible with purpose limitation, data minimisation, and storage limitation. It may be that, as with the authentication/authorisation example above, it may already be somewhat of a solved problem.
A related issue is that different functionality may be used to a greater or lesser extent by users. Some (e.g. crowdfunding) may not be used by some educators at all. As such, we need to ensure that, perhaps through an approach that leans on microservices and APIs, we ensure integrity and confidentiality of user data, while again adhering to the principle of data minimisation.
I’m delighted to be working on this project at such an exciting time for user control and privacy. Organisations that have been wilfully neglecting controls and safeguards around user data, or monetising it in unethical ways, are going to be in for a rough ride. Those, however, that have a commitment to openness and follow the principles of privacy by design are going to find that it’s a competitive advantage!