Are auto-generated identifiers PII if they cannot be linked to an identity?

Question

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:

1. 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.
2. 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.
3. 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.

Answer 1

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.)

Answer 2

If anyone could in any way use it to identify, it is PII

It's not a matter of practicability, it's one of possibility. If there is any way for the creator of the ID to correlate the ID or someone with access to it can correlate it to a person (or persona), then it is PII.

Answer 3

Not a new answer, but a concrete technical interpretation of the other answers:

If you have no way of identifying individual users, that's another way of saying your services are anonymous. That means no user login. No session state. No returning visitor cookies. Nothing.

That's a rare website or online service that works truly anonymously. Of course, if it is anonymous, you cannot show a user his or her history. There is no database table named "xyz_user" with a user ID (of any kind) as a primary key and, thus, no related tables. There is no user information to delete!

But, of course, GDPR does not require anonymity. Only that you adequately protect users' information, allow them to delete it and so forth. So choose one or the other: anonymous or identified.

Getting back to the OP: Since your application has identified users, a client supplied user identifier may help you protect the data internally, but it is not a GDPR requirement and is not a substitute for adequate data security (either in transit or at rest in your data centers).

Answer 4

I believe the way this is usually implemented in practice, namely through hash functions, also shows how to comply with the deletion request.

So some user comes to your website and you want to assign a new identifier to them. You take some personal info from them, apply a hash function to it and save the hash as your unique id. If you implemented this properly, you provide the algorithm to the user and their personal info never leaves their device, you only get the unique id back. By construction this is a one way procedure and you can't take the hash and reconstruct the personal information from it. So you store all these ids on your database and you have anonymized information and from this database alone you can't extract information about any specific individual.

But if one specific individual comes to you and requests that you delete their data (or just hand it to them) you are fine. You can use their personal info to compute the hash the same way this is done for a new user and then search for this hash in your database. That is the unique id you need to delete.

Answer 5

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.

ok like a serial number cookie.

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.

( If it's a small amount why not just store that information in the cookie instead, and store nothing about the user on your servers?)

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.

They will have to provide you with their identifier (perhaps by visiting a web page) so you respond with a link, they visit it, server side code uses their cookie to locate their data, their data is deleted, and their cookie set to expire immediately.