[cco]

A framing I often use is, "Data is like holding uranium". It can be incredibly valuable, but also very dangerous. You should be very sure that the data you're holding is worth the cost of safely protecting it (a high cost), and if it is not, get rid of it.

Stripe is a good mental model here, I don't want a person's credit card data, I want to charge them for my product. I love storing a Stripe customer ID, if a hacker were to grab that table, I wouldn't lose (a lot) of sleep, they couldn't do much with it. If that table held credit card data...I would.

That farms out a lot of responsibility to Stripe, but for a side project, I don't have the time necessary to do as good of a job at it relative to Stripe.

[mhb]

FWIW, most other merchant credit card processors also handle this using tokens, encrypting credit card keypads, etc.

[SV_BubbleTime]

And have for 25 years been or so. Authorize.net predates a lot and this was always their main feature, they run it and you get the OK and an ID.

[e_i_pi_2]

I think GDPR was a great step in this direction, even with the annoying cookies popups. There's some states in the US with similar laws basically saying "it's legal for you to collect this data, but if you do you need to build systems for people to request all the data tied to them and for it to be deleted". Hopefully the next step would be to make data sharing opt-in, while it's somewhat limited it is really nice that iOS makes apps request access to different data.

I'm really curious how effective these are in practice if someone got logs or backups, but it at least gives people a path to know what data is there remove the active copies