Comment by sgrenfro | Hacker News Reader

Comment by sgrenfro | Hacker News Reader

My name is Scott Renfro, and I’m a software engineer at Facebook working on security and privacy. I thought I'd post the comment I submitted on the original blog post here as well. We’ve put a lot of work into making deletions permanent, so I can imagine how frustrated you must be. I’m pretty sure those story deletions are permanent, and I can’t think of any place where we can or do automatically restore user-deleted content months later.

If you happen to have any more details about specific stories that reappeared, I’d love to try and figure out exactly what happened. Admittedly, that may be difficult now that several months have passed.

As one of the other commenters mentioned, your Activity Log is a better place to get a full list of your activity and delete it item-by-item. It also shows posts that Timeline omits and includes other types of content such as likes and comments. This help page may be useful https://www.facebook.com/help/activitylog and you can find your Activity Log at https://www.facebook.com/me/allactivity?privacy_source=activ...

I couldn’t tell from your description, but one possibility is that you only saw and deleted the stories rendered on your Timeline, which is just a summary of your activity.

As long as you're here, any comment on the (current) top-rated comment by lukejduncan? How can we trust that our private information today won't be similarly exposed by a settings change tomorrow? (I hope that nothing I've posted would endanger my relationship with my family, but I know others aren't as safe.)

I'd like to think we wouldn't need to make such a fundamental change again in the future, but if we did decide it was necessary, I hope that we would give everyone plenty of time to make whatever change to their account was necessary to avoid painful outcomes like that.

"I hope" isn't much comfort.

Random engineers, even awesome ones like Renfro, don't have anything useful to say about what the SVP of Product is going to decide about how facebook.com will behave.

>We’ve put a lot of work into making deletions permanent, so I can imagine how frustrated you must be

It shouldn't be necessary to put a lot of work. Just delete the content, clobber it with blank fields, or randomized content. It really is very easy.

The problem is that your company's policy is to never truly delete content despite calling it "delete", there are many ways to weasel-word it ("many software subsystems don't truly delete" blah blah) but when someone asks a third party to delete something (s)he doesn't ask for it to have it marked deleted. Just delete it.

Surely not your fault though.

PS: there's no money in this world so that I'd work for a company with the morals and values of Facebook.

When the delete button affects a single row in a single database table, it's indeed really simple. Even if it's a few rows on a single database, you can use transactions. Either way, the deletion succeeds or you surface an error message.

But for a large social site, it starts to become a more interesting distributed systems problem.

Even for a simple story with 4 likes, 12 comments, and likes on several of the comments, the data is sharded across several databases. Simple transactions no longer work. One option is looking for scalable distributed transactions. A more likely option is making sure deletions can be interrupted and restarted without losing state.

Now imagine a public figure whose post has tens of thousands of comments and hundreds of thousands likes. You may not be able to load all of those rows in a single request let alone delete them synchronously. Instead, you have to be able to process the deletion incrementally, reading and deleting some of the data then later picking up where you left off the last time you were interrupted.

Interestingly, the order of these operations can also be important. If you're interrupted between deleting a comment and deleting the likes on that comment, will you still be able to find the likes when you restart?

We've put a lot of work into a deletion framework that deals with these and many other issues. We're hoping to share more details about it in the future.

So you're telling me that you/they manage to commit inserts and updates to your/their sharded databases reliably but deletes conveniently fail.

Well comment tree deletion is a harder operation than post creation or comment creation or liking.

Each of the steps in building up the tree of comments, likes, etc. is a a couple writes at most. If that fails, you're left in a safe state. You tell the user it failed and carry on.

Deleting a post and the comments on it is harder. First, you have a potentially unbounded amount of DB rows to delete across an unknown number of shards. Second, you now have to worry about the order in which you delete things, else you risk being unable to retry in case one of these deletes fails. Third, unlike the inserts and updates, you can't just give up partway, as that's not a safe state to end in.

Reply on news.ycombinator.com