Hacker News Reader

Comment by chrismatheson | Hacker News Reader

I suppose that feature would be incompatible with user data in a GDPR world ??

No, as the right to be forgotten (if that’s what you’re thinking of) isn’t absolute.

The example I’m aware of is where personal information is held due to ‘legitimate interest’ and the request to delete isn’t deemed (however that is defined) to override that.

I won’t try to go further as it’s not 100% clear cut and IANAL.

Have a look at the legislation or the various explainers that have been posted online if you’re interested.

Edit: In this case I would guess that Canon would have trouble claiming a legitimate interest in keeping hold of your photos!

Depends on how long it is stored, you have some time (one month) to clear your systems when you get a request for deletion.

I'm not a lawyer, but my understanding is that GDPR requires companies to remove user data upon request in reasonable time-frame. If you keep not deletable backups for one month in order to improve reliability of your service, then my understanding is that it is fine to fulfill the GDPR data deletion requests withing one month period, not immediately.

Filtering this stuff from a master transaction log is kinda ludicrous, not looking forward to implementing that.

It's sometimes easier to encrypt everything sensitive with a user-specific key and destroy the key.

That's how I've done it as well. The files are backed up for as long as we want, they are just useless once the user's secret is trashed. You can do the userid blocklist's on database restores etc. but for long term backup file storage it becomes silly.

I don't think the GDPR imposes a requirement to actively filter backups.

It's not a backup, it's the authoritative dataset.

Git is also incompatible with GDPR, you can't simply delete a file from all history.

Git is not really intended for personal data

Yeah, I don't really understand why you would like to stuff personal data into a git repository (unless we're strictly speaking about author data). It's really not the tool for it.

Now for those who decided that a blockchain is the perfect solution for storing personal data however...

Name and Email is personal data...

You can, you just have to be willing to rewrite history. See git-filter-branch (and don't forget to read the fat WARNING).

Git allows you to rewrite history, that is not the problem.

But you might have a hard time chasing down every copy, it's a distributed system by design.

Once you rewrite history, you've basically broken the git concept. It's an emergency feature if you've accidentally committed a security token or similar, or before you've pushed upstream, but if you're rewriting history with any sort of regularity, you're using git very, very wrong.

Don't store your users PII in a git repository then.

The use case is to do dataset versioning for ML. The dataset itself is updated frequently. It would be nice to use a tool that can store efficiently when small changes are made yet allow versioning for reproducibility.

If you do ML on sensitive data from actual users, reproducibility is a crime, not a feature. You need to ensure that your ML forgets deleted data completely and irreversibly.

Oh man, all my WORM tapes are not GDPR compatible...thats terrible!!!

Reply on news.ycombinator.com