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




The accepted answer to the first link you posted explicitly calls out:

> There is one class of data that you have to delete - and that's personal data that the user doesn't want you to hold any more. There may be local laws (e.g. in the EU) that makes this a mandatory requirement (thanks Gavin)

This is exactly the type of data we're discussing here. So no, contradicting the user's expectation when handling personal data is not a "best practice".


Disclaimer: I deleted my Facebook account a couple years ago and never looked back.

That said, Facebook is who is just getting collectively stabbed with the pitchfork right now. Engineering best practices are one thing. My right to privacy is another. As an engineer I care about efficiency. As a human I care about privacy. My rights win over any technocratic babble. Sorry if I am being harsh. I am, of course not surprised. Engineers are lazy at best and at worst, something truly sinister is brewing.


I agree that you have the right to privacy, but there's also technical reasons why instant deletion is not always possible. If they can guarantee that the data will be gone after X days, then that's fair to me.


Yeah, that works. A best effort of actual deletion is good enough IMO. Maybe even notification it is actually done being sweeped out of a storage system.


"best" practices...

...as if I didn't already have enough reasons to hate that cliche, thought-terminating phrase... every situation is unique and figuring out what exactly to do for your particular one is probably the main purpose of being a software engineer.


Does this make it right, because others are doing it? I’d say it depends heavily on the type of data and the user expectation.

The correct thing would be to flag as deleted for a sensible period of time (to be able to undo for the user) and then get rid of it after X days when it clearly isn’t needed anymore.


I'm mostly curious how many people are posting angrily about Facebook retaining data while taking a break from implementing a system that retains data.


I'm guilty of the "implementing a system..." part. We are just starting, and data hungry.


Facebook lost billions in days and is poised to lose more.

I imagine there are more pressing issues than the difficulty of implementing a schema.


Not just billions but tens of billions. Somewhere around $50B.


"best practices" is for developers.

For the average Joe and Janet out there, "deleting" something is synonymous to "remove from the internet for eternity"


Except when it’s not, and they want back the data they’ve deleted by mistake.

In those cases it will take a lot of support to explain that what is gone is gone. I think customers don’t have a unified vision of what deleting means, they just want what’s optimal for the situation.


Then let FB show what is happening. Let them change the text on the "Delete" button to "Remove from timeline" or something similar.

How hard is it to clearly state what FB is doing in the background?


>"remove from the internet for eternity" lol, internet never forgets. Everybody seems to have an ilusion of control over digital data shared with others or uploaded to the internet.


From your first link:

> There is one class of data that you have to delete - and that's personal data that the user doesn't want you to hold any more. There may be local laws (e.g. in the EU) that makes this a mandatory requirement (thanks Gavin)


These best practices are about database records and not about files. I'd be very surprised if Facebook store files as database blobs. These are generally stored on a separate system, and it's quite reasonable to delete the file while keeping the metadata in the database.


After so many links, let me just answer with a link as well:

https://en.wikipedia.org/wiki/Confirmation_bias


Privacy hawks are always looking for a reason to complain about Facebook and scream I told you so.




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

Search: