Firstly, I am not a lawyer, I’m a software engineer so anything I write in this post pertain to the software I create rather than a professional legal understanding.
The EU General Data Protection Regulation (GDPR) – www.eugdpr.org – comes into force on the 25th May 2018. It affects anyone who stores data about EU citizens. And it is the responsibility of the website author to ensure that the regulation is followed. I must stress that it is my understanding that you as an author are responsible for the code even if it has been developed by someone else.
From a Moodle point of view there will be tools for Moodle 3.3 upwards – moodle.com/2017/12/21/moodle-gdpr-approach-plan. But what about the plug-ins you have? How do you know what data they store, if they are covered, if they are user specific and if you could delete that data upon request? This thought got me thinking about my plug-ins and the data beyond core that they store and process. So in this post I will describe to you the extra data Collapsed Topics (CT) has, processes and why it does so. Then it is up to you to determine if it is covered by the GDPR and what steps you then must take to be complaint.
CT will by default store the state of the toggles on a per user per course basis. This can be turned off by an administrator with the setting ‘format_topcoll/defaulttogglepersistence’. It achieves this by utilising the ‘Preference API‘ to store a bit of text, the ‘value’, against the user id with a name in the ‘user_preferences’ table. The ‘name’ is ‘topcoll_toggle_’ followed by the course id. The ‘value’ represents the state of the toggles on the course for the user. This ‘state’ is ‘compressed’ and looks like a sequence of characters.
A bit of background….
When I was developing CT I realised that the toggle states are effectively binary in nature being either a zero or one. To store each toggle state as a single character of either ‘0’ or ‘1’ seemed a waste especially as computers are binary in nature. So I thought about how I could easily compress a sequence of toggle states into a form that could be stored in a database and transmitted as single byte text. So I looked at the ASCII character set and saw that I could use a range of human readable characters that would allow the compression from six toggles e.g. ‘101011’ to one character. Clearly this is not using the 7 available bits in ASCII or the 8 available in a byte but it avoids non-printing characters and should be database friendly. After a bit of development I settled on the range between ‘:’ and ‘y’. The code is efficient, only storing a ‘value’ that is as long as it needs to be to represent the number of toggles on the course. Thus multiples of six toggles to one character. This also cuts down on the ‘payload’ of the HTTP GET request (effectively a URL with additional parameters) packet that is transmitted every time a user clicks on a toggle. It has to happen this way as you never know how a user will ‘quit’ a course and I wanted CT to always be in the state that the user left the toggles.
So what does this mean in relation to the GDPR?
From a GDPR point of view the ‘personal data’ is the ‘user id’ combined with the CT courses they are using with the state of the toggles in compressed form stored as text. I cannot say how ‘personal’ this is in relation to the intent of ‘personal data’ within the context of the GDPR, however you know now what the data is, how it is stored and what it is used for. That information should provide you with the detail you need in order for you to make your own informed decision.
What if you need to delete a particular users’ data?
Currently through the user interface you can only turn off toggle persistence which prevents the data being updated. However any existing data already stored in the ‘user_preferences’ table will remain until the user is deleted. If a user is unenrolled from a course, then their preference will still remain until the user is deleted. Therefore if you get a request to remove a particular users’ data then you will need to know the user id and then remove all records pertaining to that user in the ‘user_preferences’ table relating to CT.
I hope this helps, makes you think about your other plugins and what questions you should ask the developer(s).
Latest posts by Gareth Barnard (see all)
- Refactoring – 16th December 2019
- The ‘OO’ in Moodle – 16th November 2019
- Customising H5P in Moodle using the Foundation theme – Part Two – 16th October 2019