 So, today we're going to be talking about data privacy, more particularly the GDPR, but I'm hoping that it applies to most data privacy. Most of what we did for the 3.5 release, which includes the data privacy tools in Moodle, I was sent around bringing in just general privacy into Moodle. There were some things that were very GDPR specific, but we tried to keep it as general as we could. For most of us in Australia, where we may not have GDPR requirements, you can still use these tools and we do recommend that you do. So firstly, what is the GDPR? Well, the GDPR is a EU regulation that, I'm not a lawyer, basically we're looking at for protection of personal data. It's a set of rules that says what users can expect to do and it's giving the rights back to the users, to the people that submit the data to various sites and they've got certain things that they are now entitled to as part of this. The aim is to empower individuals, emphasis on the empower Moodle, but we want to give them control over their personal data. The most important point about the GDPR is that it affects everybody, so well, potentially could affect everybody, sort of disclaimer there. It can affect you if you have users that are in the EU. And again, I'm not a lawyer, but we had extensive discussions when we were developing this in HQ and the gist of things is that it most likely does affect you. So keep that one in mind. So basically the format for this is I'm going to say, look, this is how we need to do this in Moodle and I'm going to talk you through some of the features that we've added for 3.5. So essentially GDPR for Moodle means that we need to know where the personal data is in Moodle and that's one of the core challenges that we had with this one because as you are all aware, Moodle is based on a plug-in ecosystem and we didn't have an ability to ask those plugins where their data was, so we had to build that in. And yeah, spoiler, the data is everywhere. Plugins, lots of data. Core has lots of data and we had to centralize that. So that's one of the challenges we have here. One of the other challenges is, or questions we need to ask rather, is how can institutions ensure they don't retain personal data beyond its intended retention period? Now, the retention period is key here because it ties in with the purpose for capturing the data. So different types of data will have a different retention period that you may be entitled to keep that data for and that's stipulated by the GDPR. Third thing that this means for Moodle is, well, a third question rather is how can users be clearly informed about that data that's being captured? Now, you probably have privacy policies out there for your sites at the moment anyway, but we needed to bring that in and make it a little bit more fine-grained so that you can include third party privacy policies and things like that. And the fourth point or question is how can users ask to have their data removed and there's actually should be a slash? And there's a slash requested because two things that the users need to be able to do is ask for their data and ask to be forgotten. Excuse me while I recover a little bit. Now, the way that we address this in Moodle, we've got a new section for privacy and policies and that's in the admin settings area. We've got certain settings that were visible by a privacy officer. There's a set of capabilities that we would recommend using when dealing with a privacy officer role. We don't ship that role, but we have the ability to create that role. And so those settings will be tied with that. Second point, we have now new tools in core. Now, initially when we rolled this out, we had separate tools for Moodle 3.3 and 3.4, but as of about a month ago, those tools were included in core for 3.3, 3.4 and 3.5. So they all ship now, depends on which version you're with. You may still have the external tool as a plug-in, but if you're on the current versions of 3.4, 5 and 3, sorry for that matter, then you should have access to those tools. And we did actually have this third point as a part of one of those tools initially, and this is age of consent verification for miners. This was, as I said, originally in the tool, but we decided that it's useful to have in core and it's useful for everybody. So we've included that in core and not as part of one of the tools. When I say these tools, I mean, these are admin tools, basically, people. So they sit and they have admin settings that you'll see in a moment. So this is where we're going to start moving through some of the live stuff, so I can show you, I say live, it's just going to be stepping through a screen chart, so I'm not game enough to do a live demo. But at the bottom here, we have the privacy and policy section that I was talking about earlier. And you can see we've got a range of settings down there for privacy, policy, data requests, data registry and deletion and a couple of other registries, policy management and agreements. So there's a lot to get through, so I'll start stepping through some of that today. So I'm going to start with the policy tool. One way we think about it is there's two main tools that we're shipping as part of GDPR. There's a very small amount that's outside of that scope. So the first of these tools is the policy tool. Now what does this tool do? What are we aiming to achieve with this tool? Well, what we're trying to achieve is to allow the privacy users to create policies, version policies and sort of categorize policies across the Moodle site. Now we did actually have some of this already, but not to the extent that we needed, so this tool comes in to allow us to do that. And this sort of allows us to answer the questions, what data are we storing and why are we storing it to an extent and the users are informed that through the policies. Like I mentioned before, we can do versioning on these policies now too. So if we have a minor update to a policy, it's up to you guys to decide whether that dictates that everybody needs to re-accept that policy. And that's something that can be important legally. So that's something that we've built into this as well. And the most important thing, I guess, is that providing the workflow for users to read and accept these new policies. So I'm sure you're all familiar with pages like this on different websites that you've been to before. This one is a cookie statement, but you could substitute this for a site policy in terms of use, that sort of thing. This is just an example here that we've got for cookies. And excuse the diagram in the middle, I don't know if we actually would ever use that really, but it's just an example. You can see in the top right there we've got policy one of three and that's just saying if new users come along and they're using Moodle, they'll step through the policies that they're required to accept and then they'll be presented with something that looks like this where they're asked to then go and tick the boxes that say I've read and agree to the terms for these various statements. Now these statements are all configurable. We'll get to that in a moment. I just wanted to start off with showing you guys what we are aiming to get to with what we've done with GPR. And then we'll work on building that in the back end. You'll see that in a second. Disclaimer at the moment, these are all required policies. We have actually got work in progress right now to make optional policies supported as well. Just so keep that in mind if that's one of your questions that's coming to mind. This screen here is basically what happens if you click one of these little blue links. You might see that there, cookie statement, privacy policy. So you can sort of read that policy in line and once you get to this final step when you're actually looking at this. So you can see what you're accepting. Now back on the other side of things, we're gonna talk about now how do we get to that? And we do that by going through the policy settings which is part of that new privacy and policies area. Now that little box there that says default core handler is important because when we ship Moodle it is just a default core handler and we actually have to enable the tool that allows us to do these policy management. And so once we've gone into the policy settings themselves we can have a look at the policies at the top there and you can see site policy handler and I've selected the policies tool which is the new tool that we're shipping. And once we do that, that's basically enabling the tool and save changes obviously. Now that brings up new user options in privacy and policies because that tool's been enabled. That's extra functionality that it's providing. We can manage policies and sort of look at user agreements to those policies. So if we click on manage policies assuming we've created some policies there's gonna be a few assumptions here with what policies we have but we've got one for cookie statement, privacy policy and site policy. You can feel it, generic things. This is your sort of table view and you can have a look and edit these. If you wanna set one as inactive for whatever reason that's where you would do it as well. You've got your version controlling here as well. If we were creating a policy, standard Moodle form, one thing that I've circled down the bottom here is whether it's an active or a draft policy. You can create draft policies that won't do anything until you activate them. So if you're kind of work in progress that facility is there. That will come up as a draft and then through the actions menu just like you would expect, you can activate that policy. Now user agreements, once some of your users have started to come through the Moodle site, that's where you'll go to have a look at who's accepted what. And I'm not sure how many of you are familiar with the newer versions of Moodle but we've got this sort of where it says search keyword and select or select the top there. That's sort of a live filter so you can type into that and it'll bring up a range of different filtering options for this. If you have 10,000 users on your site, you might wanna restrict that a little bit. So that's one thing that we've got built into this page. Now obviously you can come in here and have a look at who's agreed to what. There is a parent role in Moodle. I'm not gonna go into that today because that's a fairly complicated subject on its own but the parent role can accept policies on behalf of students, that, sorry, on behalf of their children if they're sort of the guardian for that person. And that's again where they'll come in and they'll look at a page like this and the privacy officer can also do that. And sorry, the privacy officer is the one that could do that here. The parent, they can do it in their own space. Like I said, I won't touch on that today. Now, one important thing that I touched on earlier was versioning in policies. Basically, it's gonna happen. You're gonna have updates to your policy. So we've built in versioning to this and the way that you achieve that is you've got an existing policy that might be a change to that policy. You go down into the policy edit for that policy and you'll save it as a draft. Now what that actually does is create a new version underneath your current policy with a, under that version column you'll see the V5. That's the V5 of the V4 if you like and that's a draft at the moment. So we can work on that new policy with the updates that we need and then we can approve that when we're ready. One of the things I didn't touch on was this minor change box down the bottom. Now, when you're creating a new version of a policy you might wanna say, this is only a minor change. Everybody who's already accepted this policy doesn't have to do so again. There's no legal ramifications. Maybe they don't need to do that. So you leave that as a minor change, tick the box, save. No one has to do anything. If you don't tick that box, everyone on the site is gonna be asked to re-accept that the next time they're entering the site. So that's just one of the things to keep in mind. This screen is basically just showing a previous version history for policies and the agreements. There's nothing in this one. It's all inactive. This is the test page to show that we do support that view. So let's have a quick look at age of consent just moving on from the policies. This is the stuff that we put directly in core not as part of one of the tools. And you can access that by the privacy settings link in the menu there. Now what this does, if you switch it on, of course, is it allows us to track per country what the digital age of consent is and why would we wanna do that? Well, that's basically because people are registering with the site and they're signing up. There's many cases where we wanna be sure that they're above that age of consent and that's where they will be asked to say how old they are and they'll pick an area and depending on where the area is, they'll be matched up against the digital age of consent. The second part you're looking at on the right here is what happens if somebody is not above that age and then it's asking them to say you need to contact Parental Guardian. So that's the policies tools. We're pretty happy that we can now ask users to agree to site policies, version policies. The other side of things is the data privacy tool. So what are the goals of this tool? Well, this tool aims to allow privacy officers to set the category of data, the purpose for capturing the data and the associated retention period with that purpose. Now, you guys probably know more than I do about the purposes for capturing data. I'll show you in a while how we can set those up. Most of what I'm showing you here has probably just been created for an example. So don't read too much into the exact text in those. But the important thing is that we can ask the plugins and set relevant categories and purposes against those and we'll track that. Now, the other goal of the data privacy tool is to facilitate removal of the personal data and that's an important one. That's basically allowing users to ask to have their data deleted. And obviously, third point, workflows to allow the user to do sorts of things. And that's on the student side of things. Obviously, all of this stuff applies to teachers as well, but there's probably other things going on with teacher contracts and data retention. And so for the simplistic example here, we're looking at just the student. So again, if we look at privacy settings here, we can see that top one that's got settings for dealing with data privacy. And what you get is just below that age of consent stuff down the bottom. We've got the ability to turn off contacting the data protection officer. Now, this was actually an old screenshot. If you see that, it means privacy officer. We mocked that up when we built this original presentation and I didn't really screenshot this, but just it's privacy officer. It also allows you to map the role which you'll basically be creating a privacy officer and setting that up and that's just saying which role is associated with that privacy officer. Now, the data request, this is one of the big parts of this tool. Once data requests are active, students will see this option, privacy and policies menu under their profile. Top option there, contact data protection officer, again, privacy officer. That's just a simple form at the moment to allow them to make contact with that person. I won't go into that today. You can just imagine a simple way before. That's all that is. The second option is more what I'm gonna look at which is the data request aspect. Now, this is our student Arthur and what he would see if he came in to create that new request. At the moment, he's got a table showing no requests. It's great. He's used the site for a while. Let's say he wants to create a new request. He's done, he's withdrawn from all his courses and he said, look, I'd like to leave, but I don't want you to retain into my data. So he can create a deletion request here and he can add a comment to that and basically that just sits there as pending now. Now, that's then the job of the privacy officer to come and look at those. So this view now, Mustafa here, he's the privacy officer. So he can come in and look at the data requests from the other side of things and see that there's one that is awaiting approval. Now, we don't automate any of this stuff because we want somebody to have a look at it. That was a choice we made when we built this. We hope it was the right choice. Basically, there should always be somebody as a privacy officer within an organization. So that role is well defined and we think it makes sense for them to have to do that as an action. But we welcome feedback, obviously. So as a privacy officer, we can view the request, approve the request and deny the request here. That's basically allowing users to say, I want to be deleted, but that exact same process works if you want to say, I'm a user, I'm still using the site, but I just want a copy of my personal data. Or maybe I don't want to be deleted, I want to move on to another system, but I want to copy that data. They do that same process and instead of deletion request, it's a data request. Now, when that's approved, they'll get a zip file emailed to them, which has got all of their data from the Moodle site. And how do we know what data that is? Well, that's where the registry comes in. So the registry, and this is gonna look pretty complicated. Don't worry, you won't have to deal with this. Privacy officer was the guy who's gonna settle this up. But this is basically sort of a hierarchy view of all the bits and pieces in Moodle. There isn't really a nicer way to lay this out. Hierarchy being what it is. We could go to a little bit more fine grain and we've got some work doing that now, but essentially you're looking at your site at the top level, course categories, courses, course modules sitting under that. You're standard, you're probably all familiar with that sort of thing. This basically allows us to set up categories, purposes, retention periods against those various things. So we might want to say for courses, that's always gonna be a three year retention period because that data is, let's say, course data and the purpose is it's assessment data. And we have rules around the assessment data that mean that that's two years. Now we're not saying what this is, but we're just providing the tools for you guys to be able to do that. This one's a little bit hard to see, but I've actually picked the edit there. That's where you've got categories and purposes. So that's where you can add more of these things. And what you see here is basically the list of all those under I've clicked purposes here, but that's one of the purposes. Now the lawful basis column, there's a bunch of these, these are GDPR specific. You can use them, you may choose not to use them. You can have multiple lawful basis as well. And there are some simple options in there. So you can do sort of a generic lawful basis that should cover you in cases where you're not sure. Obviously you probably should have some legal guidance on this. But the important part about this page is that this is where you would set up the retention period associated with the purpose. So we're not saying that you can set a purpose and a period separately. As soon as it is for this purpose, then that's going to represent a period. Otherwise it just gets too complicated. But yeah, obviously you can create purposes. They're quite similar to other purposes that have a longer time, depending on your needs. This page here is just if we want to set defaults across those various elements in the hierarchy. So we can say, okay, all course categories, they inherit. So you might just set one on site. Or it's five years across the site. Everything else inherits from that. Probably not a real use case, but it is possible that you could do it that way if you wanted. You could say all courses in there, courses down, which includes course modules and blocks within the course. They might all have a different period. That really depends on your use case. Now, the data deletion, which I think is working, yes, it seems to be. This is based off the registry. So when you see this data deletion here, this is as the privacy officer, you'll be notified of things like this. And this is basically saying that, okay, let's say, what have we got here? Introduction to programming. This has passed its retention period. This has got all the information about that course. And it gives you an option to say, delete the data in there that belongs to users. This is something that basically you'll have to do if you're subject to the GDPR rules. You can't hold data for longer than you're allowed to hold it for, per the regulations. And this is just giving you a way to make sure that that is deleted. Again, it's one of those things, the privacy officer actually has to make an action to say, I delete this. The reason we chose to make them take that step is that there could be other sort of, maybe you've got a case where there's a legal constraint on a single user. You don't wanna have that happen automatically because of a court order for that specific student. There's very, I'm making this up obviously, but there could be foreseeably cases like that. So we'd like a person to actually oversee and review this deletion before it happens. One of the other things that we built as part of the data privacy tool is a plugin registry. This is probably more for your CIS admins that are setting up sites to make sure that you're compliant, basically. You don't wanna roll out your site and have half your plugins not be compliant with the GDPR. We've got a whole API that plugins have to implement to say, I do X, Y, and Z, and I'm compliant with the GDPR. That's not really in scope today, but the plugin devs know what they have to do for that sort of thing. What this does is basically list out all the plugins in the site and it will allow you to review all the data that that plugin captures and why that plugin would capture that data. That's where we've got this example. We've got assignment module and we've got assignment grades. In this case, it's the grades table for a user. So that is user data. The grades belong to the user and also overrides, same case. This page will get massive, but basically what you're looking for is this little red notification next to things that say, look, something's not quite right. We haven't implemented this API. Don't roll your site out yet. And if you are asked by any regulating body to show the data that you have captured on users and why you're capturing it, this is the page that allows you to retrieve that. So you might say, the assignment stores data and there's many more below this, believe me. This will scroll down quite a ways, but it allows you to go really fine grain and say this is all the data we capture, specific fields and tables. The reason we have to do this is GDPR, basically. It's just a regulation that says that you must provide this information. So that's pretty much what we've got in core for the moment with 3.5. That's what we rolled out with. We have a couple of things underway now. We had time constraints for 3.5 for this. So we had to cut a few things out. At the moment, we have a zip file export. Not great. You'd really like to see an HTML page where you can just look at your data in a nice friendly format. So that's one of the things we're doing at the moment. Optional policies, I mentioned that one before. That's something that we're working on as well now. Now, module type defaults, that kind of comes back to... Let me bring up that slide again. This one, so at the moment, if you see that plus next to the courses, you imagine you've got courses under there. That's as far as we go. We're saying everything in that course is subject to the same rule. And you can go down to the modules, but not by type. So what this actually does, that last point, that last point that I'm looking at on this slide, is say, for all assignment modules that are used in the site, for every new instance of that, there'll be some defaults for those, and that's just expanding what we've already got in that hierarchy, just something that we didn't get time to get to with 3.5. Role-based retention period overrides. Yeah, that's a mouthful, but basically, it means that you might have a bigger retention period or a smaller retention period, depending on the role of the user in that context, within the hierarchy of what you're seeing in the site. That is another mouthful, but you can imagine that different users might have a different reason for their data to be captured, and that allows that to happen. Bulk handling of deletion requests, that's just a simple enhancement to the form. At the moment, they have to approve each request one by one. This just allows them to do bulk actions on that, and that's something that's coming as well. I'm not sure if any of you have looked at what we have right now with the GDPR stuff, but some of these things were raised immediately as soon as we released 3.5. Basically, people are saying, why didn't you do this? Why didn't you do that? Yeah, well, we didn't have time. We are doing that now. Filtering and ordering, classic example. The last point here is just revising the way user deletion ties in with the GDPR, and that's basically because we didn't touch any of the existing delete user stuff in Moodle, so there is this page in the admin where you can go and delete a user. That's a soft delete. It doesn't touch anything. It doesn't actually remove all the personal data. People use that in a way that perhaps wasn't recommended, but they are doing that, so we decided, rather than break the way that they like to use that, we're going to leave that alone, address that one more time, and that's something that we're looking at now so that if you delete a user that way, it'll trigger a GDPR delete request for that user, and then the privacy officer can be aware, okay, well, we've already soft deleted this person. Let's go and have a look at what we need to do in terms of GDPR now, and they can approve that, and take that through. So we are trying to address some of the issues that we had with 3.5 with this. I hope that you all managed to hear me okay today and got through it, and hopefully wasn't too messy in terms of the presentation. But yeah, thanks very much for your time, guys. Hope you enjoy the Mood. Now, I'll take questions if we have any.