Hacker News Reader

Comment by NiceWayToDoIT | Hacker News Reader

Nice project, although I have question I would appreciate someone can answer. How does in real world "right to forget" works. What is confusing part for me that data that identify you are also required for the business, so how do you draw line what can be forgotten and what cannot. Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing? Second, how does that work in regards to book keeping and tax policies, where you are required to have data about your clients?

View on HN

The right to erasure (aka the right to be forgotten) is not universal and only applies in certain circumstances.

> Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing?

In this case a business (or 'data controller' in GDPR lingo) can use 'legitimate interest' as a lawful basis for processing the users information. Of course the data you kept would have to be proportional to what you're doing. For example, it would be hard to argue that you needed to keep the users billing address history if your services used a simple email black list (this is the 'data minimisation' principle).

> how does that work in regards to book keeping and tax policies, where you are required to have data about your clients?

As a rule of thumb, if you're using some personal data to comply with another piece of law then that usage is generally exempt from GDPR.

Source: https://ico.org.uk/for-organisations/guide-to-data-protectio...

Thanks.

That does get complicated in the real world. You might need to retain some data for potential future refunds, for example. But perhaps the application that does refunds also does the loyalty program, and the internals of the app aren't always separate enough that you can delete/obfuscate/whatever info from just the loyalty part.

> You might need to retain some data for potential future refunds, for example.

Then that would be a legitimate interest, and you could store that information for a period of time that is reasonable for processing refund requests.

But you would be barred from using that same information for a different purpose, e.g. the loyalty program.

GDPR article 25 requires systems to be have privacy built in, so a system such as the one you describe where a separation of these concerns is impossible, would probably itself be in violation of the regulation.

I am no expert on GDPR or security, but wouldn't a simple "PII to Cryptologically Secure Hash" solution work for some of this? The PII would possibly need to be accessed piecemeal while the account is active, so hashing is not appropriate alone, but once the account is deleted you could store a user's hash (or partial hash, made from only truly unique info or info combos) since it cannot be reconstituted and contains no specific PII. You then store this hash in your "abusive person" list, or whatever, maybe link it to refund data if needed, and if a "forgotten" user needs to interact with the service they fill in their information which is converted to the hash without saving. Doable?

this doesn't cut it. someone could take a list of email addresses, hash them, and then reidentify the dataset. hashing buys you nothing from a gdpr/ccpa compliance perspective, storing the hash is seen as no different from storing the pii itself. it really only makes things harder because it becomes more difficult to find where all the pii is when someone submits a request for you to return or delete their data.

Do you have a source for this? I thought for the gdpr it was enough that data is not easily accessible. For example, it is not necessary to delete PII from backups unless they can be automatically restored (and are reasonably encrypted). Hashing PII thus falls under this category.

i don't have a source i can link here, this is guidance i have gotten from lawyers.

There are two issue with hashing I can envisage:

1. Nothing user has is truly hash-able, (email can be replaced, there are people with the same name/dob/place of birth, address is not permanent attribute...)

2. Hash key can have duplicates - so those collisions would block different users (probably not for small companies but for FB with 2 billion users something worth considering.)

Reply on news.ycombinator.com