Hacker News new | past | comments | ask | show | jobs | submit login

FWIW, Facebook does say that they will delete all of your data within 90 days of account deletion. I believe that indicates that they've put the engineering effort to do a full audit of data to be deleted, handle missing references across the product, and to fully delete user data from logs and backups.

From https://www.facebook.com/help/250563911970368 :

> When you delete your account, people won't be able to see it on Facebook. It may take up to 90 days from the beginning of the deletion process to delete all of the things you've posted, like your photos, status updates or other data stored in backup systems.

The case from the article is trickier. My impression is the feature was just implemented with an append-only data model, which is often (maybe usually) a good engineering decision. "Secretly" from the article title feels disingenuous because Facebook never said it was deleted. As an engineer, it's frustrating that I might have to write my software to be more fragile to match the implicit expectations of how a non-technical user thinks software should work. But the frustration on the user's end is also plenty understandable here. Hopefully the gap can be closed a little on both sides by a combination of educating users and being more privacy-conscious in engineering and business decisions.




Fucking stupid policy - so they have 90 days to off load your shit to Utah/gov-cloud before they “delete” your data?

Who can possibly believe this BS.

Imagine you wanted to delete data of your own Sustem - but when you hit rm it takes 90 days to execute - this sentiment PISSES me off.

When I say “delete me from your service now” I have a reasonable expectation that you will delete it.

C’mon


Do you think it's as easy as "rm"-ing a file away? Your data is kept internally in a multitude of different databases. Parts of it sitting in cold storage. Log files, caches. That data is split across thousands of different nodes. Each system has different data retention policies. Some databases don't permit removal of a specific record - the records must "expire" first. It really does take time to delete data.


True, but this isn't an excuse. It's slow to delete data because Facebook designed it that way. They could have designed for privacy and real-time deletion of data, but they didn't, because they didn't care.


> "They could have designed for privacy and real-time deletion of data"

Actually, they could not. If data is geo-replicated across multiple clusters, spread all over the place, divided into hot and cold storage layers - it's crystal clear you can't perform "real time deletion of data". Instantaneous deletion of all data, leaving no trace behind, can not happen under such complex constraints.


>> > "They could have designed for privacy and real-time deletion of data"

> Actually, they could not. If data is geo-replicated across multiple clusters, spread all over the place, divided into hot and cold storage layers - it's crystal clear you can't perform "real time deletion of data". Instantaneous deletion of all data, leaving no trace behind, can not happen under such complex constraints.

Yes, they could have. Your post is just a description of a design that can't delete data quickly. That doesn't prove that no design exists which can delete data quickly.

If Facebook had been designed with "we need to allow users to delete their data quickly and permanently" as a constraint from the beginning, it wouldn't look like the system you've described.

All you've done is pick all the things that Facebook did and say that if you do those things you can't delete data quickly. Yes, that's true--which is why Facebook would not have done those things if they cared about allowing users to delete their data.


It's interesting that you think they need those 90 days to off load your data. As if they hadn't done so before your deletion.

By the way, rm does work like that. The file will just be marked as deleted (by removing its entry from the filesystem index), but will remain on your disk for some time afterwards, from some minutes to months. If you want to ensure deletion, you should be using shred.


> By the way, rm does work like that. The file will just be marked as deleted (by removing its entry from the filesystem index), but will remain on your disk for some time afterwards, from some minutes to months. If you want to ensure deletion, you should be using shred.

This is true, but it's worth noting that not overwriting your own data on a machine you physically own as an optimization is very different behavior from not overwriting someone else's data on your server when they request that you delete it.


I couldn't agree more.


“Rm doesn’t work like that, so clearly it’s ok that Facebook takes 90 days to delete your data after you make the request”

Utter horse crap


If you put words into other people's mouths, you're only creating confusion for yourself. I meant what I wrote, and nothing more.


> Fucking stupid policy - so they have 90 days to off load your shit to Utah/gov-cloud before they “delete” your data?

FWIW I would be surprised if there is not a delay when deleting from S3/Azure Storage/GCS (and thus anything that uses those services).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: