Is throw-away-the-key-encryption allowed under GDPR? Article 15 of the GDPR says: The data subject shall have the right to obtain [...] personal data [if it is being "processed"] Article 4 says that "processing" includes storage. Therefore, all stored personal data should be available upon request. Then does GDPR disallow the following scenario? You give me your personal data. I encrypt your personal data using a random encryption key. I store the encrypted data and assign it a random ID for reference. I give you copies of the encryption key and the ID and throw away my copies. You later provide the ID and encryption key to me and ask me to decrypt your data and perform some work with it. Note a few things: Nothing about the encrypted data, encryption keys, IDs, work performed, logs, etc leaves any information which correlates to you. Only your unencrypted personal data does. Your personal data still exists the whole time--I'm storing it in encrypted form (has it been anonymized?). Your personal data is readily available, if you give me the correct ID and encryption key. Importantly, I'll never be able to satisfy your request for all your stored personal data. It's technically impossible since I lack anything which correlates it to you, and I don't have any encryption keys. I would only be able to satisfy the request if you gave me all encryption keys and IDs that I have ever sent you. A concrete example: In order to sign into a website you must have a trusted email address. Email addresses take the form of firstname.lastname@example.com, thus they are personal data. You sign in by providing this personal data and clicking a button. Clicking the button stores your encrypted personal data according to the scheme above and then emails you a link containing the reference ID and encryption key. You establish trust by clicking the link, sending the website everything it needs to find and decrypt your personal data. Then the website takes action on your personal data, signing you in. Incidentally, the encrypted personal data is single-use and expires, so it gets deleted after you are signed in or if it gets too old. I realize the goals of this example could be accomplished a different way. But I hope it helps make the scenario clear.
TL;DR In theory there's nothing wrong with your method, it's just a way to authenticate the user, and without authentication a user has no right to request anything anyway. But in practice it looks like your method doesn't have a way to deal with situations where users lose or forget their authentication data and want to be able to recover their account. Failing to deal with that in a modern system might be considered an unacceptable bad practice and so be against the GDPR principles of security and privacy by design. EXTENDED VERSION I might be wrong or not understand the question correctly, but I don't see how this is different from many other common cases where encryption is not involved. Think about it, you aren't able to give the user their own personal data unless they provide the ID and encryption keys. How is this significantly different from the fact you aren't able to (or rather you should not) show a user their own data unless they provide their own username and password, or they convincingly authenticate themselves in any way? Just like you can't ask Facebook to show you all the data collected about Donald Trump only by claiming you are Donald Trump, you can't be required to give a user their own data unless they provide the encryption key. It can be seen as your way to authenticate users (among other things). Edited: multiple IDs/keys I didn't understand your method involved multiple IDs and keys. In theory, the situation is still the same, only with multiple pieces of data for authentication, like the user had to remember multiple usernames and passwords. Failing to provide all IDs and all keys will result in a partial authentication. But with such an approach a potential problem becomes more evident: your authentication scheme might be against the GDPR principles of "security and privacy by design and by default". Basically, your methods might be considered bad practice because they fail to deal with the common issue of lost or forgotten passwords. If a user tells you they have lost a USB drive containing all their IDs and keys and they don't have them anymore, what do you do? You can't delete their data because you aren't able to know what their data is, without another way of authenticating. And their data is now at risk, because somebody else might have their IDs and keys. If you had an email address associated with all the user's IDs and data, then you might be able to confirm their identity (for example sending an email with a link) and delete all their data. As you see, things can get pretty complicated, it all depends on the details of your implementation, and just adding or removing one detail might change the whole scenario.
Your data is not anonymous since from the picture of the face the individual can be identified. It would be anonymous, if the face was blurred and other possible identifiable information was removed. Of course, that would defeat your purpose. Please note that, in any case, Anonymization Techniques are, themselves, a type of personal data processing that requires a legal ground, and achieving real anonymization is not a trivial matter (see Article 29 Working Party's opinion 0829/14/EN WP216 on the subject). 1. The face of a person includes biometric information, which is defined in article 4 (14) among other types of personal information regulated by the GDPR as: "personal data resulting from specific technical processing relating to the physical, physio­logical or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data". A facial recognition software's purpose is exactly to perform a specific technical processing based on the facial features of the persons, to achieve a unique identification of a person based on these biometric features. Article 9 of the GDPR includes biometric data among the types of prohibited processing, unless one of the exceptions in § 2 applies. There are 10 types of exceptions among which: consent of the person, employment context, personal data made public by the person, scientific or historical research,... (each exception having its own conditions). You should check that you comply with one of these exceptions stated in article 9 § 2, if your application is about using facial images for unique identification of a person based on these biometric features. 2. In turn, if your processing is not about unique identification of a person based on these biometric features, but only about emotions recognition (which you briefly mentioned at the beginning of your post), it could be considered as not falling under the requirements of Article 9. That would still be a processing of personal information, but it would fall under the normal article 6 requirements.
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
Neither the GDPR, nor the CCPA, nor any other data protection law that I am aware of, requires that when information is deleted on request, that similar information not be collected and stored in future. Under the GDPR Article 6 there would have to be a lawful basis for any processing, including storage, assuming that the GDPR applies to the directory in question. There could be a claim that such processing was lawful under article 6(e) &quot;performance of a task carried out in the public interest&quot;. I do not know if any such claim has been adjudicated. Thus there is no need to hold a database of previously erased records to determine if a new record should be blocked as &quot;previously deleted&quot;. The Wikimedia Foundation, which runs Wikipedia, I believe takes the position that the GDPR does not apply to Wikipedia, I am not sure of their detailed arguments. But surely articles on well-known people, such as a former US president, would be covered under the same provisions as would cover news reports and historical books about such a person. Perhaps that would also come under article 6(e)
There’s no definitive list of what is or isn’t personal data, so it all comes down to properly interpreting the GDPR’s definition: ‘[P]ersonal data’ means any information relating to an identified or identifiable natural person (‘data subject’). — Article 4(1) In other words, any information that is clearly about a particular person. But just how broadly does this apply? The GDPR clarifies: [A]n identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. — Article 4(1) This means that because you say that coordinates and anticheat logs are linked to the cheaters ingame username and unique id, if there is a record of who that username and/or unique id belongs to, even if it is just an IP or email address, it is considered personal data because the information relates to an identifiable natural person. Personal data includes any data which can be linked to information where a person can be identified From CommentsIf the online username and unique id is not linked to the actual human (no stored real name, no home address, no IP), can the natural person actually be identified? The records and anticheat logs are linked to the unique id and username, however the unique id and username are (from my POV) not actually linked to the real human Only you can answer that question as it stands because we have no access to your data. From what you have told us, even though the coordinates and anticheat logs are linked to the cheaters ingame username and unique id, that alone doesn’t fall under the GDPR’s scope of personal data, as, in all likelihood, the usename and unique id could relate to anyone in the world. The issue comes if elsewhere you have a record of the person's name, IP, date of birth etc. which when combined with the anticheat logs could link that data to identifiable people. You might think that someone’s name is always personal data, but it’s not that simple, as the UK’s Information Commissioner’s Office document what is personal data (PDF) explains: “By itself the name John Smith may not always be personal data because there are many individuals with that name. However, where the name is combined with other information (such as an address, a place of work, or a telephone number) this will usually be sufficient to clearly identify one individual.” Note: A name which is much less common could be personal data as the likelihood of it relating to others deminishes. John Smith is a common name all over the UK, but what about a particular polish/czech/hungarian/french.... name (let's say) living in Nottingham, UK? What is the likelihood of another person of the same name in Nottingham, UK? Add a middle name or double barrelled surname, and it becomes even more likely that it is personal data. If you’re unsure whether the information you store is personal data or not, it’s best to err on the side of caution. This means making sure data is secure, reducing the amount of data you store, collecting only as much data as necessary to complete your processing activities, keeping data for only as long as it meets its purpose, and ensuring only authorised people are able to access the data.
I agree with Ben that there are many exemptions to the right to be forgotten. For example if messages are removed from a mailing list archive, the replies to deleted messages will become useless. That would impact the right of freedom of expression and information of those authors. That is one of the exemptions to the right to be forgotten. So there is no right to delete complete messages. Replacing references to names and email addresses, is a very good solution. It must not be possible to de-anomize the data. So having anon-20190213-123@example.org, it must not be possible to get back A. Person &lt;a.person@example.org&gt;. Sure, everyone who received a copy of those messages can find that message in their own archive, and see the author that way. But that is because they simply have a copy of the full archive. The right to be forgotten is independent of someone else having the same information you request to delete. For example google removes search results in its index, even though the same information can still be found on the original website. To fully exercise the right to be forgotten, you have to make a request to everyone who has that data. In Austria there is a recent case (ECLI:AT:DSB:2018:DSB.D123.270.0009.DSB.2018) (available only in German) where someone's data was anonymized after asserting his &quot;right to be forgotten&quot;. He did not agree and wanted his data to be fully deleted, so he filed a complaint at the Austrian DPA. The DPA denied his request. I have tried to make a translation of the relevant part of the judgment, note that many references are to other Austrian judgments or books (where I listed the ISBN instead). D.1 The binding part of the GDPR does not contain the term &quot;anonymisation&quot;. Only recital 26 states that the GDPR does not apply to anonymous data. D.2 The term &quot;erasure of personal data&quot; as used in Art. 17 is neither found in the binding part nor in the recitals. In Art. 4(2) erasure and destruction are listed as alternative forms of processing which are not necessary identical. This means that erasure does not necessarily requires final destruction. (cf. K121.375/0012-DSK/2008, with regard to Directive 95/46/EC, where also a distinction was made between erasure and destruction; cf. ISBN 978-3-406-72006-2). Such a differentiation also results from the case-law of the Constitutional Court (cf. VfSlg. 19.937/2014). Therefore, the person in charge is entitled to make a choice with regard to the means - i.e. the manner in which the data is deleted - (cf. again ISBN 978-3-406-72006-2, according to which reference is made to the destruction of keys or other decryption devices without the removal of the data itself; cf. in this sense also ISBN 978-3-406-71932-5, which refers to the impossibility of perceiving the information previously embodied in the data to be deleted; cf. also ISBN 978-3-406-72007-9, according to which deletion is to be understood as any kind of conceilment of stored personal data; cf. also Warter, Dako 2/2018, 39 [40], according to which the result of the deletion action is decisive). The removal of the personal reference from personal data (&quot;anonymisation&quot;) can thus in principle be a possible means of deletion within the meaning of Art. 4(2) in conjunction with Art. 17(1) GDPR. However, it must be ensured that neither the person responsible himself nor a third party can restore a personal reference without disproportionate effort (cf. RS0125838, according to which it is not sufficient to merely change the data organisation in such a way that &quot;targeted access&quot; is not possible any more; cf. also the judgment of the CJEU of 19 October 2016, C-582/14, 45 ff.). Only if the person responsible aggregates the data in a way that no data can be identified, can the resulting data stock be described as anonymous (i.e. without personal reference) (see Opinion 05/2014 on Anonymisation Techniques of the former Art. 29 Data Protection Working Party, WP216, p. 10). The Administrative Court has also ruled - with regard to the comparable legal situation under the DSG 2000 - that a redaction (blacking out), for example, can be regarded as a form of deletion. By making the name of the data subject and all other data relating to him or her unrecognisable, his or her request for deletion is complied with (cf. the decision of 23 November 2009, 2008/05/0079). So anonymisation is sufficient to comply with a right to be forgotten request.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.