As a hacker, I enjoy the spirit of the thing. It’s nowhere near as dumb as the cookie pop-up law. Categorically I would prefer default third party services to flush logs rather than retain.
As a founder, the cruel business logic very much favors removing support/refusing to onboard European users.
Your exposure is in a fine for 4% of global revenue or 20 million euros. Whichever is greater. No big deal. Europe may make up 10% of your revenue. The effort is going to decrease resources by 20%+ in the short term, add unknown long term complexity and overhead, and longer term employing a compliance officer. Also can we go back to the 20 million Euro fine thing for a second? Any potential acquirer is going to want to double down on diligence before assuming risk like that.
The requirements initially seem innocent enough - ability to hard delete/export user history. Easy right. Some notes from my meeting with legal:
Well what about backups? Do you retroactively go through your backups and remove R2BF users? Do you only keep backups for 6 days? What happens if you delete the user and restore from a 5 day old backup? Do you keep a second list of users who requested you delete their data - and if so how do you store that? How do you now represent activity that materially effected other users still on the platform? Is this subbed out with a “blank shadow” user? The legislation very much does not solve for the recursive logic of “how do you track users who’ve requested deletion”. Counter-intuitively we would now have to log more user activity so we can gracefully handle rendering deleted data. Why do we have to file with a third party that we’ve deleted info on a user that requested we remove all trace of them?? What if a user enter’s PII in table entries owned by other users through that other users account? What if they do it through a third party API? Speaking of, how do you ensure your third party API partners are in compliance? What if a user enters in PII in a field that you thought should have no PII in it? How do you treat EU citizens using your service outside the EU vs inside it? What if they use it in both places? What if you have an American user who happens to be located...
Sure most of these are solvable along with the another hundred edge cases not illustrated, but for bigger apps at 50+ person companies almost every one of those points is a bullet point in a meeting that requires nuanced development from multiple stakeholders. Don’t think it’s hard? Try roll into a meeting a Twitter and explain to them how easy it would be to add a button that lets you edit tweets. Some requirements are a BFD - you can imagine how things went over in a meeting where we half-jokingly suggested we no longer make backups rather than take on the burden of implementing a backup policy that may or may not be compliant with a new law that has no precedents in court to guide drafting a spec.
The net result is implementing it with the least effort and suddenly it’s just this dogpile of cludgey UI popover screens that people click through without reading and TOS updates and mandatory log outs and a lot of other things besides that add overhead to make it “non-trivial.”
It’s a big deal because pre-series A startups will choose to avoid these waters rather than navigate them.