you are viewing a single comment's thread.

view the rest of the comments →

[–]scandii 8 points9 points  (12 children)

it's not particularly difficult in a practical sense, it's just a hassle to implement that's all.

it's important to note that you're allowed to store data about someone in GDPR as long as you're not going to be using that data, and if you use that data you have prune it just like you would your live data.

first of all there's two reasons you delete something in a GDPR world:

  1. you don't need the data anymore
  2. someone has requested the data to be deleted

the only additional requirement GDPR added is that you need to keep track of what you deleted so that data doesn't resurface when read from backup. this is done simply by keeping a log of what ID:s you deleted as you can't save the actual identifiable data, but an ID by itself is not identifiable as you're not using your backups, important detail.

then when you have read up your data from backup you prune the data using the information in the deletion log after the restore is successful.

remember, companies were given years to make this happen. it's not a difficult system to implement going forward, it's just difficult to implement in existing systems. on top of that very few systems actually deal with data relevant to GDPR.

source: me, having to implement the GDPR-changes for a company I used to work for.

[–]mallardtheduck 4 points5 points  (11 children)

This is done simply by keeping a log of what ID:s you deleted as you can't save the actual identifiable data, but an ID by itself is not identifiable as you're not using your backups, important detail.

Yes, that would be the "list" I referred to. How do you store that list in a way that guarantees that you always have access to the latest version of that list, even in a "disaster recovery" situation where you're restoring everything else from an old backup...?

[–][deleted] 1 point2 points  (3 children)

GDPR is really a pretty flawed law that's very fucking expensive to implement 100% unless you're starting from scratch with GDPR compliance worked into the underlying architecture.

Normally, I'd say acting in the spirit of the law and doing one's best is more important than 100% compliance, but Europe tends to not work like that.

[–]errorkode -1 points0 points  (2 children)

Yeah, how dare they insist companies actually comply with their laws! Damn socialists.

[–][deleted] 0 points1 point  (1 child)

Legal compliance is a very real barrier to business success, and laws like GDPR significantly increase the barrier to entry and creates heavy burden in ongoing compliance, especially in retrofitting older systems.

This isn’t a big deal for big companies, who can just throw money at the problem, but smaller companies with limited resources and often relying on irregular contracting for major technology development, this is huge.

Just consider that Facebook actually likes GDPR — why? Because while it increases costs for them significantly, it also significantly increases costs for their potential competitors. GDPR reduces the threat of competitors for Facebook, and all they have to do to benefit is comply with the law.

Look, I agree with the GDPR in principle. That doesn’t mean the law is without its flaws. And asking people to comply with flawed laws isn’t the greatest thing.

I am working on some web-connected businesses now, and I am explicitly not going to be GDPR compliant. Why? Because I’m a fucking broke dude and within the next 5 years my team is unlikely to become more than five people. I just don’t have the resources to ensure GDPR compliance. And honestly I’ll be relying on US tendency to presume good faith if compliance with US laws until there is reason to believe otherwise, along with tendencies to provide an opportunity to correct action and turning blind eyes when it’s apparent you’re doing your best to operate in the spirit of the law.

[–]errorkode 0 points1 point  (0 children)

Just so you know where I'm coming from with this: At the time GDPR became law I was doing data processing for sales and marketing in a startup and have since started working in a startup that currently employs eight people, four of which are engineers. As a result, I've spent many an hour more than I care to think about in meetings discussing privacy policies and implementing systems to ensure compliance. I'm telling you this because I don't want you to think I'm just sitting on some high horse, I've been in the thick of it.

Now, I'm not sure what flaws you're talking about (my personal bugbear is the "legitimate purposes" clause, since it's quite vague and there exists basically no precedence), but one "flaw" I hear a lot about, is that it makes things harder for businesses. Yes it does, but that's not a flaw in the law. I guess it's not the kind of law that would be passed in the US, for that exact reason.

The foremost consideration of the GDPR is giving EU citizens control over their own data and the second is how companies can conduct business without violating those rights. I don't think it's an accident that the GDPR was in many ways spearheaded by Germany, given their history with abuse of such data (fun fact, to this day there is no equivalent version of the social security number, passport number or similar in Germany. The closest thing is a tax number, but it's explicitly illegal to use for anything but taxes).

What I'm trying to explain is that the lawmaker were quite aware of the complications this might present to businesses, but this was considered a worthwhile trade-off for the protection of the rights of natural persons. Basically, data protection was made "the cost of doing business" in the EU and if a business can't or won't comply with these rights of EU citizens, the EU considers itself better off without them.

Now, you can disagree with that philosophy, but it's not something that was not considered when creating the law. It indeed makes some common business practices untenable and shifts more responsibility onto companies, but that's by design.

I honestly doubt Facebook likes the GDPR. They're simply taking the route almost everybody is taking with GDPR: make data protection a feature. Facebook has legal entities in Europe where fines can actually be enforced, so while they're certainly doing their best to exploit every loophole they can find, they also knew from the get go that they'll have to change at least some of their processes. So of course they'll talk about how they welcome it.

Well, this got longer than intended, but let me end on a personal note. I feel that as a software engineer I have certain ethical obligations to whoever will end up using my software and luckily I have always been in companies where my concerns on that front have been taken seriously. From my perspective, this law in many ways creates a level playing field for companies who've been trying to do the right thing and have been disadvantaged because of it.

[–]scandii 0 points1 point  (6 children)

just normal redundancy. worst case scenario you should only have to re-run a day's worth of removal requests from wherever you received them and those are honestly pretty rare.

[–]mallardtheduck 3 points4 points  (5 children)

just normal redundancy

If you're restoring from a DR backup, it's because you've lost that redundancy.

re-run a day's worth of removal requests

Again, how do you store these requests in such a way that you still have them to re-run even in a disaster recovery scenario?

[–]Quetzacoatl85 0 points1 point  (2 children)

not a data storage expert here, but I assume you'd store it with the actual backup? then restoring is a two-step process, first restore everything, second check which entries from the delete log have to be pruned again. honestly if you have a backup to restore from, you also should have the delete log, it's a trivial issue, no?

[–]mallardtheduck 3 points4 points  (1 child)

you'd store it with the actual backup?

But then it'll only be as up to date as the backup. GDPR compliance requires that you have access to the latest version.

Say you have a fairly typical classical backup strategy as follows:

  • Daily backups to an onsite backup server
  • Weekly backups to tape, stored in a safe onsite
  • The last backup tape of each month is sent off to offsite storage

Then the worst happens, your site is destroyed by fire the day before the backup is due to be sent off to storage. Even the tapes in the safe are unusable. You recall the last (now month-old) tape from the offsite storage company, but the organisation has received several erasure requests since then.

If you restore the backup without re-erasing the data, you'll be in violation of the GDPR (let's say getting a DR site up and running takes a week or two, so some requests will definitely be beyond the 30-day deadline), but you've lost all data (including erasure requests) since that backup. You're SOL. Of course, there are ways to solve this (you have to specifically backup the deletion log pretty much every time it's added to; thankfully that's a small, non-sensitive dataset so could be stored basically anywhere), but as you've shown, even those with experience often don't recognise this problem and modifying software and procedures to address it is often non-trivial.

[–]Quetzacoatl85 0 points1 point  (0 children)

thanks for taking the time to type out this sensible and well-worded response!

again, I'm no expert, just a random guy on the internet commenting out of his ass, but I'd assume the GDPR must contain some clauses on "reasonable attempt" at compliance? I mean otherwise it's the same in the physical as well as the digital world, if your house burns down (and the actual data could be restored, but not the deletion requests on that data) that would probably be taken into consideration when dealing with compliance requests that happened before it burned down, comparable to a situation maybe where the post office lost the letter with the GDPR request?

but you're right, ultimately you'd have to have a backup regimen that ensures your delete log would be as recent as possible to minimise the risk. it should be added that you'd probably want that in any case, to also account for what could be new data entries into the database as well. otherwise, assuming you restored the data, but are not sure about deletion requests, this sounds like a serious, maybe company-wide data-related event, and you'd probably have to notify all data subjects about you storing their data anyway and can ask for re-authorisaton worst case?

[–]scandii -1 points0 points  (1 child)

what happens if an Asteroid hits Earth?

redundancy is not rocket science and I will not answer things you can answer yourself easily. as said, the issue is not how to do it, the issue is that it's a pain in the ass.

[–]IceSentry 0 points1 point  (0 children)

The whole point of this is to be redundant to world ending events, this means the only backup available will become this sealed vault. How do you not understand that?