11 ms·

You can't purge backups: if the servers were allowed to go in and remotely modify the off-site backups to purge deleted data, then an intruder could do the same

by Xuzz 15y ago

You can't purge backups: if the servers were allowed to go in and remotely modify the off-site backups to purge deleted data, then an intruder could do the same thing for all data. So you can't permanently delete data in the backups. When subpoenaed, Facebook would have to go back through the backups and find the user-deleted data anyway: they still have it under their control. So there's really no difference in marking a "deleted" flag or purging the data from the production servers: they are not (and should not, and arguably cannot be) able to the data from backups. This is true for all web services. I'm not even getting into about the support and user anger cost by permanently deleting user data. But it's clear to see that this — while an intuitive idea — is not practically possible for most web services.

drostie 15y ago
I would agree that there are privacy concerns whenever you back up user data. It's something of an interesting question because users could also be held responsible for creating their own backups, especially if you made it extremely easy for them to do. It's something like when my VPS failed. The code that I was running on my VPS I routinely backed up, but the database -- while I serialized it to disk -- wasn't ever transferred to my local computer because I didn't think it was important. When the VPS failed, the whole database was gone. The point is, I can't be angry at them for not backing it up, because that wasn't a term of the service they were providing me. A similar mental model could probably work for database-driven sites, at least for the databases storing user content -- your code should of course always be under a mirrored version control. ^_^;;
Dylan16807 15y ago
You should still delete it from the main database, even if you defer it for a week via deleted=1 for performance reasons. And then it's easy to purge ALL user data backups more than X months old.

by Xuzz 15y ago

drostie 15y ago

I would agree that there are privacy concerns whenever you back up user data. It's something of an interesting question because users could also be held responsible for creating their own backups, especially if you made it extremely easy for them to do. It's something like when my VPS failed. The code that I was running on my VPS I routinely backed up, but the database -- while I serialized it to disk -- wasn't ever transferred to my local computer because I didn't think it was important. When the VPS failed, the whole database was gone. The point is, I can't be angry at them for not backing it up, because that wasn't a term of the service they were providing me. A similar mental model could probably work for database-driven sites, at least for the databases storing user content -- your code should of course always be under a mirrored version control. ^_^;;

Dylan16807 15y ago

You should still delete it from the main database, even if you defer it for a week via deleted=1 for performance reasons. And then it's easy to purge ALL user data backups more than X months old.