All your remaining points seem more easily solved than the backup bit, but I do not understand what could be so hard about deleting a user from a backup. Perhaps I'm dumb, but just go in there and delete it retroactively? If it affects other users, that's ok. They see a [deleted] a la Reddit.
You're not responsible for ensuring the API partners are in compliance. Those companies should have to fend for themselves.
When you delete everything you stored about a user, you also delete all potential personally identifiable information, so I again do not see what the problem is.
It just sounds like a bit of whining from where I am standing. It's like a small bridge builder saying "but the standards are too damn hard!". We start with the end goal of safe Bridges and safe users and then go backwards. Not the other way around.
The easiest way to comply with it would be have a list with all user deletion requests stored somewhere else and every time you restore from a backup, you also apply this list from the backup. But have you really deleted users if you keep backups?
It certainly sounds like the possibility of deleting all your users might actually make us all more careful, less gun-slinging, shoot-from-the-hip programmers.
I do backups for a living. I do them on tape, every day, and then once a month a trucks takes them to a dedicated safe. 6 backups are incremental, one is full. Please explain it to me how I'm going to delete one single user. Thank you.
You could also keep a record of "to-delete" primary keys in event of a restore along with your backups.
All of this should have been implemented a long time ago, some European countries demanded this already.
I am surprised by the lack of imagination of people if they don't want to implement something (too burdensome, technically impossible,...) who can come up with decent solutions if it fits them.
A little anecdote for this: Recently I wanted to buy some insurance. The insurance company demanded wide leeway in handling personal data which by law (in Germany) has to be opt-in. I returned the paperwork, explicitly stating that I do not consent to use of the data beyond what is strictly necessary for the contract. I was told that contract can be made only with consent and that I could revoke consent later (the latter is mandated by law. What a bull-shit show. I am looking forward to GDPR coming into effect to give these businesses a middle-finger.
Want to hoover up all available data, well then you'd better go to great lengths keeping it safe. Find yourself holding data that you now need to do something about? Delete it, unless it's business critical.
I really don't buy into this idea that the backups thing is that hard of a problem: if you're a startup, you'd design your infrastructure from the ground up with GDPR in mind which is going to put you in front of the competition and incumbents. Is it really, really, really that hard to have something that deletes stuff from backups? How long are we planning to keep backups anyways? Surely, when a user requests their data to be deleted it can be deleted from the main production database. Then when that db is backed up it'll overwrite previous versions (this new update then replicated out to other places) and just like that you've successfully (and easily) removed all applicable user data from all current db's and backups...
I understand your sentiment, but I think dismissing the issue of barrier to entries for small businesses is very shortsighted. Remember that excessive consolidation in the Internet industry is what led to the wholesale violation of consumer's privacy in the first place. So enforcing stricter data handling rules and protecting small businesses's ability to compete are two sides of the same coin. To truly protect consumers in the long run, regulators need to address both issues in a comprehensive way.
There is really no perfect way to do it, and it speaks to how unreasonable 'the right to be forgotten' actually is. When did people ever have a right to be forgotten? No one can force me to forget embarrassing things I've witnessed others do, and vice versa. The same goes for my local copies of photos, videos, diary entries, etc. of such events. Can't make me destroy those love letters you sent. You can't instigate a county-wide manhunt to destroy copies of every local newspaper that covered you in some way you want to forget. You cannot delete most of your public records in real estate, justice, business, etc. You cannot start fresh on your credit history whenever you want.
Sure, there is more easily accessible data on the average person with the Internet now, but the majority of the types of data already existed in the pre-Internet-era, perhaps with the exception of ad profiles. Consider all of the political scandals (particularly ones that happened long before they were unearthed) in the pre-Internet era.
So, what about when companies have data breaches and expose your data? I think they should absolutely be held liable. But it should be their choice to choose to be liable and determine how much they would need to forget to avoid liability. Furthermore, all of the active users are still compromised with GPDR -- only the people who opted to be forgotten benefit. So instead, there needs to be a framework for addressing data breaches and poor security, rather than deleting every trace of a specific type of data profile that a user and/or associated users posted on your platform.
> only the people who opted to be forgotten benefit
That is not true. One of the main points of GDPR is that you only store data as long as it is reasonable for your business. If I haven't been a customer at a store for 5 years, I can fully expect that my data has been deleted. How long reasonable is will be determined in the court, but I expect it is going to be in the customers favor.
Exceptions for slander and copyrighted information (e.g. photos) that were posted by other users? (or even regular content posted by the user that they 100% own) Absolutely -- but even in these cases, requiring that the third-party platform owners track down all potentially offensive content (much of which may be posted by other users) and then purge every layer of their backups after removing the offending content is overkill and shifts the responsibility away from the offender (whoever posted the content, even if it was the user himself) to the platform owner.
Ultimately, the ability to un-publish content you own that you published should be sufficient regulation-wise, and most popular platforms already enable that as a basic feature.
It's not about undoing participation in information sharing. GPDR does not require Wikipedia to delete everything I've contributed, but the fact that I have contributed is subject to be deleted if I request so. Furthermore, there must be explicit opt-in, and that is a good thing.
It's a trivial problem to purge from the backup, really. It's not a hard problem to solve. Many companies have done so before, and now we might even see standard tools to do so.
Rehabilitation of offenders act came into force in UK in 1974, so over 40 years.
Do it, that's fine. I'd prefer to know if you can't be trusted with my data.
People whined about HTTPS, it was often an afterthought. Now you wouldn't dream of submitting stuff via HTTP. GDPR will be the same, just on a business level instead of a technical one.
> What if a user enters in PII in a field that you thought should have no PII in it?
> What happens if you delete the user and restore from a 5 day old backup?
> What if they enter PII in table entries owned by other users through that other users account?
A lot of these are a red herrings, put in there to muddy the debate. Mistakes happen, the GDPR "punishments" acknowledge that. On the other hand, many companies already treat free-form user entered text as sensitive information. Everybody who's been neglecting privacy will have a bad time adopting this. Technical debt or over-complicated systems will also make it harder, but that is also to be expected.
> How do you ensure your third party API partners are in compliance?
If I had to guess, for many companies outside the EU, this is going to be the biggest issue.
One of my main issues with GDPR is the increased Red Tape. If I need customer data for whatever reason, extract data and deliver to Risarkivet (required by law every now and then), I must get a Data Processor Agreement. Fair enough, except if I need to do a different thing the customer asks me for, I need a new DPA. Only thing that'll happen is that we have a standard made by Datatilsynet, put in customer details and job detail, and that is it. A mail provides exactly the same, it could even reference the standard DPA. That just isn't accepted by the law. I guess middle managers need something to do as well.
After consultation with GDPR experts, this, unfortunately, is the conclusion we came to at my company as well - and is the same one that many other smaller companies will arrive at as they try to comply with this unwieldy and burdensome regulation. It might take a few years, but the incredibly unhealthy end result of this law will be two Internets: one that people in the EU have access to, which will mostly be operated by large companies that can afford to implement GDPR, and another including all sites that the rest of the world can access. My guess is that this will also have a significant negative impact on EU startup funding, as the risk of being wiped out by fines for even minor violations of this very complicated law that is subject to unique legal interpretations in each of 28 different countries is quite high. Few investors are going to take on that kind of risk.
In short, this law is already on track to create a fractured Internet that deprives EU citizens of access to the vast majority of Internet services, and consolidates the private data that their regulators are so worried about in the hands of a few giants.
Also, why does a company or anyone else "own" personally identifiable information in the first place? The logic is completely inverted and we seem to have all been OK with it in the first place. Why does a company like Facebook "own" what is mine from the beginning — is it just because it is in a row in their database? Is it because I once clicked OK on a TOS? Now I can revoke this consent and Facebook and others have to comply. Previously they could just tell me to FO. Sounds like a great win for users!
The issue isn't really even about any desire on the part of companies to abuse personal data. It comes down to the many ways that even companies with the best of intentions can violate this regulation.
It is also trivial to enforce a routine manual scrub of small amounts of private data.
The only people who might have trouble are "small" data resellers having millions of accounts of personal data. It is good they will have to comply.
If you're using a third party service, you will have to use it with prejudice. No more randomly including J. Random noncompliant Ad Agency as a middle man illegitimate handler and washing hangs of it.
Also URLs are perfectly fine as you're not processing the data. The thing that changes is that you have to specify which third party service you use and that it is externally managed. Probably link to their privacy policy and they also have to be compliant with GDPR. This will make it possible to actually get rid of the images and protect your privacy.
Guess where the air is purest?
Not the EU, that's for sure.
https://www.nytimes.com/2016/05/12/science/who-says-europe-t...
Archives should be pruned.
* User A requests to be deleted and is from prod.
* Deploy bad code between backup 1 and 2 - oh noes prod is corrupted!
* Restore backup 1, which restores user A
So - how doesn't this work for GDPR?
Now let's try to figure out that tricky backup problem!
Good one, hadn't even though of this. I planned on my VPN provider handling off-site backups for me, but this would mean I'm unable to delete a use from backups.
Does anybody have a solid solution for this?
It's not fucking hard, although a lot of people seem to be struggling with the concept of not hoarding data, or privacy in general.
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.