Live data from Hacker News

Instagram kept deleted photos and messages on its servers for more than a year

theverge.com

131–140 of 205 posts

Re: Instagram kept deleted photos and messages on its servers for more than a year

#131
post #9

We know that HN is visited by a fair share of Facebook employees. Can some of you weigh in (anonymously?) on this topic? Do you guys do hard deletes of user data instead of just soft deletes? If so, are logs or backups kept? For how long? In other words: if I'm a user of $POPULAR_SERVICE and I delete my account at time t0, is there a t1 > t0 after which every trace of my data is gone from the platform? My (cynical) g…

For non-cynical reasons, no. It's basically 90 days for FB data, which is mostly because the majority of logs get deleted after 3 months.

However, there's usually some large slice of user data under legal hold, which legally can't be dropped as it's pertinent to some random long running court case, so not every trace of your data is gone.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#132

Whenever someone publishes an article like this, I want them to find out what its like when you reach the threshold of 100000 individual delete requests per second which ends up being five million actual deletes when you factor in all of the associated references to the item being deleted and its metadata. Then I want them to find out what happens when you have to propagate those deletes across geographically distrib…

> you literally can't just delete data

You literally can.

You can't remove data that you don't control though e.g. Removing embarrassing pictures from the internet. However if you control the server you control the data. I can appreciate that it might not be as simple as a unix command but it is a single letter in CRUD. It's fundamental.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#133

Earlier quoted context omitted.

They've got 30 days to delete data, there's no excuse not to manage it within 30 days. Also, you're saying they intentionally built a software stack without even thinking about how to obey the law (the 30-day deletion requirement existed even before the GDPR, since 1996 even, just with lower fines) I hope in a few years this case will be taught in school just like the Therac case is being taught right now.

It's not that simple, some of these companies have tech stacks that are run-a-way trains written by people who had good intentions but wrote their code and built their infrastructure in a way that was meant for 1/50th of the traffic they currently have. I don't know anything about instagram's infrastructure but what I can tell you for certain is that every one of these companies has legacy infrastructure and code tha…

> I don't know anything about instagram's infrastructure but what I can tell you for certain is that every one of these companies has legacy infrastructure

So you don't know anything about Instagram but at the same time know for certain that they have legacy infrastructure that keeps them from meeting legal requirements? How about we don't give them a pass just because it requires a bit of work to comply with laws and regulations.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#134

Earlier quoted context omitted.

This rationalization isn't acceptable to me. They have gladly set up the infrastructure to handle a high volume of new information and it should go both ways.

should See RFC 2119, "should" usually denotes something as "optional" But really, almost zero companies build software around data in such a way that the data could and will disappear at any moment.

Their comment wasn't an RFC. Right to be forgotten and GDPR are not suggestions.

Regardless, in practice, billion dollar companies have the resources to ensure 'delete' isn't actually "partially hide for years/forever". With proper surrogate IDs they could even preserve a minimal amount of meta such as tombstone IDs to ensure all first and third party systems are in compliance.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#135
post #38
post #9

We know that HN is visited by a fair share of Facebook employees. Can some of you weigh in (anonymously?) on this topic? Do you guys do hard deletes of user data instead of just soft deletes? If so, are logs or backups kept? For how long? In other words: if I'm a user of $POPULAR_SERVICE and I delete my account at time t0, is there a t1 > t0 after which every trace of my data is gone from the platform? My (cynical) g…

Deletion is a risk. It's much safer to just say it's deleted...

Under the GPDR, lack of deletion is also a risk.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#136

Whenever someone publishes an article like this, I want them to find out what its like when you reach the threshold of 100000 individual delete requests per second which ends up being five million actual deletes when you factor in all of the associated references to the item being deleted and its metadata. Then I want them to find out what happens when you have to propagate those deletes across geographically distrib…

Hi. I also work at this scale. It doesn't take a year to delete the data. Be upfront with your users:

'Your delete request is being processed. No one will be able to see this item though it may take up to three days for the data to be completely removed from our servers'

This is not a technical challenge, it's an issue of priorities and Facebook doesn't prioritize privacy. They were able to release a TikTok clone in a few months, but can't solve deleting data?

Re: Instagram kept deleted photos and messages on its servers for more than a year

#137

Whenever someone publishes an article like this, I want them to find out what its like when you reach the threshold of 100000 individual delete requests per second which ends up being five million actual deletes when you factor in all of the associated references to the item being deleted and its metadata. Then I want them to find out what happens when you have to propagate those deletes across geographically distrib…

Whenever I see someone write a comment like this, I want him to understand, that don't say deleted, if it's not deleted. Also, if it not works at scale, don't tell your users that it works and pretend it works as you communicated. I find really bothering, when engineers trying to hide behind the "it's a very complicated process in the background, so we just say we have done something, when the truth is, it is in prog…

Developers are also falling into this trap regularly with distributed systems. MongoDB famously claimed to be "eventually consistent" but in reality failed to deliver on this promise. The MongoDB authors then tried to weasel their way out of it the same way you are describing and many developers rightfully called them out on it.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#138

Earlier quoted context omitted.

The vast majority of companies I've seen consider issuing "SQL DELETE" is sufficient for GDPR compliance. One day, they will be burned when some investigation finds out that those rows are still sitting in uncompacted tables, or on now-unallocated disk blocks, or on now-remapped SSD sectors. The only way to be sure the data is deleted is to copy all the data you want to keep to a new drive and burn the old one. Anyth…

All it takes is one dataleak[+] to blow that wide open. Secure erase is hard. But what is much less hard is to encrypt data and then to limit the problem to getting rid of the decryption key. This reduces the problem in scope to one single datum rather than a whole chain of possible plaintext copies. Secure erase is a contractual requirement for many relationships, it is interesting that none of the major db vendors…

> But what is much less hard is to encrypt data and then to limit the problem to getting rid of the decryption key. This reduces the problem in scope to one single datum rather than a whole chain of possible plaintext copies.

Key issue: you can't do any operations on encrypted data, essentially you're killing off your database.

Homomorphic encryption is academic research, not something that is widely available and supported in common open and closed source databases. The best you can get is a database that encrypts the on disk data (Oracle TDE), but that only protects against a server being stolen or hacked on the OS level.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#139

Whenever someone publishes an article like this, I want them to find out what its like when you reach the threshold of 100000 individual delete requests per second which ends up being five million actual deletes when you factor in all of the associated references to the item being deleted and its metadata. Then I want them to find out what happens when you have to propagate those deletes across geographically distrib…

Whenever I see someone write a comment like this, I want him to understand, that don't say deleted, if it's not deleted. Also, if it not works at scale, don't tell your users that it works and pretend it works as you communicated. I find really bothering, when engineers trying to hide behind the "it's a very complicated process in the background, so we just say we have done something, when the truth is, it is in prog…

I agree with you completely, no one should be hiding behind "It's a really complicated process". They need to actually sit down and come up with a concrete plan on how to tackle the problem then communicate that we have a plan in place its been added to the roadmap and we are going to tackle it in Q3 20XX.

Re: Instagram kept deleted photos and messages on its servers for more than a year

#140
post #8

I want to know if the photos are securely deleted. It's not enough that the mere reference to a file is gone. I want everything overwritten with zeroes, and the photo made properly irrecoverable.

Always encrypt the data at rest, and delete by deleting the key is likely how this would be done. This way you can also delete e.g. tape backups without actually loading the tape and re-writing the whole thing with certain portions deleted, which is not really practical.

Yes, and you could also queue files for deletion at a later stage by throwing away the encryption key for a large batch of files which have been queued for deletion.
Post reply on HN