Sending outIssue #295 of my Thought Shrapnel newsletter. This one was called ‘A wee problem…’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
Recording, editing and releasing Episode 98 of the Today In Digital Education (TIDE) podcast with my co-host Dai Barnes. We entitled this episode ‘Zoom zoom zoom’ and discussed audio recording, coding, philosophy books, the work of Nassim Nicholas Taleb, thinking about dying, big tech, and some tech tricks!
Next week I’m working at home for Moodle Monday through Wednesday. I’m then flying to Berlin to speak on digital literacies at an event organised by the Goethe Institut. I’ll be back on Friday to finish off my Moodle work.
Sending outIssue #294 of my Thought Shrapnel newsletter. This one was called ‘Snowmaggedon ❄️’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
Recording, editing and releasing Episode 97 of the Today In Digital Education (TIDE) podcast with my co-host Dai Barnes. We entitled this episode ‘Reeewind’ and discussed audio problems from last week, microcasting, snow, Youtube videos, porn, making friends, Slack competitors, voice assistants, smartphones, and more!
Rethinking the approach we should take with Project MoodleNet after all this talking, reading, and planning!
Microcasting via my Thought Shrapnel blog. You can see those I’ve recorded here. They’re short, straight-to-phone recordings on a range of subjects such as what I’m working on and stuff I’m thinking about.
I’m busy ideating, and talking to people around, Project MoodleNet. When you’re explaining something that doesn’t yet exist, you’ve got to use touchstones and metaphors, starting from where people are to help them understand where you want to go.
In these discussions I’ve been using three things to help me:
A great ‘landscape’ image from Bryan Mathers (see above)
It’s worth, I think, unpacking the third of these — if only so I’ve got a public URL to point people towards when I reference it elsewhere! It’s an imperfect metaphor, as it involves more technical understanding than we’ll require for Project MoodleNet.
Anyway, here goes…
WordPress and Moodle are similar
Free (as in freedom)
Host your own version
Have it hosted for you
How Jetpack works
Jetpack is a meta-plugin, a ‘plugin of plugins’ that adds lots of functionality to self-hosted instances of WordPress. In fact, it’s pretty much a no-brainer to activate Jetpack if you’re self-hosting. It connects your instance to your wordpress.com account, giving you:
Faster page loading (via CDN)
Detailed site stats
Where’s the value for the organisation behind WordPress?
So lots of value for users, but (you may think), what’s in it for Automattic, the organisation behind WordPress? Well…
Secure, fast WordPress sites maintain brand value
Better metrics around installation numbers
Ability to upsell to customers direct from dashboard
Why is this a good metaphor for what we’re doing?
Project MoodleNet will be a standalone social network for educators focused on professional development and open content. It can be supercharged, however, by using a similar model to what WordPress have done with Jetpack.
Imagine users logging into a institutionally-hosted Moodle instance using their Project MoodleNet credentials because the two are connected in a similar way to how Jetpack works for the WordPress ecosystem.
To be clear, I’m not proposing that Project MoodleNet offers the same services as Jetpack, I’m saying that it serves as an example where you can create value in two places and additional value by linking them together.
This would mean…
Teachers: professional social networking within their existing learning platform.
Instructional designers: faster access to curated open resources.
Sysadmins: better security and potentially reduced hosting costs.
(if you’re wondering about ‘reduced hosting costs’ it’s because we’re tentatively looking at how IPFS could be used in the wider Moodle ecosystem)
This isn’t a perfect metaphor by any means, and so I’m looking for other ways to explain what we’re trying to achieve. However, the combination of Bryan’s image, referencing Thingiverse, and explaining JetPack is helping those I’m talking with to understand the kind of thing we’re trying to build.
Sending outIssue #293 of my Thought Shrapnel newsletter. This one was called ‘Making cheese grate again’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
Jet lagged. I thought I’d beaten it with Melatonin tablets, but it came back to bite me on Tuesday — three days after I got home! I took the day off to get back into the groove.
Recording an episode of the Today in Digital Education (TIDE) podcast with my co-host, Dai Barnes. Unfortunately, the recording didn’t work properly and only Dai’s side of the conversation was captured after the two-minute mark. It’s disappointing, as we’ve only just moved to a paid account on Cast after experiencing some issues with Zencastr. Not the best present for Dai, whose birthday it was this week!
Buying a Chromebox (Asus CN62) for my office, as I’m sick of having to connect and disconnect my laptop every morning. I just want something where I can turn it on and go straight into a video conference. It’s obviously not as powerful as my laptop, but does the job.
Snowed in. I don’t think I’ve ever seen so much snow in Northumberland, where I live!. The snow was lying 22cm deep outside our house, which meant no school for three days for the children, no travel, and most shops either shut or on reduced hours. I work from home, so the only way it affected me was reducing my options for exercise and having to do some childcare.
Booking travel for upcoming events in Berlin, Glasgow, and Bristol.
Next week I’m working five days for Moodle as I took a day off this week. I’ll be digging into the Project MoodleNet milestones planning and overview document (initially for internal use) and talking to more smart people!
What follows, therefore, is about the final week — entitled ‘Responsibilities, liabilities and penalties’. I’m digging into in this area because I’m leading the MoodleNet project. However, I’m writing here instead of on the project blog as I’m still coming to grips with all that GDPR means in practice.
I like the way that the course organisers frame the final section of this course:
As individuals or natural persons, you should know that most of the activities that you daily perform, all the forms that you are asked to fill in and most of the technology that you use on a daily basis leave a trail of personal data behind. Collecting data, analysing and linking different databases create the possibility to learn very personal information about you and obtain details about your life and life of those who you care about. More than you would have ever thought. More than you even remember. To give but one example: 4 pictures of you placed on the Internet allow facial recognition programs to find you again when crossing the street. Given this situation, you need protection.
As per the title of this week’s course title, the focus is all about how GDPR will be enforced:
These enforcement mechanisms include a number of measures and instruments:
The establishment of national supervisory authorities (and the Lead Supervisory Authority in case of cross-border data transfers) and of the European Data Protection Board (Chapter 6);
Arrangements to streamline legal compliance, including codes of conduct (Article 40), data protection certifications (Article 42), binding corporate rules (Article 47) and standard (contractual) data protection clauses (Article 46);
Rights of data subjects, including the right to lodge a complaint and the right to an effective judicial remedy (Chapter VIII);
A multi-layered mechanism to protect the transfer of personal data of EU citizens outside the EU (Chapter V);
Liabilities and sanctions for violation of laws (Chapter VIII);
The role of Member States in compliance and implementation.
The EU provides a way to ensure local colour and context is respected, while enforcing a European-wide framework. The aim is to prevent safe havens for bad actors:
Each national supervisory authority is empowered to monitor any data processing activity that takes place within its territory (jurisdiction). It is also charged with the task to monitor any data processing activities that target data subjects residing in its territory, even in those situations where the activities are carried out by non-EU data controllers or processors. However, since in an online environment data does not always respect borders, the territorial jurisdiction of a national supervisory authority is not always clear cut.
As a result:
For avoiding situations in which more than one national supervisory authority are competent, the GDPR has introduced the legal concept of the lead supervisory authority or LSA.
When national supervisory authorities realise that a case brought before them has a cross-border dimension… they refer the case to the LSA which decides if it will handle the case or not within three weeks. Article 56 GDPR provides that the lead supervisory authority for cross-border processing of data will be the authority that is competent to supervise the entity engaged in data processing of individuals in different countries or, the authority competent to supervise the main establishment of the data controller or processor in case this has different establishments in several Member States.
So taking the example of the UK (where I live) there’s a national supervisory authority which is then subject to the lead supervisory authority. That, in turn, is subject to the European Data Protection Board:
To ensure the consistent application of the GDPR throughout the EU an important role will be played by the European Data Protection Board (the Board).
Even though the denomination looks new, the Board in itself is the continuation of the existing Article 29 Working Party which was established under the old Data Protection Directive 95/46/EC.
The old Article 29 Working Party was often criticised for not adequately consulting stakeholders before taking decisions. In reaction to this criticism, the Board is required to consult interested parties where appropriate. This would of course benefit data controllers or processors that might be affected by the decisions adopted.
So it sounds like the EU have learned their lesson:
Similarly with the Article 29 Working Party, the Board is composed of the heads of national supervisory authorities and the European Data Protection Supervisor (EDPS), or their representatives. The EDPS’s voting powers are restricted to those decisions that would be applicable to the EU institutions.
The Board also includes a representative of the European Commission who, however, does not have a right to vote so as to ensure the independence of the Board. There seems to be an implicit suggestion that the European Commission has exercised too much influence over the Article 29 Working Party in the past and the GDPR wants to ensure that this will not be the case in the future.
There’s some great provisions in the GDPR but I have to wonder just how quickly some of the decisions and actions will be taken:
Together with the establishment of the Lead Supervisory Authority presented in the previous step, the consistency mechanism is intended to avoid such situations. When it is clear that the decision of a supervisory authority will have an EU-wide impact, or when a request comes from a national supervisory authority, the Chair of the European Data Protection Board or from the European Commission, the Board issues a non-binding decision on a specific case. The national supervisory authority dealing with the case shall take utmost account of the decision of the Board or shall inform the Board in the case in which it does not intend to follow its opinion.
Codes of conduct
Part of any compliance system involves self-regulation, and the GDPR is no different. I like the ‘code of conduct’ approach in this regard:
For controllers and processors, codes of conduct are an important tool for achieving legal compliance and creating evidence to support this. Member states’ supervisory authorities, the board, and the commission encourage drafting codes of conduct. Such codes of conduct can be prepared, amended, or extended by associations and other bodies representing categories of controllers and processors. Codes of conduct need to include measures specifying the application of the GDPR, This includes, for example, the collection and pseudonymisation of personal data, exercise of data subjects’ rights, and notification of a data breach. Codes of conduct contain mechanisms that enable supervisory authorities to carry out mandatory monitoring of compliance. Drafts, amendments, or extensions of codes of conduct need to be submitted to the supervisory authority for approval.
Companies and other organisations have to ‘walk the walk’, though, and not just have their documentation in place:
Apart from supervisory authorities, other competent bodies with an appropriate level of expertise and accreditation can also monitor compliance with codes of conduct. Drafting codes of conduct is one thing. Committing to them is another. It is important in the sense that it can provide evidence that controllers and processors comply with the GDPR. This not only counts for controllers and processors within the EU, but also for those who are not subject to the GDPR in order to provide appropriate data protection safeguards.
Binding corporate rules
One way of moving beyond a code of conduct is for large, multi-national organisations to implement ‘binding corporate rules’:
Binding corporate rules (BCRs) are internal rules adopted by multinational groups of companies. They define the group’s global policy with regard to the international transfers of personal data to companies within the same group that are located in countries which do not provide an adequate level of protection. They are legally binding and approved by the competent supervisory authority in accordance with the consistency mechanism.
These rules are beneficial for the organisation (efficiency / consistency), for the EU (compliance) and for the end user (transparency).
The GDPR allows for personal data to be transferred outside the EU, but not just anywhere:
As a general rule, transfers of personal data to countries outside the European Economic Area may take place if these countries are deemed to ensure an adequate level of data protection.
Article 45 GDPR provides that the third countries’ level of personal data protection is assessed by the European Commission. According to the GDPR, the Commission’s adequacy decision may be limited also to specific territories or to more specific sectors within a country. A current list of countries that have been evaluated as having an adequate level of data protection can be found here.
The example given in the course is of Japan, which isn’t currently listed as having adequate protections. However:
Personal data can be transferred to a third country even in the absence of an adequacy decision:
(i) if the controller or processor exporting the data has himself provided for appropriate safeguards; and
(ii) on the condition that enforceable data subject rights and effective legal remedies are available in the given country.
At the end of the day, it’s the organisation’s responsibility as the data controller to comply wih the GDPR:
In accordance with the provisions in Chapter VIII, controllers and processors are legally liable for damages caused by data processing activities which infringe the GDPR. A controller is liable for all damages caused by processing activities. A processor is liable for not complying with its obligations or for acting outside or contrary to lawful instructions of a controller. A data subject who has suffered material or non-material damages as a result of a violation of the GDPR has the right to receive compensation for damages…
So now we get to the interesting part. What can the EU actually do about GDPR infringement?
According to Article 83 GDPR, the fines may, depending on the infringed provision of the GDPR, amount to a maximum of 20 million Euros, or, if this is a higher amount, to 4% of the total worldwide annual turnover of an undertaking. For example, a failure to implement the data protection by design and by default is subject to a maximum fine of only 10 million Euros or 2% of the total worldwide annual turnover of an undertaking. On the other hand, violating the basic principles of data processing, including the conditions for obtaining a valid consent as well as non-compliance with a supervisory authority’s order may result in the highest fine of 20 million Euros or 4% of the total worldwide annual turnover.
That’s obviously a lot of money, but it’s a sliding scale:
What the amount of a fine will be at the end will depend on the nature, gravity and duration of the infringement as well as on its character – if there was intention or negligence from the undertaking. The supervisory authority must ensure that the administrative fines would be in each specific case proportionate to the infringement and at the same time also effective and dissuasive. As a result, not all infringements of the GDPR will lead to those serious fines mentioned above.
The good thing, however, is that the fines are calculated on global revenues, rather than just the amount the organisation makes in the EU:
Once the GDPR becomes applicable, the impact of a fine on data controllers and processors, even if not reaching the maximum amount established in Article 83 GDPR, could be significant. Also, in those situations in which a global organisation has only a small establishment in the territory of the European Union, or is completely based in third countries but it targets the processing of personal data of EU citizens, the fine would be based on the total worldwide annual turnover. Thus, following the data protection rules as established by the GDPR should be taken seriously both by EU and foreign organisations.
I’m hopeful that the GDPR is going to help the legal system catch up with some of the technology that’s permeated our lives over the last couple of decades. Time will tell, of course…
Sending outIssue #292 of my Thought Shrapnel newsletter. This one was called ‘Is there a cure for Tasmania? 🇦🇺’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
I’m heading back to the UK this evening then will be at home for the next couple of weeks working on Project MoodleNet and wrapping up some consultancy work. After that I’ve got a bit of travel to events in Europe from mid-March onwards.
Sending outIssue #291 of my Thought Shrapnel newsletter. This one was called ‘ Necessary koalafications 🐨’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
Working in Perth and Mandurah, Australia at a Moodle team leads workweek. It was great to hang out in person with my colleagues, some of which I’d never met in person. We got lots done, and it was my pleasure to help facilitate some of that.
Sending outIssue #290 of my Thought Shrapnel newsletter. This one was called ‘Unscathed’ and featured curated links from the Thought Shrapnel blog (where you can also sign up if you don’t yet subscribe!)
ActivtyPub is a protocol that allows for decentralised, federated social networks. We’re experimenting with it as potentially the base on which we can build Project MoodleNet, “a new open social media platform for educators, focused on professional development and open content”.
Mastodon is great, but purposely limited in features to keep things easy for users, moderators, and administrators. Hubzilla, on the other hand, gives users plenty of options.
Hubzilla is a free and open source set of web applications and services running on a special kind of web server, called a “hub”, that can connect to other hubs in a decentralised network we like to call “the grid”, providing sophisticated communications, identity, and access control services which work together seamlessly across domains and independent websites. It allows anybody to publicly or privately publish content via “channels”, which are the fundamental, cryptographically secured identities that provide authentication independently of the hubs which host them. This revolutionary liberation of online identity from individual servers and domains is called “nomadic identity”, and it is powered by the Zot protocol, a new framework for decentralised access control with fine-grained, extensible permissions.
What does that mean in practice?
From the practical perspective of hub members who use the software, Hubzilla offers a variety of familiar, integrated web apps and services, including:
social networking discussion threads
cloud file storage
calendar and contacts (with CalDAV and CardDAV support)
webpage hosting with a content management system
While all of these apps and services can be found in other software packages, only Hubzilla allows you to set permissions for groups and individuals who may not even have accounts on your hub! In typical web apps, if you want to share things privately on the internet, the people you share with must have accounts on the server hosting your data; otherwise, there is no robust way for your server to authenticate visitors to the site to know whether to grant them access. Hubzilla solves this problem with an advanced system of remote authentication that validates the identity of visitors by employing techniques that include public key cryptography.
In this post, I want to outline some of Hubzilla’s features and discuss how they may be useful to Project MoodleNet. This is not meant to be comprehensive, by any means, just my first impressions.
1. Configurable UX depending on user technical knowledge
When you set up your account in Hubzilla, you’re presented with this drop-down menu asking you to indicate your technical skill level. The lower you set this, the simpler the user interface becomes. I like this because, as with any kind of community, there are more and less technical educators who will be using Project MoodleNet.
2. WebDAV integration
Although not strictly accurate, I set my technical skill level as ‘Wizard’ to see all of the options available in Hubzilla. This box appeared informing me of my WebDAV address:
Web Distributed Authoring and Versioning (WebDAV) is an extension of the Hypertext Transfer Protocol (HTTP) that allows clients to perform remote Web content authoring operations.
The WebDAV protocol provides a framework for users to create, change and move documents on a server. The most important features of the WebDAV protocol include the maintenance of properties about an author or modification date, namespace management, collections, and overwrite protection. Maintenance of properties includes such things as the creation, removal, and querying of file information. Namespace management deals with the ability to copy and move web pages within a server’s namespace. Collections deal with the creation, removal, and listing of various resources. Lastly, overwrite protection handles aspects related to locking of files.
Many modern operating systems provide built-in client-side support for WebDAV.
This is handy stuff, especially given that NextCloud, which is a great service for files, calendars, contacts, and other applications, also supports ActivityPub and WebDAV!
3. Inbuilt calendar
Talking of calendars, Hubzilla has one built-in under ‘Events’. It’s pretty basic, but it’s easy to create entries and import/export existing calendars. I assume that there’s a way to link this up with WebDAV, but it wasn’t obvious in the time I spent tinkering.
4. Other apps
Other apps can be added and removed by users in a range of categories. All the basic things you’d want are there, and new apps can be developed and added in a straightforward way.
5. Multiple profiles
One thing I immediately liked about Hubzilla was the ability to create multiple profiles, should the channel owner allow. This permits users to create profiles that demonstrate different facets of their personality, and perhaps share information with certain groups that they wouldn’t share publicly.
The only current downside to this was that I couldn’t find a way to have different images for different profiles. I guess these are sub-profiles, but it would be nice with Project MoodleNet to have different avatars for different facets of your identity within the system. Something to test out, for sure.
Hubzilla is built around ‘channels’ that you can discover and add via any compatible instance. So, just as with Mastodon, people can find and add you no matter which server they’re using.
7. Adding content
I tested out adding content into a channel by posting a link to a resource I found on OER Commons. There’s no visual editor, but the channel owner does get to choose between wiki markup or Markdown. There are buttons which generate the necessary code for users, as Mediawiki does by default.
8. Responding to posts
As you’d expect, because it’s 2018, you can respond to posts not only with a Facebook-inspired ‘thumbs up’ but also with a range of emojis. In addition, there are a range of options, including ‘Poke’, ‘Share This’ and starring the post to come back to.
9. Mastodon vs. Hubzilla?
I asked people, ironically enough on Mastodon, what they thought about Hubzilla. I some quick responses, and you can see the thread here. It seems like Hubzilla is a lot more flexible than Mastodon, but it’s by default relatively complex, which can put less technical people off a bit.
We’d obviously do a deeper dive if and when we decide to experiment further, but Hubzilla’s code is on GitHub and the repository seems to be pretty active. They’re on v3.0 and, according to some quick digging, the first release was in August 2015. There’s only 47 nodes with 847 users at present, however, compared with over 1 million users of Mastodon across almost 1,500 instances (source).
Hubzilla has some very nice features which we would definitely want to implement with Project MoodleNet. Whether or not it’s the best base to start from is a decision we’ll have to make as a team, but I’ve enjoyed experimenting!
It’s a surprisingly interesting subject, so much so that I’m in danger of, for the first time ever, actually completing an online course that I’m taking voluntarily!
Although it’s my choice, I’m pursuing knowledge in this area because I’m leading Project MoodleNet. However, I’m writing here instead of on the project blog as I’m still coming to grips with all that GDPR means in practice.
Week 3 of the course is all about data controllers and data processors. The quotations I use throughout this post are taken from the course, which I highly recommend (you can sign up for free!)
In brief, data controllers are those who determine the purposes and means of processing personal data. When two or more controllers do so jointly, they are joint controllers. Processors, on the other hand, are those engaged in processing personal data on behalf of controllers. They will follow instructions given by controllers and cannot make decisions on the choice of purposes and means in data processing.
Here’s a more homely metaphor:
To make this more clear: if you visualise a ship and imagine that it is processing data, the controller is the captain and the processors are the sailors. A controller manages and controls the processing of the data (the ship), he determines the purpose (the destination), and the means (or the course of the voyage). A processor is contracted by the controller to carry out data processing for the purpose and with the means determined by the controller. Processors (sailors) act under captain’s instruction and report issues to the controller.
So from a Project MoodleNet perspective, Moodle (the company) is the ship, providing both the purpose and the means. The processor is the Project MoodleNet team which is processing the data. To the end user, the data controller and data processor are effectively one and the same.
The interesting thing about the GDPR is that you can’t just respect users’ privacy and security, you have to prove that you’re doing so:
First of all, to demonstrate legal compliance is in itself a GDPR obligation. Being able to demonstrate that your organisation is taking compliance measures, both technical and organisational, may save you from potential hazards, such as heavy fines or sanctions. Controllers have to implement appropriate technical as well as organisational measures to make sure that processing of data complies with the GDPR. They have to implement these measures to ensure data protection by design and by default.
One method of doing so is ‘privacy by design’, something covered in a previous week, and which allows you to demonstrate that user-respectiving privacy safeguards are built into your products and services.
However, things can and do go wrong. GDPR therefore mandates what must happen in the event of a data breach:
In the event of a data breach, controllers have the obligation to notify the supervisory authority of that breach.
The supervisory authority in the UK is, I believe, the Information Commissioner’s Office. Moodle is an Australian company that is setting up an office in Barcelona. Until that’s set up, Moodle is processing EU members’ data without a legal presence in the EU. I wasn’t sure what that meant in terms of supervisory authority, so looked it up. Basically, it means that instead of a ‘one-stop shop’ approach, in the event of a data breach, Moodle would have to inform each member state individually.
The data controller has a responsibility to help users exercise their GDPR rights:
Finally, a very important obligation for a data controller is the duty to assist data subjects with exercising their rights to privacy and data protection under the GDPR. For example, a controller has the duty to provide data subject with sufficient information when collecting personal data.
Handily, the Futurelearn course (which is put together by the Universiy of Groningen) has a list of the obligations for data controllers:
• Specific obligations as regards transfer of data outside the EU (Chapter V GDPR);
• To assist data subjects with exercising their rights to privacy and data protection (Chapter III GDPR).
In other words, there’s a lot of companies that are going to have to get a whole lot more transparent about user data very quickly. I feel that we’re in a pretty good position with Project MoodleNet, as we can design all this in from the outset.
Data protection by default
Just as the GDPR advocates privacy by design, it also specifies ‘data protection by default’:
Data protection by default means that, by default, technical and organisational measures need to be taken to ensure that only personal data which are necessary for a specific purpose are processed. This obligation covers the amount of data collected, extent of processing, storage period and accessibility. This means that, by default, the less personal data that are processed, the better. This obligation includes that, by default, personal data are not accessible without the data subject’s intervention.
So, for example, I use an app called FullContact to manage my contacts across various accounts and to automatically update their details. It’s great, and I’m a paying subscriber to their service. When I install it on my Android smartphone, I get a screen which prompts me to give the app access to my contacts:
Given the job I’ve asked the app to do, giving it access to my contacts seems reasonable. I’ve seen other apps, however, request access to my microphone, location, and other ways of gaining potentially sensitive information about me, without any obvious reason why they would need to do so. GDPR compliance prevents this.
One thing we’ve been discussing with Project MoodleNet is pseudonymisation. Sometimes on a social network, for a whole variety of reasons, you may want to avoid posting with your ‘regular’ account. In this case, token-based pseudonymisation can help:
An example of an effective measure as mentioned in Article 25 is pseudonymisation. Pseudonymisation substitutes the identity of the data subject in such a way that additional information is required to re-identify a data subject. Such measures may also include anonymisation, which irreversibly destroys any way of identifying the data subject.
So, for example, you might be able to generate a finite number of pseudonymous accounts with your login details every month. This would mask your identity when it matters but, if you decided to do something illegal, or troll other members of the network, it would be possible to figure out who you are.
All of this is fascinating as, instead of organisations making it all up as they go along, they have to figure a lot of things out in advance. in order to satisfy their legal requirements and inform the user
When collecting personal data directly from data subjects, the controller has to provide the following information to data subjects at the moment of the obtaining the data:
The controller’s identity and contact details;
The contact details of the data protection officer (if applicable);
The purposes and legal basis for data processing;
The recipients of the personal data;
The fact that the controller intends to transfer personal data outside the EU (if applicable).
Furthermore, to ensure fair and transparent processing, the controller needs to provide the following information:
The reason why the data subject needs to provide personal data (this could be a statutory or contractual requirement or a requirement to enter into a contract), if the data subject is obliged to do so and what the consequences are for not not providing the data;
Data storage period;
The rights of data subjects (right to access, rectification, erasure, restriction of processing, objection to processing, data portability, the right to withdraw consent; the right to lodge a complaint with a supervisory authority);
The existence of automated decision making (including profiling);
Any other purposes (if the controller intends to further process the personal data for a purpose other than that for which the data was originally collected).
Over and above this, organisations have to be lot more secure in their data storage and processing procedures.
Under Article 32, controllers have the obligation to take technical and organisational measures to achieve a level of security appropriate to potential risk. When taking these measures, they need to consider the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons. Examples of such measures include:
Pseudonymisation and encryption;
Ensuring the ongoing confidentiality, integrity, availability and resilience of processing system and services;
The ability to restore the availability and access to personal data in a timely manner in case of physical or technical incident;
A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures to ensure the security of the processing.
Returning to what happens when and if things go wrong, and user data is compromised, the GDPR makes very specific provisions:
When a data breach occurs, a controller has the obligation under Article 33 to notify the competent supervisory authority within 72 hours after becoming aware of the data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If the supervisory authority is not notified within 72 hours, the controller needs to provide reasons for the delay.
Note the ‘unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons’. In other words, if there’s a data breach but the data is encrypted (as in the case of the LastPass hack) then, as far as I’m aware, while the organisation may choose to notify the supervisory authority, they are not required to do so. Obviously, if personally identifiable information was accessed, then the organisation would need to notify the relevant supervisory authority within 72 hours.
If there’s an elevated risk, then the notification should be immediate. The ‘data subject’ (i.e. user) also needs to be informed, in ways that they can understand:
Furthermore, the controller has the obligation to communicate without undue delay the personal data breach to the data subject under Article 34 if the breach is likely to result in a high risk to the rights and freedoms of natural persons. The communication to the data subject needs to be described in clear, plain and understandable language.
Data Protection Impact Assessment (DPIA)
Interestingly, the GDPR makes provision for new kinds of technologies that may put ‘data subjects’ (i.e. users) at risk. Organisations using new technologies to obtain personally identifiable information are required to carry out a Data Protection Impact Assessment (DPIA):
If there is a chance that a new type of processing (especially when using new technologies) may cause a high risk to the rights and freedoms of natural persons, the data controller needs to carry out a DPIA.
The example in the course is something like using ultrasound to ‘fingerprint’ people. This won’t be a concern for Project MoodleNet, as we’re using pre-existing technologies.
Data Protection Officer (DPO)
Apparently, in earlier drafts of the GDPR, the appointment of a Data Protection Officer (DPO) was mandatory for all organisations that had over 250 employees. However, as I’m sure someone pointed out, when Instagram was purchased by Facebook, it had 27 million users on iOS alone… and only 13 employees.
The final version of GDPR makes no mention of the number of employees an organisation must have before having a DPO is mandatory. Instead, it focuses on the type and scope of the data being processed.
Appointing a DPO is mandatory under certain conditions. Based on Article 37 a controller and processor need to designate a DPO if:
The processing is carried out by a public authority or body (with the exception of courts acting in their judicial capacity);
The core activities consist of processing operations that require regular and systematic monitoring of data subjects on a large scale;
The core activities consist of processing on a large scale of special categories of data (Article 9) or personal data relating to criminal convictions and offences (Article 10).
As we have already seen, data controllers and data processors are different. Data controllers, using the nautical metaphor introduced earlier, are like the ship’s captain, whereas the data processors are like the crew.
Processors process data on behalf of controllers and under controller’s instructions. Processing has to be governed by a contract or other legal act under EU or national law that is binding on the processor. This contract or legal act, among other things, determines certain obligations for processors and how they assist data controllers in fulfilling their GDPR obligations. Some of these obligations are similar to the obligations of data controllers.
Not only are some of the obligations the same, but as with the case of Moodle and Project MoodleNet, the data controller and data processor are one and the same.
Again, data processors have to be able to demonstrate that they are acting within the terms of GDPR:
The most important obligation for both controllers and processors is to demonstrate legal compliance. Concrete technical and organisational measures (such as documentation, records, Data Protection by Design and by Default, etc.) may provide good evidence to demonstrate compliance with the GDPR.
Applying my learning to Project MoodleNet
Finally, the third week of this course asks a few questions:
Do you need to carry out a DPIA?
Do you need to appoint a DPO or a representative?
The second and third questions are the easiest to answer. As Project MoodleNet does not involve new technologies that access personally identifiable information, we won’t need to carry out a DPIA. In terms of the DPO, Moodle is currently interviewing for a DPO to be based in the new Barcelona office.
Returning to the first question, Moodle has blogged about how the organisation’s approach to GDPR in terms of its open source learning platform. With Project MoodleNet, however, the answer to the sub-questions around record-keeping, privacy policies, etc. is “we will have”. As I mentioned earlier, one of the benefits of developing this project as GDPR comes into force is that we can build it from the ground with these in place!