For the online learning world

Elearning WorldSecurityTechnical

Collapsed Topics and the EU General Data Protection Regulation


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.

Therefore CT has on the user’s browser a stored sequence of ‘0”s and ‘1’s or combination thereof that represent the state of the toggles. When a user clicks on a toggle, the stored sequence is compressed from the ‘0’s and ‘1’s to the text ‘value’ mentioned. That is then transmitted using the Moodle Preference API mechanism as a HTTP GET request to the server for it to store the text in the database. A Moodle ‘session key’ (docs.moodle.org/dev/Security:Cross-site_request_forgery) is used to ensure that the request to change the data is valid. When the course page is refreshed or loaded the ‘text’ value is fetched from the database (or default if there is one, which there are settings to determine for ‘all open’ or ‘all closed’) and sent to the user’s browser where JavaScript decompresses it into the stored sequence. The generation of the course page also decompresses the ‘text’ value and creates the HTML markup accordingly at the server end.

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.

And finally….

I hope this helps, makes you think about your other plugins and what questions you should ask the developer(s).

Gareth Barnard
Latest posts by Gareth Barnard (see all)

Gareth Barnard

Gareth is a developer of numerous Moodle Themes including Essential (the most popular Moodle Theme ever), Foundation, and other plugins such as course formats, including Collapsed Topics.

4 thoughts on “Collapsed Topics and the EU General Data Protection Regulation

  • This article is very nice as well as informative. With GDPR, users will have control over their personal data. Under the law, users have a set of new rights, and these rights will impact all Moodle plugins. I want to thank you for this informative article.

  • Pingback: Privacy - ElearningWorld.org

  • Beautiful post! this is only the tip of the tip of someone looking from a distance at an iceberg 🙁

  • What a great post Gareth ! GDPR is a very important piece of legislation, not just affecting Moodle of course. But for Moodle it does have many implications, and I know HQ have done a lot of work already. But you are so right, that plugins also need to take GDPR into account now – and that is maybe not the priority for many developers. And what about developers from outside the EU? It’s an interesting time ahead in this area, and even legal people do not agree 100% on what is required when it comes to applying in the real world interpretations of what GDPR attempts to achieve. I’m sure this will be the hot topic for the whole of 2018 in the Moodle world – and many areas of the world in adopt a similar model or follow the EU best=practice.


Add a reply or comment...