Are auto-generated identifiers PII if they cannot be linked to an identity? The reason for this post is to express a contradiction that seems to be widespread in some places on the internet. I'm not a lawyer, I'm a software developer doing my best to comply with the GDPR and the ePrivacy Directive. If I had enough money I would hire a professional to do it for me, but for now that is not the case so it is up to me to do it. I don't know if what I am going to expose is true, it is the result of my investigations, so I invite anyone to contradict me and tell me what I am mistaken. The object of my reasoning is the auto-generated unique identifiers on the client device in analytics tools and similar (Google Analytics...etc.). These identifiers are often linked to real identities, with which I think it is evident that they are personal data; however in recent years there has been a wave of analytics services claiming to respect privacy that use auto-generated identifiers not linked to any identity. Some of these services claim that they can be used without a cookie banner as mandated by the ePrivacy Directive. These services have evolved and now some of them have eliminated the need for this identifier. The reason is the criticism of some users who use the fact that if you can differentiate one user from another, it is personal data and must be subject to prior approval by the end-user. Instead, some of these tools use fingerprinting methodologies that consist of mixing various data (which by themselves would not constitute personal information) in order to differentiate some users from others, this being a way to technically 'solve' the legal trouble by not creating the auto-generated identifiers. Leaving aside the debate that may arise here about whether or not fingerprinting is personal information (I do not intend to delve into it in this thread), let's assume the following scenario: Let's imagine that I have a privacy-friendly application in which I use auto-generated identifiers on the end client's device to be able to differentiate one user from another. This application does not collect any other kind of personal data, only short bits of information to know the language of my users, if a page has been viewed, etc. Let's imagine that I have complied with all the legal obligations about informing and obtaining consent from this user, and this user has accepted it. Now let's imagine that this user wants all their collected personal information to be deleted, as dictated by the GDPR. At this point, I couldn't fulfill his/her request. The reason is that although these unique identifiers are stored in my database, they only serve to differentiate one user from another, I cannot know to which real person they belong. With which I imagine (and I repeat, I do not know about these issues, what I am going to say is pure conjecture) that I would have to add a form in my application so that the user could copy that identifier and then pass it to me so that I can eliminate all data associated with it. At this point is where, in my inexperienced opinion, a contradiction occurs: I cannot by myself, through the data I have collected, identify this person. I need him or her to proactively tell me who they are in my system... so, how can an auto-generated identifier be considered personal information if, on its own, it's not possible to identify a real person? Of course in this example let's imagine that I really can't identify the user, that I have not collected any other personal information of any kind that together with the identifier allows me to identify him/her. This is so far the contradiction that I do not understand. I repeat that I am not a lawyer nor am I versed in the matter, so I would be very grateful if someone could get me out of my mistake and point out where the fault is in my reasoning.
You are having difficulty understanding the GDPR because you have an improperly narrow idea of “identification”. In contrast, the GDPR uses an extremely broad definition. In Art 4(1), personal data is defined as any information relating to an identified or identifiable natural person (‘data subject’); an 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 It is worth noting that your “auto-generated identifier” would quite clearly be “an identifier such as … an identification number” and/or “an online identifier”. It is also worth noting that indirect identification is still identification. Recital 26 explains the concept of identifiability in more detail: ³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. Key observations: Singling out a data subject already counts as identification, meaning that it isn't necessary to infer their real-world identity! The data subject is still identifiable if you can only identify them with additional data. The data subject is still identifiable if identification can be performed by others. The main limit to this concept is the “means reasonably likely to be used” criterion: as long as there is a reasonable scenario in which the data subject could be likely identified, they are identifiable. Identifiability does not depend on your current intentions or policies, only on objective factors. As an illustration of these points, consider the Breyer case (C-582/14). The pre-GDPR Data Protection Directive had an essentially equivalent concept of identification, except for the “singling out” factor. The CJEU was asked to decide whether this meant that IP addresses collected in a server log file of some website were personal data. Quite clearly, such IP addresses do not directly identify a person, unless you happen to be the data subject's ISP. But here the CJEU constructed a reasonably likely scenario that shows that IP addresses will typically be personal data even without the “singling out” criterion: in the event of cybercrime, the website operator would reasonably provide the IP addresses of visitors to the police for investigation, and they in turn would have the means to get a subpoena/court order to get the ISP to provide the information necessary for identification. What does this mean for your identifiers? These identifiers and any linked information relate to a particular user, the data subject. Thus, these identifiers and any linked information are personal data if the user is identifiable. Since these identifiers allow you to single out a particular data subject, i.e. allow you to distinguish one user from another, the users are identifiable within the meaning of Recital 26 GDPR. Additionally, identification is possible if it is performed by someone other than you – such as the user themselves. How does this mesh with data subject rights? You correctly point out the problem that when a user contacts you to exercise their data subject rights, you wouldn't be able to find their records. But Art 11 GDPR prepares for this: If your processing activities do not require identification, then you are not required to acquire or maintain additional information just for the purpose of complying with data subject requests (this encourages data minimization). If you can demonstrate that you are unable to fulfill a data subject request because you can't identify the data subject, then the data subject rights in Art 15 to 20 do not apply. These are the rights to access, rectification, erasure, restriction, and data portability. Unaffected are the right to information, the right to object, and rights related to profiling. However, you still have to comply if the data subject provides additional information enabling their identification. You have intuitively grasped the correct solution: you can provide a feature where the user can see their automatically generated user identifier. Then, they can provide this ID to you when invoking their data subject rights. A note on privacy-preserving analytics. When it comes to analytics, the GDPR and ePrivacy issues must be looked at separately. From a GDPR perspective, any client IDs or other identifiers are likely to be personal data, regardless of how they are stored or created. But the GDPR does not necessarily require that the user gives consent to such analytics – a legitimate interest (opt out) solution might also work. The ePrivacy Directive does not care about whether such IDs or fingerprints are personal data, only about how they are created and stored. Any access or storage to information on the end user's device is only permissible with consent, unless the access or storage is strictly necessary for a service explicitly requested by the user. Analytics are not strictly necessary from the user's perspective. Thus, while cookies or LocalStorage can be freely used to store user preferences on a site, accessing/storing cookies for analytics purposes, or accessing information for fingerprinting purposes through JavaScript APIs, is only permissible with consent. Compare also the WP29 opinion 9/2014 on fingerprinting (PDF). This leads me to conclude that many so-called GDPR-compliant or cookie-less analytics fail to meet ePrivacy obligations if they include a client-side component such as the typical JavaScript tag without asking for consent, but that they might be OK if they rely on purely server-side data collection. Regardless of how user IDs or fingerprints would be created, those IDs and any linked data would still be personal data though, so that GDPR would still apply. A hash of an identifier is still an identifier and therefore personal data, and at the very least still enables indirect identification. (WhatsApp attempted a “lossy hashing” argument while appealing its fine, but didn't convince many supervisory authorities.)
The GDPR has a fairly broad concept of what it means for a data subject to be identifiable. The details are given 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. The good news is that this mandates a risk-based approach to identifiability. You don't have to prevent re-identification with absolute certainty, but you must make sure that re-identification is not “reasonably likely”. The bad news is that “identify” does not just mean “figuring out the real-world identity of the data subject”, but also “being able to single out the data subject”. Hashes of personal data are still personal data. The hashed password still allows you to single out data subject, since the hash now serves as an identifier that links multiple records. Equivalently, a random ID would serve as an identifier. Depending on the information in the linked records, this could reasonably likely also allow linking to a real-world identity. I'll also point out that the GDPR explicitly notes that “online identifiers … such as internet protocol addresses, cookie identifiers or other identifiers” enable profiling and identification, and are thus a kind of personal data. Note that it seems you have a user database that includes a password hash. This database includes rich links between the password hash and other, more directly identifying, data. Alternatively, consider that the software that collects tracking information along with this tracking identifier would also receive other information about the data subject that could allow re-identification, such as the data subject's current IP address. It would be reasonably likely that such additional information could be used to identify or single out the data subject. For this analysis, it is irrelevant whether you have any intention of singling out users – it only matters whether, under an objective analysis, the relevant means to do so exist. Related: EDPB thinks hashed phone numbers are personal data. There has been recent debate by regulatory bodies on the question whether hashed phone numbers are personal data. This debate was published by the EDPB binding decision regarding the Irish DPC's fine against WhatsApp, which uses hashed telephone numbers to intersect user's address books. The question in the context of the fine was whether this represents processing of personal data of users who are not WhatsApp users themselves. Originally, the Irish DPC argued that such hashes were not personal data. However, the German, French, Portuguese, and Dutch supervisory authorities pointed out that the specific hashing approach used by WhatsApp does not provide anonymization, for example because there still is contextual information (such as the user's social graph) that would allow indirect identification (and because their hashing was pretty weak and reversible with reasonable effort). Such hashing would only be pseudonymization, not anonymization. The Hungarian supervisory authority makes the argument that WhatsApp could always re-create the hash from the original data, thus permitting re-identification of the hash. This is in line with my above argument that the hash allows singling out. Again, the hash should be considered pseudonymous, not anonymous. The EDPB upheld all these objections against the Irish interpretation as “relevant and reasoned”, and largely agreed with their merits. Some parts of the resulting analysis are specific to issues around phone numbers, in particular that there are comparatively few phone numbers. However, a recurring point is that the hashed data cannot be viewed in isolation. It must be viewed in the context of how it is created and used, and in the context of other data that the data controller has. Conclusion It is possible that in some cases the hash could serve as an anonymous token. But this would require careful analysis about how the hash is created and used, and about what other data you have available and could potentially link or correlate with this token. Unless you are extremely sure that there are no means that could be reasonably likely used to perform re-identification or singling out, you should consider such tokens to be pseudonymous data. Pseudonymization is a great security measure, but such data is still personal data. I suggest reading the WP29 opinion 05/2014 on Anonymization Techniques (WP216) (PDF link). It predates the GDPR and is slightly outdated in both legal and technical matters, but still contains highly relevant guidance on the matter of proper anonymization in the European data protection context. Aside from identifiability issues, I am concerned about using the password (or derived hashes) for anything other than authentication. Even in hashed form, this is fairly sensitive data. In most cases where you would use a password hash, you can likely use a random number instead.
From the GDPR's definitions: ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an 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; This blurred image would be &quot;information relating to an identified ... natural person (‘data subject’).&quot; It does not matter whether the person can be identified using the information in question. Therefore, the answer to your question Under GDPR, does blurhash of a profile picture count as personal data is yes.
Belgium enacted an implementing law, the Act of 30th July 2018 on the protection of natural persons with regard to the processing of personal data. This, along with the GDPR, are the key legislative references that relate to your question. On 5th September 2017 the ECHR judged that it "considers that States should ensure that, when an employer takes measures to monitor employees' communications, these measures are accompanied by adequate and sufficient safeguards against abuse". This case set a precedent relevant to employee monitoring in Belgium. This is most definitely a data protection or privacy law matter and the DPO should be consulted. If they have to do research, that shouldn't be your concern as that is their job. The company must support the DPO in what they need to do that job, as such is literally written into the GDPR. Furthermore, in this case it would, by my evaluation, be necessary to conduct a Data Protection Impact Assessment (DPIA) for the monitoring activity, and if one has been done, it should document the recommendations and requirements or what is already in place. You as an individual may also ask a question of the Data Protection Authority: (NL) https://www.gegevensbeschermingsautoriteit.be/verzoek-klacht-indienen (FR) https://www.autoriteprotectiondonnees.be/introduire-une-requete-une-plainte You might ask them about your position and liability as an employee, but I would be more concerned, if I were you, with verifying that your actions are above board rather than trying to cover your ass just in case they aren't. Do the right thing, even if that means questioning the direction you've been given. AD logons still identify the person logging on, and may include source IP, which is specifically listed in the GDPR as within the scope of 'personal data'. So while there may be a legitimate need to process such data, it needs to be gone about in the right way. Actions taken by an employee are taken by the organisation in terms of processing personal data, so whatever you are asked or ordered to do, will be done by the company. If you are being offered no legal justification for doing so, you might document the direction you are given and question it respectfully, pointing out that if found to be unlawful, it is the company that would be in trouble, all while knowing that should there be for example an unfair dismissal, you have a record of who asked you to do what, how you challenged or questioned it, and what was the outcome.
In the general case, it seems unlikely, based on the wording (which is convoluted). In certain cases, if the president of Russia posts "My name is Vladimir Putin", that post is personal data. On the other hand, you might, based on my writing, conclude that I am from the US, and you might even conclude that I'm in Washington state, but that doesn't distinguish me from 7.5 million others, so on those grounds that is not personal data. Eventually, though, you might identify me specifically from other things that I may have said on SE. The definition depends on two parts. First, personal data is "information relating to an identified or identifiable natural person". Any "information" provided by a natural person is "related to" that person (as is any "information" that is about such a person). The second part defines "identifiable natural person", that is, who is an "identifiable person"? Every person can, in principle, be identified by reference to some label or description of fact about them, so every person is an identifiable person, under this definition. This means that every piece of text that refers to an individual (not even text which can identify the person) is "personal data". Obviously, any individual can be uniquely identified by some collection of identifiers; the problem is that the wording of the law does not explicitly say "using that supposed personal data". If I mention that I have a relative named Knudt, that would technically be personal data: I've given information that relates to a person, though you have no idea (and could not possibly figure out) who that person is. Another term that the regulation defines and uses in a few places is "pseudonymization", which is defined as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person The point of interest here is that this says that "personal data" which cannot be attributed to an individual is, nevertheless, still personal data. I think the most important part of the regulation is art. 6, which defines lawfulness of processing, especially para 4., which allows consideration to be given to safeguards such as pseudonymization.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
This question shows a misconception of GDPR. GDPR creates an obligation not just towards the data subject but also towards the authorities of the relevant state(s). The data subject cannot waive your responsibility to safeguard data, document internal processes, etc. GDPR is not a blanket ban on the handling of personally identifying information (PII). Informed consent is one of the ways to get permission to process and store this data. If your data subjects are prepared to give your sweeping permissions, ask for consent (informed, revocable, etc.), document the consent, and go from there. The data subject does not get to decide what classification data falls under. If you collect, say, medical data, then you are subject to increased restrictions and safeguards.
The university has a legal obligation to collect certain data from attendees, including employees an visitors. It has decided to keep these records in digital form, and offers a smartphone app as a convenience. The university has outsourced the data processing activity to a third party. This is perfectly legal under the GDPR, if that third party is contractually bound to only process the data as instructed, and not for their own purposes. Whereas the university acts as a data controller (Verantwortlicher), the third party would be a data processor (Auftragsverarbeiter). I have some doubts though whether an app or a website is indeed the solution that offers the best data protection, especially taking into account the GDPR's data minimization principle. Requiring updates when entering or leaving any room is potentially excessive. Given the sensitivity of the data, the university should have performed a data protection impact assessment to weigh the consequences of this measure. At least for employees, the measure would likely have to be approved by the union (Personalrat) as well.