4 ms·
From a user's perspective, I can see a privacy drawback as well. Suppose that instead of a typical User table, you have a User_Revision table like suggested. E
by pil0u 3y ago
From a user's perspective, I can see a privacy drawback as well.
Suppose that instead of a typical User table, you have a User_Revision table like suggested. Every time a user updates their account settings, you INSERT a new row there. If a user changes their email address, you get a row each time they update it.
Not only the company gets an history of email addresses, but also they are tied to each other. If this information gets leaked, the user is exposed to more vectors of attack.
- ludston 3y agoGDPR 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.
- kaveh_h 3y agoThis 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.
- goodbyesf 3y agoPretty 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.
- roflyear 3y agoFirst, 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.
- ludston 3y agoThat'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.
- kaba0 3y agoSlightly 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 https://tildes.net/settings/account_recovery , and I found it very genius)
- misterS 3y agoThis works great for password resets. It does not work if you actually want to send emails, for instance notifications.
- vbezhenar 3y agoWhile it's better than storing emails in clear-text, nobody uses vvkcbrxrsewf@gmail.com. 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.
- kaba0 3y agoYou 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.
- razzm256 3y agoForgetting 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.