36 ms·

Merely setting a delete flag is not compliant with the GDPR, that's why a cascading delete is necessary. Any programmer worth their salt knows mass random delet

Merely setting a delete flag is not compliant with the GDPR, that's why a cascading delete is necessary. Any programmer worth their salt knows mass random deletes and updates are extremely inefficient.

yzmtf2008 8y ago
I encourage you to read my comment again, and point out where I mentioned merely setting a delete flag. Any reader worth their salt will point out that it’s not what I suggested at all.
- codexon 8y ago
  "you could easily not switch to a CASCADE, but instead set delete=1 and mark every sensitive field with a special value"
  - dbpatterson 8y ago
    you ignored "and mark every sensitive field with a special value", which is the key part. As long as all sensitive data has been essentially zero'd out (for some value of zero), all is fine.
    - codexon 8y ago
      Marking a field sounds to me like labeling and not zeroing it out.
  - jachee 8y ago
    What if "a special value" == NULL?
    - namibj 8y ago
      If you choose that value, and it's the only, or one of the few values that break your software, then it's your fault.
- alexbecker 8y ago
  I believe the confusion is around your statement "mark every sensitive field". I think you mean "overwrite every sensitive field", but that definitely took a re-reading to infer, and I'm still not 100% sure.
  - yzmtf2008 8y ago
    Thanks, the processs reminded me of the “redaction” process, so I used mark. That’s definitely on me. Clarified.
dboat 8y ago
To your post specifically, I think a cascade of "zero outs" or the like to blank out a user's data would be sufficient is it not? It could happen at most once for each user account so it shouldn't be ruinously inefficient unless a system was already on the verge of collapse. But on the topic in general, could someone explain to me what the real world consequences are likely to be for a small business not based in the EU, of not complying? If I've never cared where my users were as long as their payments cleared (oh, is that where they get you? the payment processor?), and I'm selling handcrafted bobbins online in Canada without letting people delete their email address, what is likely to happen if someone complains to EU authorities?
- codexon 8y ago
  That would make it compliant but there will still be efficiency problems. Databases such as Cassandra are made so that updating doesn't actually delete the old data until some time later so frequent updates will degrade performance and storage. Other databases that allow for immediate overwriting the data will cause fragmentation and thus performance decline and wasted storage until you compact (basically recreating the entire database) which is not something you want to do all the time, especially on SSDs.
  - Dylan16807 8y ago
    It's not frequent updates to delete a piece of data once in its lifetime. If it takes a week to garbage collect that's fine, it just can't stick around forever.
    - codexon 8y ago
      The problem isn't to delete 1 piece of data 1 time. The problem is different people demanding thousand+ rows randomly spread out in your database deleted every day that is the problem.
      - Dylan16807 8y ago
        Is deleting an arbitrary set of rows every fortnight such a problem?
yzmtf2008 8y ago
HN won’t let me go deeper, so here it goes: > "you could easily not switch to a CASCADE, but instead set delete=1 and mark every sensitive field with a special value" Emphasize on the part after “and”
- sunir 8y ago
  That is insufficient. You can still infer identities through metadata and behavioural analysis. For instance purchase history and geolocation is often enough to identify some individuals.
stemuk 8y ago
Wouldn't it be possible to just delete the 'idetifiabel' parts in the database in order to be GDPR compliant? If you for instance save all the user data like user preferences under a random userId, and then delete the personal data (such as email address, name etc.) associated with the userId I would expect this to be GDPR complaint without having to do a cascading delete.
- sunir 8y ago
  That it isn’t known with confidence is your answer to whether it is worth implying it is easy.
- pilsetnieks 8y ago
  If you're absolutely certain that the user's identity cannot be reconstructed from the remaining data points, then yes, a full anonymization is enough. You are, after all, removing personally identifiable information, even if the record structure remains in your database. It's a law, not a technical constraint. No one gives a fuck about some foreign key relations, they care that personal data cannot be accessed, or somehow reconstructed.
- lagadu 8y ago
  Anonymizing like that would be GDPR compliant yes, as long as the remaining information absolutely cannot be used to identity the original subject.
- ianamartin 8y ago
  Yes, but this is actually more difficult than you think. It doesn't take very many data points to ID a user.
- wlll 8y ago
  This may well be harder to get right than just deleting the data. Just as in the saying (and this is a terrible paraphrase) goes: "Anyone can design a lock that they themselves can't pick" If you think you have anonymised data sufficiently you may well not have done it sufficiently to prevent others from re-conctructing it: https://en.wikipedia.org/wiki/AOL_search_data_leak https://en.wikipedia.org/wiki/AOL_search_data_leak
cygned 8y ago
The thing is, affected persons can not only request a data deletion, but also the pausing of data processing. In that case, you are not allowed to delete them but they must not be used any longer, which is essentially a soft delete. So to be compliant, you’d have to implement both a soft and a hard delete.
CaptainZapp 8y ago
I read a lot about cascading deletes, which I interpret as holding personally identifiable data redundantly. I can see two reasons why this would be a problem: You have a really shitty un-normalized database design. Granted that you may have to denormalize specific columns for performance reasons. But why that would be the case with, for example names, phone numbers or sexual preferences, totally escapes me. Or, you're referring to actual cascading deletes, meaning that you need to get rid of child relations, based on deletion of the parent relation. If this poses a problem then I'd argue that you're guilty of a shitty database implementation, arguably with criminally bad definition of your primary / foreign key pairs. I really don't see a problem here, unless the database schema is implemented in a totally incompetent manner. Edit: Clarity
tensor 8y ago
A cascading delete is not necessary. You need only to remove personal information, not all information. Now if you are producing an application that only contains personal information like a chat app, then sure, you might need to remove everything. But often all you need to do is overwrite the name, address, or similar bits of information, and you can then leave the rest of the data intact and set your delete flag.

yzmtf2008 8y ago

I encourage you to read my comment again, and point out where I mentioned merely setting a delete flag. Any reader worth their salt will point out that it’s not what I suggested at all.

codexon 8y ago
"you could easily not switch to a CASCADE, but instead set delete=1 and mark every sensitive field with a special value"
- dbpatterson 8y ago
  you ignored "and mark every sensitive field with a special value", which is the key part. As long as all sensitive data has been essentially zero'd out (for some value of zero), all is fine.
  - codexon 8y ago
    Marking a field sounds to me like labeling and not zeroing it out.
- jachee 8y ago
  What if "a special value" == NULL?
  - namibj 8y ago
    If you choose that value, and it's the only, or one of the few values that break your software, then it's your fault.
alexbecker 8y ago
I believe the confusion is around your statement "mark every sensitive field". I think you mean "overwrite every sensitive field", but that definitely took a re-reading to infer, and I'm still not 100% sure.
- yzmtf2008 8y ago
  Thanks, the processs reminded me of the “redaction” process, so I used mark. That’s definitely on me. Clarified.

dboat 8y ago

To your post specifically, I think a cascade of "zero outs" or the like to blank out a user's data would be sufficient is it not? It could happen at most once for each user account so it shouldn't be ruinously inefficient unless a system was already on the verge of collapse. But on the topic in general, could someone explain to me what the real world consequences are likely to be for a small business not based in the EU, of not complying? If I've never cared where my users were as long as their payments cleared (oh, is that where they get you? the payment processor?), and I'm selling handcrafted bobbins online in Canada without letting people delete their email address, what is likely to happen if someone complains to EU authorities?

codexon 8y ago
That would make it compliant but there will still be efficiency problems. Databases such as Cassandra are made so that updating doesn't actually delete the old data until some time later so frequent updates will degrade performance and storage. Other databases that allow for immediate overwriting the data will cause fragmentation and thus performance decline and wasted storage until you compact (basically recreating the entire database) which is not something you want to do all the time, especially on SSDs.
- Dylan16807 8y ago
  It's not frequent updates to delete a piece of data once in its lifetime. If it takes a week to garbage collect that's fine, it just can't stick around forever.
  - codexon 8y ago
    The problem isn't to delete 1 piece of data 1 time. The problem is different people demanding thousand+ rows randomly spread out in your database deleted every day that is the problem.
    - Dylan16807 8y ago
      Is deleting an arbitrary set of rows every fortnight such a problem?

yzmtf2008 8y ago

HN won’t let me go deeper, so here it goes: > "you could easily not switch to a CASCADE, but instead set delete=1 and mark every sensitive field with a special value" Emphasize on the part after “and”

sunir 8y ago
That is insufficient. You can still infer identities through metadata and behavioural analysis. For instance purchase history and geolocation is often enough to identify some individuals.

stemuk 8y ago

Wouldn't it be possible to just delete the 'idetifiabel' parts in the database in order to be GDPR compliant? If you for instance save all the user data like user preferences under a random userId, and then delete the personal data (such as email address, name etc.) associated with the userId I would expect this to be GDPR complaint without having to do a cascading delete.

sunir 8y ago
That it isn’t known with confidence is your answer to whether it is worth implying it is easy.
pilsetnieks 8y ago
If you're absolutely certain that the user's identity cannot be reconstructed from the remaining data points, then yes, a full anonymization is enough. You are, after all, removing personally identifiable information, even if the record structure remains in your database. It's a law, not a technical constraint. No one gives a fuck about some foreign key relations, they care that personal data cannot be accessed, or somehow reconstructed.
lagadu 8y ago
Anonymizing like that would be GDPR compliant yes, as long as the remaining information absolutely cannot be used to identity the original subject.
ianamartin 8y ago
Yes, but this is actually more difficult than you think. It doesn't take very many data points to ID a user.
wlll 8y ago
This may well be harder to get right than just deleting the data. Just as in the saying (and this is a terrible paraphrase) goes: "Anyone can design a lock that they themselves can't pick" If you think you have anonymised data sufficiently you may well not have done it sufficiently to prevent others from re-conctructing it: https://en.wikipedia.org/wiki/AOL_search_data_leak https://en.wikipedia.org/wiki/AOL_search_data_leak

cygned 8y ago

The thing is, affected persons can not only request a data deletion, but also the pausing of data processing. In that case, you are not allowed to delete them but they must not be used any longer, which is essentially a soft delete. So to be compliant, you’d have to implement both a soft and a hard delete.

CaptainZapp 8y ago

I read a lot about cascading deletes, which I interpret as holding personally identifiable data redundantly. I can see two reasons why this would be a problem: You have a really shitty un-normalized database design. Granted that you may have to denormalize specific columns for performance reasons. But why that would be the case with, for example names, phone numbers or sexual preferences, totally escapes me. Or, you're referring to actual cascading deletes, meaning that you need to get rid of child relations, based on deletion of the parent relation. If this poses a problem then I'd argue that you're guilty of a shitty database implementation, arguably with criminally bad definition of your primary / foreign key pairs. I really don't see a problem here, unless the database schema is implemented in a totally incompetent manner. Edit: Clarity

tensor 8y ago

A cascading delete is not necessary. You need only to remove personal information, not all information. Now if you are producing an application that only contains personal information like a chat app, then sure, you might need to remove everything. But often all you need to do is overwrite the name, address, or similar bits of information, and you can then leave the rest of the data intact and set your delete flag.