[anonymousiam]

I do not agree. The identity can be extended with some GUID and then hashed. The GUID and hash can be kept, but the identity discarded. Then the original identity is lost, but if encountered again, it will be known that it was previously seen.

[mindri0t]

>but if encountered again, it will be known that it was previously seen

But when you see it again you have personally identified the individual have you not? Doesn’t that by definition mean it is identifiable if you are able to determine the identity later?

This is something that advertisers/supermarket points schemes etc used to do when they didn’t have consent to share personal data, hash it and align it with what they already had so effectively they shared the subsets of interest anyway. I remember at university when some guys from yahoo sponsored a hack event, they literally gave a guest lecture boasting about doing this with Sainsbury’s to squeeze through a legal loophole back in 2013.

[dylan604]

That's the fun of thought experiments, the rabbit hole just keeps going.

If your original delete request was followed so that everything they knew about you was deleted, they would not be able to relink everything that GUID linked to. It should be gone now. However, if that hashed value lives in a BANNED_ACCOUNTS table, then all they have to do is create the hash, check the table, disallow new account. You can even do it in good faith by not storing any of the new info rather than storing it and forcing a new delete request.

[bentcorner]

It's not clear to me how from a privacy perspective that's different from the hash of an id.

[anonymousiam]

It's different because a hash of the ID can be used by anyone who knows the hashing algorithm. If the ID is combined with a UUID/GUID and the UUID/GUID is kept secret/isolated by the entity doing verification, then nobody else can make use of the hash, even those within the entity organization who do not have access to the UUID/GUID. The UUID/GUID itself is not PII so it can probably be retained without violating the GDPR. The same goes for the hash. And since there is no way to reconstruct the original ID given the UUID/GUID and hash, there should be no GDPR violation.

In a large entity such as Google, you almost need to outsource ID verification to ensure it's not abused by other (advertising/marketing) parts of Google. Of course all of this requires good faith on the part of the implementing entity, which is certainly not guaranteed.