How are you going to "fix" that "design flaw" when the personal data in question is the result of legally required customer age checks? Evidence needed to support your tax filings? Used to identify and block people who are repeatedly trying to defraud you or breach your security? Subject to a legal hold because it might provide relevant evidence in some legal action between other parties or it's been requested as evidence by some government committee?
Data protection laws like the GDPR might take the position that you should minimise the collection and use of personal data. Many of us might even agree with that position in principle. It can still be complicated to work out what "minimal" actually means if you did have good reasons to collect the personal data in the first place and you might still need to keep the data or some part of it for those purposes or to comply with other laws or regulations.
> How are you going to "fix" that "design flaw" when the personal data in question is the result of legally required customer age checks? Evidence needed to support your tax filings?
This kind of wilfully ignorant argument is extremely tedious and indicative of the fact that you do not understand the actual construction of the GDPR, or choose to misrepresent it.
Let’s put this nonsense to bed once and for all by quoting the Irish summary [1] of articles 17 and 19:
> You have the right to have your data erased, without undue delay, by the data controller, if one of the following grounds applies:
> - Where your personal data are no longer necessary in relation to the purpose for which it was collected or processed.
> - Where you withdraw your consent to the processing and there is no other lawful basis for processing the data.
Information pertinent to tax records is not collected on the basis of consent, and nor is anything else legally required.
This is HN. Please don't post comments with that sort of hostile tone here. Assuming ignorance and/or bad faith does not further constructive or interesting discussion.
I absolutely agree though, this argument is extremely weak, like a developer being asked to step outside their comfort zone locking up and declaring something unknowable levels of complexity so they don't even have to try.
The GDPR is extremely easy to understand. It's not always trivial to comply with, because we all know that enterprises are held together with instant glue, a networking VM in a basement nobody has logged in to for 10 years, at least 3 layers of management between a DPO and feature teams and one all-knowing employee everyone hopes will never leave or take too much vacation because things will slowly crumble in their absence. It's pretty hard to be absolutely compliant in that environment. But if you're a startup, or even solo? You can absolutely design your app to not have these issues in the first place.
I respectfully disagree. And I write that not only as a very experienced developer but also as a director who has been legally responsible for GDPR compliance in more than one relatively small organisation.
The GDPR in its official format in English is 88 printed pages. It contains 173 introductory paragraphs followed by 99 specific Articles some of which span multiple pages by themselves. As is customary for legislation made at EU level a lot of the provisions are written more as statements of intent with considerable ambiguity about concrete implementation that is left to regulators or courts to clarify.
The specific legal basis of "legitimate interests" and the overarching obligations to collect and process data only where it is reasonably necessary are good examples of this openness to interpretation. And yet much of the data processing that most of us would probably agree is reasonable relies on the legitimate interests basis for its lawfulness. Several enforcement actions by regulators have already been brought against data controllers who apparently believed they were acting in compliance but were still found to be infringing the general principles around necessity and proportionality.
I contend that any legal document running to nearly 100 printed pages of densely printed text cannot credibly be described as "easy to understand". Indeed I must have read hundreds more pages of analysis and discussion by legal scholars, professional data protection officers and other experts and there have been plenty of disagreements over interpretation or sometimes outright contradictions between those papers.
Of course the only things that actually matter are the actions of the regulators or other official bodies that interpret the regulations and potentially sanction those who infringe them in specific cases. That means we also have to consider the stated opinions and actions to date of all the different national regulatory authorities and the outcomes of the cases that have been formally considered and resolved so far. And once again it is clear that even among the national regulators who are responsible for the interpretation and implementation of the rules there can be considerable disagreements about how the rules should be interpreted and sometimes which cases should be brought at all.
Now I don't necessarily disagree with some of those outcomes but I do think that if a data controller honestly believed their prohibited actions were in compliance and was subsequently penalised and required to make changes then evidently there is a problem with how accessible/understandable the rules are and those rules demonstrably failed to prevent the unwanted behaviours in those cases until the regulators did take action.
I will take your point, but I'd say you also need to account for how the GDPR has been enforced to this point. I regularly submit complaints to supervisory authorities and I've been employed by a few companies that regularly have meetings with their local SAs for guidance regarding potential pitfalls.
Most enforcement is directed towards total disregard of the GDPR. Data that hasn't been properly deleted after requests, requests that go unanswered, and entities like Meta who think their legitimate interest towers over protected categories of information (i.e. allowing microtargeting based on health). Companies also get away with a lot of easy to see violations (i.e. I've complained about Microsoft doing dark patterns to obscure whether agreeing to data collection is a requirement for a service to work).
Usually you'll be fine if you understand the basic framework and intent.
And I'm not sure how you get to 88 pages. It comes out to 68 pages with very generous margins and a line-height of 22pt on A4 for me.[1] (also, all EU law, including translated judgements, is canonical in all member state languages, FYI)
I will take your point, but I'd say you also need to account for how the GDPR has been enforced to this point. ... Most enforcement is directed towards total disregard of the GDPR.
I agree this is true. And at least here in the UK the regulators appear to be acting in good faith and according to the spirit of the law. However I don't like the principle that not enforcing a bad rule somehow makes it better.
If something doesn't need to be enforced then it doesn't need to be a rule at all. Then it can't be selectively and possibly punitively enforced against someone the authorities take a dislike to or simply because of a bureaucratic mistake caused by incompetence rather than malice.
Moreover having rules that are rarely enforced effectively penalises those who do make a good faith effort to comply but probably would not have suffered any ill effects if they had not done so. They're being penalised by paying extra compliance costs for trying to do "the right thing" and that doesn't seem like a good idea to me. In a business context it is literally giving a direct financial advantage to competitors who bend or outright ignore the rules and get away with it.
Also, legal texts are the always longer than a conceptual tl;dr of them. Covering for all eventualities. It's not a flaw of the legislation itself that some boilerplate is required. Also, a lot of it is contextually relevant (e.g. there's entire sections for regulating specific industries).
Your average contract contains the same boilerplate by percentage.
I don't know where your actual problem is. The GDPR allows holding data for most of these purposes. You intermingled legal obligations with data legal departments would like to hold in the end there. Only one of those is required.
Also, some of these are pure theoretical in the EU. You're not even allowed to photocopy an ID in Germany; age verification is a checkmark someone sets upon verifying the ID is valid and then (metaphorically) handing it back, not a copy of a legal document that you probably don't want deduplicated to random S3 buckets held by all the companies you do business with. They're not exactly resistant to replay attacks, after all.
My point is that knowing which personal data you need to redact and under which circumstances is not always easy. Before you can build a system that does something you first need to identify exactly what something is required.
- Payments, particularly from P2P transactions. If I send you money, and then you request the deletion of your profile, there's plenty of complexity there.
- Enforcement records from illegal content / violating content
- Local data cache for offline mode in mobile apps
I'm not saying all of these apply to "Threads". But there are tons of edge cases to consider that need code changes t o behave as expected.
There's really no complexity there. The right to be forgotten doesn't superseed other laws, and it is required by law in most countries, that transaction data be stored for 5 years plus running year, so in case you request to be forgotten, that can only happen once the mandatory data retainment has expired, which can easily be handled by a "transaction date", and simply run a batch job that matches each user to their transactions (and desire to be forgotten), and once transaction are expired and the user has requested to be forgotten, you simply delete.
> Local data cache for offline mode in mobile apps
The right to be forgotten has a "grace period", so set your cache expiration to less than that amount of time and you're pretty much home safe, or better yet, don't cache GDPR sensitive data and you can pretty much cache for as long as you like.
There's a lot more to payments than raw transaction data. Payments are usually related to the exchange of goods or services. The delivery data of those could be essential for winning a chargeback dispute or a liability for a customer that asked to be forgotten.
such as the ability easily support redaction of personal data?
Errg: sorry folks. I miss read the thread and thought the "such as" was responding to the comment next to it about the design flaw of not being able to delete personal data.
