GDPR: Is only a birthday personal identifiable information? I wonder if only a birthday is seen as personal identifiable information according to the GDPR, so no usernames, passwords, emails, phone numbers are present in the system. Literally only a birthdate. And if someone can answer this it would be great if you could link the source as well since I can't seem to find this.
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.
You quoted the definition of personal data from Art 4(1) GDPR. This definition of identifiability is further explained in Recital 26: […] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. […] If the user ID is unique, then the hashed user ID will be unique as well. Thus, the hashed ID will enable “singling out”, and would still count as identifying in the sense of the GDPR. You also claim that there's no way to reverse the hash. This is not quite correct. Assuming that the hash function itself is secure, then the only way to crack the hash is to brute-force the input. The difficulty of brute-forcing depends only on the entropy of the input data, not on the size of the output hash. It is thus comparatively easy to crack hashes of short low-entropy strings like sequential integer user IDs, IPv4 addresses, or weak passwords. In contrast, it would be difficult to crack long random user IDs, such as UUID version 4 identifiers created from a cryptographically secure RNG (CSPRNG). Even if the hashes can't be cracked, they are not anonymous – you can link them to the original user ID, after all. The GDPR only considers data anonymized if there are no “reasonably likely” means to re-identify the data subject. If this de-identification is reversible, it's called pseudonymization instead. If storage allows, a better technique to generate pseudonymous IDs is to create a table that maps the true ID to a CSPRNG-random ID. Unlike a hash, the random ID cannot leak extra information about the original ID. This pseudonymization technique could perhaps also be turned into irreversible anonymization by deleting the ID mapping, assuming that no “singling out” can happen. Pseudonymization is a very good security measure. It is explicitly mandated whenever appropriate in Art 32 GDPR. So you should probably use it. It's just that GDPR continues to fully apply to processing of the pseudonymized data. Since the pseudonymized data is the data subject's personal data, you may be required to delete it when receiving an Art 17 request for erasure. You may also be required to forward the request to others with whom you shared the data. However, the right to erasure has many conditions and exceptions. If you actually need to keep the data for a particular purpose, chances are good that you can keep it.
The GDPR doesn't generally distinguish public from non-public personal data. If you have a good reason to contact the professor, do send them an email. GDPR does not prevent this. If you're sending this email for “purely personal or household purposes”, then GDPR doesn't apply anyway. There are rules in the ePrivacy Directive against unsolicited emails, but these specifically relate to emails for direct marketing purposes. A company is not allowed to send out spam marketing, regardless of whether they obtained the email address from a public data source. Companies can send email marketing to their own existing customers, or to people who have given consent. Consent is defined in a fairly restrictive way (as a specific, informed, freely given, and unambiguous indication of the data subject's wishes), so that mere publication of an email address cannot be interpreted as consent to receive marketing from a particular company.
It’s personal data ... but why do you think you can change it for free? It’s clearly personal data because it can be demonstrably linked to you, both within and outside Blizzard’s database. Presumably, you consented Blizzard having it or they have some other legitimate basis for having it. So far, this is all GDPR compliant. You have a right to be forgotten, so you can ask Blizzard to delete your account. You have a right to confirm the information is correct. And that’s it. They can charge you a fee to change your user name just like your government can charge you a fee to change your real name.
"1) Can I use an pre checked tick box under GDPR?" Nope. "Silence, pre-ticked boxes or inactivity should not therefore constitute consent." (Recital 32) "2) Since GDPR also requires the data collector to ensure that the user is not under the age of 13 so I am planning to ask the users age only for that region i.e. EU Region. Now will simply mentioning that "By continuing you acknowledge that you are above 13 years" will work or will I have to ask the users age?" You have to require some affirmative action. Implicit consent (just continuing) is not acceptable (ibid.) "3) The GDPR requires the data collector to have a proof of the users consent. Now what kind of proof will be required for my App? I am ensuring that the user cannot move forward without providing the consent (only once) is that sufficient as a proof or is any other proof required?" If you are collecting data about the user, you should record the time and date consent was given as part of the user profile. If you are not collecting data about the user (this is only done by third party services such as Google analytics etc.) and there are no user profile, then preventing the user from using the app will have to do. The GDPR also requires data-minimization, and creating a user profile to record consent when no user profile is otherwise required will violate data-minimization-principles.
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.
Since the Steam ID contains or may contain enough information for it to be possible to link your account to you as a physical person, it would definitely be considered "personal data" according to Article 4 of the GDPR. However, by agreeing to the DOTA2 terms of service, you have given consent for them to show your information to other players (or at least that is included in most terms of service I have read for other games. I have not read the one for DOTA2 specifically). Replays are an interesting corner case. If download of replays are only possible for other players or if the wording of the ToS says that you consent to displaying your user ID to anybody, that would mean that they would have covered their bases. As long as they comply with other parts of GDPR, like "the right to erasure" (Article 17) that is. If the API is accessible to anyone and not covered by the ToS you might have a case. If you only want to remove the traceability between you and the replays, you can always evoke Article 17 and delete your account.
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.