GDPR and the right to having your personal data deleted certainly puts a bit of a stopper on using an immutable database for anything personally identifying.

This would be the case if you’re a purist, but you can be practical and allow physical deletions of certain record just for this reason.

Pretty much all databases are "immutable". The logs contain every transaction ever made and most institutions save their logs. Also, backups of data are stored on tape and likely shipped somewhere for safekeeping.

First, I don't consider that immutable. Second, that isn't true for all databases, often you have to set it up and turn it on, and think about what you're doing as there are considerations for storage and backups. Third, it isn't like you can just get the data back magically and without effort. It can be a problem to hunt through. It can be an enormous amount of data.

That's not immutability, that's "log shipping". And if an organisation doesn't have the capability to delete personal data from it's backups, and it operates in Europe, chances are that it's in violation of GDPR and could be subject to millions of Euro's in fines.

Slightly unrelated: A great way to solve this specific email issue is to store hashes for emails only, similarly to passwords. When a user needs a password reset, they should send an email to a specific address, the sender mail is hashed, and if it matches a user, a password reset link is replied. That way a data breach can’t expose user emails.

(This is what Tildes use: https://tildes.net/settings/account_recovery , and I found it very genius)

While it's better than storing emails in clear-text, nobody uses [email protected]. Brute-forcing emails is going to be pretty effective. And if you have another e-mail database (which are plenty available in the open wild), I bet that success rate will be huge.

I like Apple's approach to generating random throwaway emails.

You don’t have to use the same salt for each email, right? You can hash each email with a separate, random salt and “brute force” upon password recovery. That way while individual emails can still be restored, you can’t easily get a database of emails to mass-spam, which is the point (emails are not really private completely, anyway).

I also like apple’s method, but it is not either-or.

This works great for password resets.

It does not work if you actually want to send emails, for instance notifications.

That’s true, though many websites would be much better off if they would properly evaluate the question of do they actually need to send those?

That's an added bonus to the user in most cases!

This is probably worth doing, but one should be aware that a typical e-mail address does not contain enough entropy to not be guessable offline.

Perhaps someone should deliberately leek a bogus database that contains the bcrypt hash of [email protected] and see if that account starts receiving spam ... probably it won't.

There is (almost certainly) no associated e-mail account, but the following is the SHA-256 hash of firstname.lastname.threedigits, something like "davey.jones.490". I'm half-expecting someone to reply with the solution, though I think there are about 36 bits of entropy in my choice:

b8b6395265714064afb525f37e9969a7dbf09a4a2afa28812e917580be2dc667

Forgetting is a separate operation that can be (relatively) easily added whereas updating existing system to work w/ immutable data is an effort on a whole another scale.