Can you say specifically what goes too far? I don't find it onerous or unreasonable at all, but my business model doesn't improve by violating it either.
Even with the best of intentions, these laws can be labyrinthian and ambiguous, and therefore expensive to (try to) observe. And there is still always the risk that you are found guilty of something. For a small or medium business, you are likely to be far enough out of the radar to avoid issues. But as a large company you may easily end up in legal crosshairs, costing millions or billions of euros, even if you ultimately prevail. And if you lose…
These laws being byzantine is the result of almost two decades of legal battles. Meta and Google have batteries of competent lawyers and lobbyists, constantly testing for legal loopholes, interpretations and contesting complaints in European courts.
Privacy laws aren't new, they existed before the GDPR. But they were fractured and not up-to-par with the new digital reality of large scale collection of personal data. These laws are geared exactly against the very business model of Google and Meta: offer free services, be first to market and become a gatekeeper, collect user data as broadly as possible, sell business intelligence and marketing services to actual paying customers.
When Meta states that it can't release Threads due to "unknown legal liabilities" that's a round-about way of admitting that their business model doesn't entirely square with European laws, such as they are.
Finally, as far as size in terms of user base, revenue and expenses go, the likes of Meta, Google and Twitter are very much a league of their own. Given their business model and its profitability, it's inevitable that their goals and motives are at odds with the interests and legal rights of citizens.
People keep saying this and yet it’s never happened despite the GDPR being in place for 5 years now.
As a tech manager for an EU company, I can honestly say that it isn’t that hard to be GDPR compliant.
Even when I worked for a company that did need to collect customer information, we pretty well understood what we could and couldn’t do under GDPR.
This whole “GDPR is dangerous” meme needs to die because businesses aren’t being dragged in court over trivial things because of it. The only people moaning are those who were abusing peoples data to begin with. And those are exactly the types of companies this law is protecting people from.
> As a tech manager for an EU company, I can honestly say that it isn’t that hard to be GDPR compliant
It's pretty easy for a business to be GDPR compliant unless their business model or processes in some way involve collecting and processing or selling personal data of their users. Before GDPR a lot of businesses used this as a nice little second income stream, or just grew used to being able to freely analyze every aspect of their users private data that they could get a hold of. Suddenly they can't do this anymore, and what's actually difficult is not being compliant with GDPR, it's reconciling their business to a new way of working where they have to be considerate of their user's right to privacy.
For example, you have a deeply entrenched analytics system that you base a lot of your decisions on. Suddenly you have to basically gut it, or even throw it out entirely. No matter that's there's plenty of GDPR compliant systems to replace it, they don't feel as effective and it's easy to see why a business would make these changes begrudgingly and with a lot of complaining about how unfair it all is.
That looks to me as though the system is working exactly as intended. When I do business with company 'A' I do not expect or consent to them passing that data on to company 'B'.
That’s the point I’m making though. The law isnt a problem. It’s companies who abused user data that’s the problem.
It’s also worth noting that you can still using customer data for analytics under GDPR. GDPR doesn’t prevent legitimate analytics from happening. It just gives consumers power to be excluded from analytics and to force companies to be transparent about their usage of personal data.
> As a tech manager for an EU company, I can honestly say that it isn’t that hard to be GDPR compliant.
> This whole “GDPR is dangerous” meme needs to die because businesses aren’t being dragged in court over trivial things because of it.
Ah, yes, the one weird trick of GDPR "compliance" by being a smaller, less appealing target to the enforcers.
The "GDPR is dangerous" meme needs to stay alive because it's massively ambiguous and different country's interpretations vary wildly. The types of companies the law is "protecting people from" are non-European ones. It's just economic protectionism in the guise of privacy.
Even if that were true, it isn’t but for the sake of the discussion I’ll humour you, America is far more open and aggressive with its protectionism policies. As is China. So I don’t understand the complaint. You’re either in favour of laws that promote the growth of local economies or you’re not.
But to be clear, the GDPR is not about protectionism. If it feels that way then perhaps you need to have a hard look at whether the bigger problem is the companies that you feel are being persecuted by GDPR and whether the countries they originate should have done more to regulate them to begin with.
I'm neutral on protectionism: I'm in favor of laws that are precise and unambiguous, and not up to the interpretation of whatever courts and enforcement agencies wish to impose.
For example, which of the following statements are true according to the ECJ's interpretation?
American companies cannot run datacenters in Europe, because the CLOUD act might compel them to give up data to American authorities.
Canadian companies cannot run datacenters in Europe, because Canada might pass legislation that compels companies to give up data to Canadian authorities.
American citizens cannot work at datacenters in Europe, because they're subject to U.S. law, and the U.S. might pass legislation to compel them to steal data.
Germany cannot host datacenters, because they lack an independent nuclear triad, meaning that they're subject to U.S. invasion to seize the datacenters.
> I'm in favor of laws that are precise and unambiguous, and not up to the interpretation of whatever courts and enforcement agencies wish to impose.
So am I but unfortunately the topic itself is highly nuanced. If it were that easy to say this type of usage is ok but this type isn’t then we would have been able to put better technological measures in place to keep our data safe.
And let’s be honest, GDPR is hardly an outlier. Most laws end up being nuanced when it comes to cutting edge technology. Whether it is intellectual property laws, computer misuse laws, etc. The only difference here is that innocent people aren’t being harmed by GDPR.
So if you’re going to complain about vague laws harming people, then GDPR is the literal last one you should be concerned about at this point in time.
The only reason people moan about GDPR is because entities like Facebook have brainwashed you into believing it’s bad. They say it’s “anti-business”, “harms innocent companies”, etc. but it’s all BS. And I say this as someone who has had to work inside the GDPR every day since it’s inception.
Now if you want to moan about innocent people being arrested in America for “hacking” because they send bug bounties, or even just click “view source” in Chrome…then I’m all ears. Or complain about how IP laws are being abused to hoard monopolies on obvious ideas. Or about how companies are sucking up other peoples copyrighted content for free to train proprietary GAN. Or about the abuses of DMCA.
The thing is, companies don’t to moan about those things because those abuses empower them. Whereas GDPR levels the playing field. So despite the fact that GDPR has never once been abused and the others frequently are, GDPR is the law that everyone gets pissy about.
This is absolutely not my experience while working in an Ad agency in EU. There are companies like Iubenda which basically handle all the normative side of things, and if required by third parties they also do the compliance checks.
We've had no more than two disputes since the GDPR was passed and they both ended up with a simple "Please remove their data and make sure that X services are deactivated too when the user fills their consent form".
No scary lawyers or multimillionaire suits. I guess that part is reserved for those that consciously decide to ignore the rules.
> Seriously though, GDPR compliance isn’t that hard
Unless compiling data on your users and selling it is your entire business plan.
One of the issue I see it that many companies have been lured into this impression that they need to track everything, in great detail, but it doesn't actually provide that much value. I blame the snake oil sales people in the advertising/remarketing/up-selling/cross-selling business.
This is correct. So many websites don’t actually need to collect any user data. It’s just a distraction, slows down and bloats their site and worsens UX.
I recommend to simply get rid of any tracking. If you want user feedback, ask them or do tests. It’s cheaper and more effective.
So many websites don’t actually need to collect any user data.
Any commercial organisation is going to have customers and therefore customer details and payments data.
Any commercial site needs to record enough logs to investigate events like outages or security threats.
Any site that isn't purely informational and read-only probably works with user-provided data in some way.
People keep writing about GDPR and similar laws as if they only apply to data-harvesting analytics plugins on ad-ridden content farms but the same laws apply to everyone else as well. For many it will be reasonable and indeed necessary to process personal data in order to do whatever the site or app does.
> Any commercial organisation is going to have customers and therefore customer details and payments data.
Necessary for the performance of a contract or to comply with legal obligations.
> Any commercial site needs to record enough logs to investigate events like outages or security threats.
Legitimate interest, and possibly legal compliance if the nature of your site means you have a legal duty to collect those logs or that they could help in the course of an investigation.
> Any site that isn't purely informational and read-only probably works with user-provided data in some way.
If it's a UGC-based website, then collecting some data is necessary as part of the provision of a service or legitimate interest for fraud/spam prevention.
Every single point you mentioned would explicitly be allowed under the GDPR with either compliance with legal obligations, necessity for the performance of a contract or legitimate interest, no consent required even.
There should be no debate that the items I mentioned are allowed under the GDPR because one or more of the lawful bases for processing applies. My point is that on many sites you're still going to be collecting and processing personal data for many legitimate reasons and therefore you still need to have all the policies and provisions in place for that data to be compliant with the data protection regulations. "Just don't collect the data in the first place" is mostly not a very useful argument for how easy it is to comply with the GDPR.
On numerous occasions in GDPR-related discussions I have seen people seriously questioning whether you can keep a basic server log with IP addresses in it of the kind that every web server has generated by default for decades. Often there are suggestions that such logs must be automatically deleted after a short period or the IP addresses masked in order to be compliant. And yet having records of which addresses were doing what on your site can be useful information for security and fraud prevention purposes months or even years after the records were originally created. So who is right? GDPR doesn't actually say and as far as I'm aware neither have any of the relevant data protection authorities yet so if you're running a site with these security concerns but also making an honest attempt to be compliant then you literally have no way to know how far you're allowed to go without crossing a line and upsetting a regulator.
That's just one everyday example that would probably apply to millions of different websites and that has been discussed many times but still with no clear answer. There are many more areas of ambiguity that even a well-intentioned organisation can easily run into. Backups and archives. Soft deletes when a user asks to delete something but you know for a fact that many users subsequently contact your support staff saying they've made a mistake and asking to restore the data. It's a long list with few clear answers.
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.
Twenty-eight independent data regulators on a complain-investigate model. I’ve seen folks bury early-stage competitors with regulatory inundation as an effective, if unethical, strategy. Zero chance Musk wouldn’t have armadas of randos complaining raining in on Threads.
For EU-based business: The DPA of your country is responsible for you.
For non-EU-based business: Appoint a representative in the EU. The DPA of that representative's country is responsible for you.
So where do the other 20+ DPAs come in? They might be responsible for your customers - in which case, they'll contact your DPA and sort it out among themselves. You still won't have to become an expert in the nuances of Bulgarian, Swedish and Portuguese privacy law.
> they'll contact your DPA and sort it out among themselves
No, they won’t. They’ll help you coördinate. You won’t have to become an expert in other bodies of law, but you will need to responsive to them, which is time consuming, distracting and—if you’re running a real business—expensive.
I’ve seen this deployed to remarkable efficacy, with asymmetry in defence:deployment cost in excess of 10:1.
