Protecting Personal Data with Django (because it's the law)

Speaker 1: Okay, everyone. I hope you enjoyed lunch. We are now back with our next series of talks, and we will start it off with Will Hardy talking about protecting personal data because it's the law.

Speaker 2: Hello everybody. Um my name is Will Hardy. I'm a software engineer with a law degree. Um and while I liked the legal world, I preferred to build things. So I never really knew what I wanted to do with that degree, but now I have something to do. I'm here to talk about the GDPR. If you haven't heard Anything about that? Well done. But for those of you who have absolutely no idea what the GDPR is Uh while you're getting thousands of frantic emails uh talking about this GDBR thing, allow me to be the one to fill you all in 2016 GDPR is a 40-kilometer wide asteroid on its way to impact mainland Europe on the 25th of

Speaker 2: May 2018. By an astonishing coincidence, the EU Parliament in 2016 announced a regulation called the GDPR and it will take effect and I'm not making this up on the 25th of May 2018 For my own sake, I'm going to ignore the asteroid completely and focus on the hypothetical peaceful life in the European Union after the regulation takes effect. By the way, I'd like to warn the transcribers that I am another Australian, but I've been living here long enough to learn to speak a little more slowly. I'll also say data, not data, and there's not much I can do about that. Um so what is the GDPR? Uh it regulates the processing of personal data.

Speaker 2: You probably You probably already have similar laws. Um there was an EU directive in nineteen ninety-five. But uh so a lot of this isn't new, but the scope and the enforcement of the laws has changed dramatically. Uh it is a regulation and not a directative. So the directive in nineteen ninety five was just sort of asking the member states Please could you maybe do something like this? But now the regulation is a law that applies everywhere in the EU simultaneously and has the same laws. As a user, it's much needed, I think, and wonderful regulation. You may have already noticed a w

Speaker 2: a lot of wonderful emails telling you all about your rights in recent days and recent hours Um and asking for your consent. Uh you may already have a warm feeling of trust in these EU companies that are now asking telling you that they will handle your personal information more safely. And you still have this feeling of control over your personal data. You can delete anything, uh, or you have this feeling you know things will be handled properly and safely. I'm not sure if this feeling is valid. Um The timing over the recent concerns, public concerns over Facebook's algorithms is has maybe made this a bit more interesting. And uh it's nice to see such attention coming to this uh in the last few days. The regulation itself isn't that big. I had a copy around here somewhere.

Speaker 2: It's um it's have a feel uh feel free to read through it, it's not too difficult. The first 30 pages or so are just recitals telling you about uh what it should be doing, um and they're not really binding The after that you have the articles, which are the sort of the binding bits, and they're all nice little chunks of information that's easy to get through. The first 34 of these are uh relevant for us. Uh after that it goes on about setting up all sorts of things that we don't really care about. Um we'll go through some of these articles in a minute, and the There are a couple of interesting ones towards the end, um, but uh have a nice read and you'll be fine. Um the most important thing is of course just don't panic. Um

Speaker 2: you still have plenty of time left. I'm here to talk mainly not uh like a lot of other talks and articles and and and things that people have been saying. I'm here to talk more to the people who build the technology and not the managers and and anyone else who's uh trying to figure out what the law means. So there's a lot of information for those people and enjoy that. There's a whole internet full of that. But for us, we um We're more about we're building the system. So we'll probably maybe get told what to do. Maybe someone will say this is what I need implemented or the lawyer says this is okay, so maybe do it this way.

Speaker 2: Um but I think it's important, um even though as an employee you're not personally um uh responsible for compliance. Uh no one's going to attack you personally, it's the company. Um I still think that there's a professional duty for anyone who calls themselves a fancy name like a a a software engineer or an uh evangelist or a data scientist or anything like that. Um when you advertise yourself in this sort of a professional role I think there's a professional duty to be on top of these things. And this regulation is really central to what to what we do as an industry. And if you don't know it, you're you're not really uh trained in what your profession is expecting of you.

Speaker 2: Um Also, if you care about your employer, and not all of you do, but if you care about your employer, then you'll be helping them comply in a really effective way. Um, you're at the front lines, you know the details of the data, you know uh how everything fits together. Um and the people who are making these decisions, the lawyers especially, have no idea all the sort of details about what's going on. Um a good company might set up a a way of communicating uh between you and the people who make the decisions, but it's not always the case. So if you have a good eye for how things work and what might be private data or personal data and might might be this, you're going to be extremely valuable for your employer in helping them comply. And if you're valuable then maybe you might that turn into commum crensation

Speaker 2: or something like that, you'll have to negotiate that with your bosses. Um So what I'm going to do here is I'll just go through maybe three three things roughly some key concepts, some terms, so that you understand what it's all about Um, exactly. And then some of the rights that we as users and your users as users uh enjoy or should be enjoying. And third are just some sort of jobs and tasks that we as people who build software have to do. So, first of all, uh just as a a diving across from the the the development world into the legal world, terms in the legal world aren't so fixed as they are in software. There are there are no there are no types that you can define and there's no categories that very cleanly say this is personal data and this is this.

Speaker 2: It looks like it might be that way, but it's not really like that For example, the term personal data, this is the definition from the from the regulation. It's deliberately broad and it really encapsulates a whole lot of things. But For example, like your your name and your IP address, some cookies, the device IDs, all sorts of online identifiers are included in indirect information. But it doesn't always mean that it is the case. If you have a collective IP address that's probably not personally identifying, if you have a name that's John, a first name that's probably not in itself personally identifying. But if it's collected with other things or if you have a very, very unique name, then uh then it is suddenly uh

Speaker 2: uniquely identifying or identifying. Basically get a feeling for anything that relates to a person is personal data. So and that person that it's relating to is the data subject, lovingly named. Processing is also something very broad. Um it means any operation. I mean the text is here, but I print it off and stick it above your work place. It's anything that involves the collection, recording, structuring, like it's anything basically you do with data. Storage included, if you're not looking at it, it's still processing it. Data controller. So here's now some more interesting terms. A data controller is a special um it's an organization or a person in a professional context.

Speaker 2: that basically collects the data and controls how it's used and for what purpose or controls the purposes that it's used for. Um if it's purely personal, if it's just between friends, not included. Uh you'll be fine. But as soon as someone else is involved that's maybe in a commercial context, then uh they are a controller. There are lots of exemptions, don't worry too much about those. But The data controller also doesn't have to be in the EU. So Americans with the smirks on your faces, uh if you have EU citizens or data subjects in the EU, you uh should also be complying with this. It's broad but um I

Speaker 2: it's what's important is that there are two different types of uh entities. There's the controller and there's also a data processor. And the data processor is the person maybe the controller gave the data to. So they've collected the data from you for a specific purpose. But they've given it on to somebody else to do some work because they couldn't be bothered doing it themselves. Um freelancers, you are a data processor, potentially. Because you're not an employee. Um and you may be processing personal data, that's your role in the system. A processor has less duties. Uh you probably won't be asked specifically for consent or you won't be asked to delete things that all goes to the controller. But you still have some responsibilities and we might get to that.

Speaker 2: Finally there's also, or almost finally, special categories of data which are Anything revealing racial, uh ethnic origin, political opinions, religious, and so on, you can read it all there. Um this is Uh notice that gender and sex is not there. It's an interesting omission which will come later in discrimination. But um these Anything that comes under these categories then has to be treated with a bit more care and has some other rules that it has to go with. Get to know these and understand because if you recognize that flowing through your systems you really should maybe be doing something about that. Finally, there's also the idea of profiling.

Speaker 2: It's called out by name and it has a special definition and it has the some extra rules that also pertain to it. Um the It is very, very broad as well as the others. If you look at the categories, they seem specific, but you can probably fit a lot of stuff into those categories. This will come into effect when for discrimination and so on Uh but that's all the terms. There I only uh listed a few of them, but they're the main ones I think sort of us writing the software should know about because if you recognize any of them. and you're probably in the best position to recognize them, it's something you should maybe alert the company or the organization to what's happening. So, as a user we get some nice nifty rights

Speaker 2: and this is the exciting bit about the legislation. Transparency is the first one. We finally get to find out what they're doing with the data and who's actually using it and who's not really using it Because if they uh are going to use it for a specific purpose that's outside of your contract, of outside of what they're going to be doing with it, they need to tell you about that. And it's been interesting in the last few days getting the emails telling me all these services that you didn't realize were doing something with your data are doing something with your data. What does it mean, what you have to do here? It's not really your concern. That's in people in charge of the company should be doing that sort of thing. But that's basically some a right that we as users get to enjoy. Right to access the data. So as a user you get to see what they have about you.

Speaker 2: And this will be in uh a day's time we'll be able to see what all these companies have. They should be providing it electronically. You can either submit a request or if they uh don't want to deal with that, an automatic something built into their system of you somewhere. But can you answer these questions? Uh what data do you have about me? How did you get this data? Why are you saving the data? Um and who you're giving the data to? If you can't answer these questions, you have about a month to answer uh if anyone asks you. Uh the right to rectification is interesting, um, but for us it means can we correct the data? Like does your system allow the data to be corrected? Um have you fed some things into the machine learning algorithms and You can't change that anymore.

Speaker 2: If you just have a field in the database with a Django admin interface, then you're fine. You can just tell an admin to go in and change it. Thank you, Django. But you might want to add a simple view to let the users do it themselves. Thank you, Django, for enabling that as well. Ah, the next ride is erasure. So anyone can say, please get me out of your system. You probably also don't have to decide when and what to erase. That's hopefully coming uh from the people who make the decisions, but you have to know that it's technically possible. Um can you erase your users from your system, from your backups? Um And if you do have backups and you restore a backup, do users who had erased themselves suddenly reappear in your system?

Speaker 2: This can happen for a number of reasons. It's not just if they uh don't consent or withdraw consent, they may object to processing or the data may no longer be necessary for the reasons why they were taken. Um the next right is data portability, then it really affects us. If we're building systems, then we have to build systems that provide their data in a structured, commonly used and machine-readable format. Um which isn't too difficult to do. Maybe we already have Django serialization. Thank you, Django. But maybe uh it's just something that's a bit awkward in your system or maybe it's something you have to build. Um you have 30 days to do it, but you might want to Automate that. The um

Speaker 2: user can, and this is something that's not talked about too much, the user can ask for themselves to be flagged in your system to say, please stop processing me, uh but don't delete me. Uh it's a sort of like a a funny bit of the law that's sitting there somewhere, but you have to be able to do it. Um I doubt you'll get uh a request for this, maybe you will, but you have 30 days to comply, so maybe you can wait for that and wing it. But is someone going to surprise you with this request uh a week before it's due? Uh could you please make that happen The next one is also a right to object to automated decision making. And this may only affect some of you if you have systems that do completely automated decision making. Is anyone here from Schulfa? No? Good.

Speaker 2: Um there is uh already this law in Germany. Um Germany was one of the countries that that already has these things. Um But Schufa managed to get around that. Schuffer's a credit agency in Germany that's loved by everybody. And they managed to get around that by having a token person in their process uh click a button. And that meant it wasn't a completely automated process and they managed to to sidestep that. I don't know if that will work with the new regulation. We'll find out. The right to object is is similar to the removing consent, but it's uh for also for the times where you didn't collect consent. So maybe you have a system saying like these people consented and so on, but they can still object if even if they uh if you didn't get their consent.

Speaker 2: So, what things do we have to do? There are lots, but I'm gonna list some things that maybe aren't completely talked about everywhere, and some things that maybe address us specifically. A core aspect is this idea of by design and default. So it it's it's it doesn't it's not entirely clear and specific, but um and But um it's it's sort of important and it means you trying a la and If you give it a good go, you'll be fine, I guess. Um so taking into account the state of the art, the cost of information, la la la. Django already helps you with this because it it it The framework itself encourages best practices. The documentation pushes you even further in that direction and

Speaker 2: helps you to learn about best practices. And the community even more so. The community offers third-party frameworks that allow more techniques for best practices and conferences like this where you learn about how to do it properly. So in that sense, a lot of us are probably don't need to care as much about this. We probably all know somebody who does need to care about this who's storing. passwords in interesting ways, who has insecure systems who send data sets by email to uh 400 recipients in the CC field and so on. There's a lot of detail in this. Um I think they they mention things like pseudonymization.

Speaker 2: Yeah, okay. Um and that is uh basically what we already have already. If you use the Django uh Auth app, um the then you will probably have a model that has all the user information in it. some of it. And that will be linked with an identifier, that's pseudonymization. Everywhere else in the system, or if you pass it on to other things, don't pass the personal information, don't pass the The um don't pass the email address, don't pass names and that, pass the the number and ID or generate a UUID if you're using different systems outside of your Django system. Uh data minimization isn't really built into anything, you have to do that yourself. Just don't collect everything you see under the sun with the hope that maybe I'll one day use it.

Speaker 2: Sit down and have a think about what you might actually be using the data for and if you don't need it then don't store it. Build try and try and automate and build a lot of these things into your into your systems so that it doesn't you're not relying on someone to remember it or think about this. It won't cost you any extra time later if it's automated. If you're encrypting uh field by field, um I'll talk about that a bit later if we have time. Um Integrate maybe the purpose for which the data could be used, processed into your system so that uh it's clear at every stage what you can do and can't do. Um and maybe provide APIs if you're providing data to other people with inf like automatically restricting or anonymizing data before it gets used.

Speaker 2: We could take a small technical detour. I think we might have time. Basically, let's let's try to encrypt sensitive data by field. I thought We can do something with Django. If you do encrypt data in fields, you're not going to be indexing it or sorting it anymore. I hope you can live with that. um make a decision if you're just going to do them individually or by groups uh and what libraries you might use and you trust uh to do this properly. I would hope that maybe in the future Django might offer something like this that that does it in a safe way and then allows things to happen. So if we have a little model maybe that we have uh Uh and names. By the way, uh interesting fact it was the first email address uh that we know about. Um

Speaker 2: the real name maybe maybe we don't want to keep that public. Maybe um maybe you want to hide this from server admins, from Dana. or the support staff that are looking through the admin. And one way to do that might be if it's extremely sensitive, like medical data, might be to encrypt that. So we start with an unencrypted version and then we be we install the encrypted version and uh then have a function to get the decrypted version with a password. Problem of course is that uh this only happens when you log in because you don't have the password anymore. So we'll encrypt it with like a content key that you can get once you supply the password at login and and store it somewhere. Um But

Speaker 2: that is then only for one user. You could set up another model to l uh to encrypt the same content key for each user that needs it with their password. But that's also something a problem because then you'd have to store the content key for the whole session and where are you going to store that? So you would then probably maybe have another key, a user key, uh that you can store somewhere. Um you can either store it half of it in the in memory or a session and and the other half in the browser and use um uh secret um sharing to to bring them together and provide access. Something like this would then uh be able to encrypt

Speaker 2: Data within a model per user. So it's no longer a system-wide encryption, it's a per user encryption. And what you've done is You've you've managed to to for your backups, if you delete the key then you don't have to touch your backups. Deleting an encrypted file or deleting encrypted data just means throwing away the key. So But if you want to use encryption, it's a good way of deleting things, of uh sort of um shredding them by um By just throwing away a key that's not part of your backups, that's not part of your systems. And if you keep everything separate, that might be a lot easier to do

Speaker 2: A couple of notes on this, make sure you use maybe like an is initialization vector so that um the uh the same key elect data won't be revealed because you have none none none none and we can work out that this hash means none. Or and make sure that um you don't write something like this ever yourself. Um so this should also be something that's part of a framework. Um Using if you store the way you do it in the uh key like the user passwords do in Django, then that will help migrating data later uh if you change your algorithm or your method. Um Erasing personal data might be straightforward, but um you'll probably have problems with your link data or your backups, you've got one month to work that out.

Speaker 2: By separating maybe your backups. If you have a uh one backup for your account data and one backup for your non-personal data then you can maybe keep the non-personal data a bit longer. Or you can re-encrypt the other one in another way, but you can just maybe manage it a little bit better if you do that. The idea of crypto shredding before with the throwing away the key is the same idea if you've encrypted the the account data on a per user basis, then you can just throw away the key. One other thing that the regulation brings that's new is, or in some jurisdictions, is preventing discrimination. uh based on special categories. And this um this is basically when you're having algorithms for like uh

Speaker 2: pricing your shoelaces or something. Um if you You can't include any of this information in your algorithm to decide who pays more or who has a legal effect Um another important word here is the word revealing because if I have uh maybe a date of birth and a postcode I might be able to identify a lot of people that way. Combining different forms of data can identify people in ways you might not have. So if you use that data, especially postcode data, if you use that you may well end up being discriminating against people. It's a very difficult thing to do properly, and we should be doing it properly, and we're learning about this at the conference. Uh and there are lots of people, lots of research happening.

Speaker 2: Um you will hear about bias in algorithms. Uh learn about it. If you're writing algorithms that make uh decisions for people and how much they pay or whether they get a loan or anything like that. learn about this stuff um and try to prevent it. It will make your algorithms better in any case because um you're you're looking at the what's actually um important instead of some other things Also note that gender and age is not included in the special categories as we saw before. So you're free to offer shoelaces more expensive expensively to uh one sex than the other. Um you will maybe run against other discrimination law in other uh aspects of the EU legislation, but in the GDPR you'll be fine. Um

Speaker 2: don't in don't forget intersectional. Um so if you have you may be sort of controlling your algorithms, you're testing them, you're auditing them. But if you're doing it for just each category specifically, you may miss that uh some people who live in two categories at once will then get discriminated against. You have to check these as well. And it's Not easy to do because there are lots of combinations. Ways to attack this, uh there are um Uh there's a there's a lot of work on this sort of thing, and I'd I'd encourage you to go and do about that. It's probably outside of the scope of this talk. Um but you can remove data points, you can um uh anonymize the data uh and uh there are ways of of addressing that that might be worth doing.

Speaker 2: It may slightly um not improve your algorithm. Uh but I think it's there is a bit of research showing that the uh the fairness when you increase the fairness you can get a lot of gains in fairness for a little price in um in in how good your algorithm works. It's a problem of of multiple optimization. You could maybe include it. If you ordered it, it's probably the best way to do this. because you're not allowed to collect special data categories without a very good reason. It may not be possible to be fair. It's it's a question you might have to ask. And I think we'll find out in the next few years how far we come with that. What's another thing that I won't go into too much detail about is the idea of explaining machine learning.

Speaker 2: This can be very difficult because there might be a right to explanation of an algorithm. So if some a user comes to you and says, tell me why you made this automated decision. You may have to be able to explain how that happened. If you're using machine learning, if you've got a a deep neural network, you have no idea what's going on. It's not going to be easy. There is research in this area. Look into it, it ex explainable machine learning. Um it's it's hard to say whether this right even exists to an explanation. It's early days yet. Well it hasn't even started yet. But it'll it'll clear up in the next few years I think and we'll we'll know what we need to do and whether it's part of it or not. It there are reasons I I won't go into the details that it

Speaker 2: might not actually exist because um Because it was removed explicitly from Article 22 and so on and so on. In Germany there's there's an also a translation of the law that says it has to be about the envisioned effects and so on and so on. Look into this so we can have a chat about it later if you're interested in that. What is interesting is maybe the idea of anonymization. Doing this is really hard and if you don't have any experience in anonymization don't try it alone without maybe getting into the research of this Basically it's asking a question, is re-identification reasonably likely? And the only person who can answer that is maybe you because the lawyers have no idea um whether this data can be combined in a way that uh might allow re-identification.

Speaker 2: Um One I mean uh one this can also be very helpful. If you're working on anonymous data, you're avoiding model overfit if you if you're building models for machine learning, um which means uh instead of um having one or two people in your s in your database um tell your model something that's wrong about uh about the world, you'll anonymize it and it'll be the information will be generalized. It's if you don't know things like the the K anonymity and and L diversity T closeness, uh find out about them or ask someone who does. I'm sure there are lots of people in this room who know how to do anonymization. Uh it's hard. Um It's I I just I I'll just leave it there

Speaker 2: because it's uh it's something you you really shouldn't attempt yourself if you don't know about it. Um finally there is the final thing of breach notification and this is something you have to know because um if you don't tell anyone uh about the email that you accidentally send all your users with the personal data or something then uh your organization will be liable. You have to tell somebody because uh within 72 hours it has to be registered at the uh local authority. Um You may have to also inform the relevant data subjects. And this can be very easily easy to trigger. It also means loss of data or anything that sort of makes the data poorer.

Speaker 2: If you send an email to the wrong person in CC or something like that, there can also be a data breach. A lot of innoculous things can actually turn out to be a data breach. Um finally what I guess for for Django, if I could think of any sort of random tips that I could stick at the end of the presentation, these will be it. Um maybe set up a proxy for external services to protect your users. If they're connecting directly to Google Fonts. then Google is suddenly getting their IP address and the user didn't know about that. So you can either get their consent before you do that or you can set up a proxy so that the user is just connecting to you. I had more on that. But we'll continue. What can Django do?

Speaker 2: I guess we'll find out in the next few years. But maybe allow, enable, um, facilitate. safe per user encryption. Maybe include a lot of documentation that's specific to GDPR to help people comply using Django. Um and maybe even to tag personal data from the from the model uh onwards, um where you can say in the model that these fields uh are storing personal data or in combination with these other fields this might be And so that we can track it through the system, so that we can handle it in a view, in an admin, and say that these users can't see personal data, or that um this purpose has been attached to this data and um th A view can then check uh am I allowed to use this data because I want to use it for this purpose.

Speaker 2: Um maybe it's something for the sprints if people are keen and eager to to get into this sort of stuff. Um but I think in the end um It's going to be interesting to see uh what happens in the next few years. What we're experiencing now is uh more probably the more painful part of it, is the the transition. But I I I think in a few years everyone will really know what we have to do. Everyone will know um how we're supposed to work, everyone will know um what we can and can't do. It'll be get easier, it'll get more fun and we'll all have access to our data. Um so thank you for for your time. Um if you have any questions I'm happy to take them, but I'm I'm not gonna answer questions on compliance specifically for you if you have things like that. But uh general philosophical questions or clarifications are good.

Speaker 2: Cheers.

Speaker 1: Thank you very much. And we have a first question here at the microphone one.

Speaker 3: Yeah, thank you. Um and I say this with American legal training, so things are a little different. Um it seems that one of the hardest pieces to implement, just thinking off the top of my head, is the sort of Decline for processing where a user wants to remain in your system, but it just seems like there's so many code paths that that can go down and stuff like that. Can you decline to implement that right and just say, you know what, we're not giving you that ability and you can choose to erase or not, but we're not gonna allow you to decline processing?

Speaker 2: Yeah, it's a good question to maybe like I I think Um you can just say, well, I if you erase them, you're no longer processing personal data, so you're no longer um uh attached to the GDPR. It doesn't apply to you anymore.

Speaker 3: Right. I I guess m uh a deeper question is does that maybe um impact poorly with other rights of of use or or something like that, or you know, contractual rights that they had to use your system?

Speaker 2: Probably. Yeah. And it means you have to look at your contracts. To make sure that uh these scenarios are covered. Okay. But not you personally, the lawyers.

Speaker 1: Okay, thank you. The other questions from the back microphone?

Speaker 4: Yes, um at some point you uh mentioned tagging personal data. Uh there are some data which are borderline For example, if I do business with you, assuming you're a freelancer, I will have your name as a business partner. I cannot delete that because I need it for legal reasons for my accountants. Yep I also have your phone number, but you didn't give me your business phone your number because you don't have one. You gave me your personal phone number. So Uh do you have any insight on how to involve these kind of things?

Speaker 2: Uh not entirely but there are uh lots of exemptions for for business contracts and and things like that. When you do get into the borderline data, um then uh it's a case by case basis and I think a lot of lawyers will often give you answers. There's there's no yes or no for a lot of things Sometimes there is, but sometimes it's just we d I I don't know, maybe. Um and if you then get into the corner cases that you can argue for this or you could argue for that. But there are exemptions that help you continue to do business with your freelancers. And if you look through those, you'll probably be covered by most of them and you'll be fine. But often You can do this on a case-by-case basis anyway. If someone asks you please delete my phone number, you can delete their phone number pretty easily.

Speaker 4: Okay, thank you.

Speaker 1: Okay, another question from that microphone.

Speaker 5: Hi. That was really good, thanks. Sounds a little bit flippant, but um it said about the on your earlier slides you would it And I was wondering what is the definition between a natural person and a natural person.

Speaker 2: Um a human, I guess, is a natural person. Uh a corporate body isn't is Could be a legal person, but it's it's not a human, so it's not uh so if I have personal data on a company, it's not personal data. It's yeah.

Speaker 1: Okay, there's another question at the microphone at the back. Yes.

Speaker 6: Where do you know all this stuff from? In the internet there's a lot of stuff. And everybody says something different and how to know which parts are correct and which ones to follow and

Speaker 2: Um okay, so first you could read the uh legislation, it's not too difficult. Um I have a copy back here if you want to look at it. Um and uh secondly there there are a few uh lawyer uh um uh legal companies that provide guides to it and you can trust them if you trust them. Um and there are a few opinions. Um and in in reality a lot of you don't really know. There are some uh legal articles from scholars that argue in both directions for an idea is like the the right to explanation. Um and they're good arguments both of them, like I sort of agree with both of them and we won't know. Um we'll find out in the next couple of years if if people bring in cases to to uh to judges and we'll find out to courts. Um but

Speaker 2: Other than that, um you never really know uh a definitive answer to a lot of things. Um most of the time it's reasonably kick-cut and it's a risk uh analysis situation. Um Is it worth doing that or what are the consequences of doing this? And I imagine at the beginning the authorities probably aren't going to come down too hard on smaller companies. And they probably won't come down hard on the larger companies with good lobbyists either. But there is also a right to sue. Uh so a user can uh say, I don't like what you're doing with my data and and take you to court. And who knows what will happen there. I don't I've no idea. We'll find out. It's it'll be interesting times, I guess.

Speaker 1: Okay. Another question in the front.

Speaker 7: Um is there any provision in the law to uh prevent end users from harassing a company like um asking every other month for the new data they collected or so? I mean in some extent um the the recovery of the data or especially cleaning backups is um is actual work, be it in implementation or even if it's a manual task for smaller companies Um which costs money, which is not something I can easily argue.

Speaker 2: There was previously in a lot of implementations of the law, so other countries had that. Um and they would allow maybe the first couple but if you have too many then uh that would be y you could charge a fee for it or something, but Um it's now free and should be automated. Um and I think the emphasis is on that you build systems that do this for the user automatically and you don't have to um do it for every individual user. Um I'm not sure there are probably definitely ways you can harass. Um if you uh look for very specific things that uh companies might not do. I don't know if that's uh uh I haven't

Speaker 1: Okay, if we don't have any other questions, thank you very much Will for this amazing talk and for taking so many questions.