Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

First, if you cared about user privacy, you would store as few data points as possible.

Second, it’s very likely that you have APIs in place that can request all data for a user anyways. If you don’t know what data you have of your users, you don’t give a shit about their privacy, no?

Third, user requests are usually: a) what data do you store about me? B) Export all data. C) delete all my data (for real).



At any kind of scale that is 100% not the case.

The orchestration of a data extract from even a midsized corporation is a significant endeavour.

Someone in the company knowing what data we have on an entity is a significant step away from the entire company being able to access that, because, you know, we take data privacy seriously, so we don’t make it easy to access all data on a single entity.

If your approach to privacy is putting all the eggs in a basket, allowing easy extraction of everything from that basket, and hoping the basket can be kept secure I’d argue your model is weird to begin with.


This is so simplistic. There are many storage solutions for many different use cases.

Some of these are write once and immutable afterwards.

There are relational structures for transaction history that may also link to customers.

These all have to be re-designed in such away that information can be removed from the system and exported from the system, while keeping essential information (such as past sales records).

This is not an easy problem to solve.


> Some of these are write once and immutable afterwards.

Got an example of something like that that'd make it impossible to soft delete a person? I'm struggling to think of any datastore in regular use that's write only.



Yeah, as I thought, it's a blockchain/distributed ledger related technology. Hence why I said "regular use". I doubt large numbers of EU businesses are suddenly having to move data from their core ledger to another datastore because of this.


>Third, user requests are usually: a) what data do you store about me? B) Export all data. C) delete all my data (for real).

Are you implying that those 3 requests are simple to fulfill in a business running a modern software architecture?


Backups usually aren't designed for deletion of individual records. Until recently this was considered to be ok.


If your backups age out and are deleted over time it is ok (as long as that timeframe is reasonable).


_if_ you can ensure that you can re-execute deletion requests if the data needs to be restored.


With GDPR no backup can be kept more than 60 days.


It still is.


they aren’t but this is actually quite easy. PD gets encrypted on a per user basis. to forget a record, throw away the key.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: