[shmolyneaux]

That seems like a GDPR violation waiting to happen. It shouldn't be possible for them to store an email address like that forever and be in compliance.

[arielweisberg]

This can be implemented without storing it. They could store a hash. No idea what they actually do.

[charcircuit]

A hash of a public identifier like an email is personally identifiable data.

[jounker]

Isn’t the entire point of a cryptographically secure hash that you can’t derive the original information?

[charcircuit]

You can't derive the original better than guessing. With public identifiers you can just take a list of them and guess with those. If someone asks for your email they can hash it themselves and compare it against whatever databases.

[pfortuny]

You can always encrypt with a public key instead of hashing.

[pbhjpbhj]

You mean 'as well as', right?

[pfortuny]

No, I mean encrypting (using a random padding like OAEP-RSA) gives an undecipherable item.

[kstrauser]

If user [e-mail] violates our ToS and I suspend them, I can keep that email address forever to keep them from signing up again. They can’t just say “GDPR! You have to forget me, tee-hee!”

[hluska]

Any reason you won’t just use a hash?

[kstrauser]

Yep. Almost every company uses multiple vendors for things. Suppose you use a tech support helpdesk and you don't want to waste time dealing with banned ex-customers. You can't import that list of hashes into Zendesk or whatever and tell them to blocklist them.

Substitute "billing company" or "authentication provider" or "fraud detector" for "helpdesk". There are times when it's not sufficient to say "don't do business with SHA-256 hash ef61a579c907bbed674c0dbcbcf7f7af8f851538eef7b8e58c5bee0b8cfdac4a". You need to say "John Smith is banned".

[silversmith]

GDPR says you are not allowed to store my data just because. If you have a good enough reason, everything is allowed.