4 ms·

It's not clear how to implement 'right to be forgotten' inside backed-up data, too.

by mappu 9y ago

geocar 9y ago
It’s pretty easy: just don’t restore their data. Most businesses with personal data also have invoices. Since you don’t have to destroy those, simply note their request there. Other kinds of personal data like marketing leads and medical data should be much easier to see how to forget.
- hamandcheese 9y ago
  That isn’t easy from a technical perspective. The whole point of a backup is to restore to a state from a previous point in time... now they want future state (the “right to be forgotten” request) to modify how a backup should be restored?
  - geocar 9y ago
    No. The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
    - hamandcheese 9y ago
      > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And to then restore to a point in time before the software or hardware bugs occurred, no? > A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Um what? There are ton of good reasons to stick to a single DB, it’s not unreasonable at all. The main one being that it massively simplifies ensuring data integrity compared to a distributed system. Also it’s just easier for a small team to manage.
      - geocar 9y ago
        A single point of failure isn't a good way to protect people's personal data that you have, but even small teams are unlikely to have a single golden source of data. Data tends to flow from one system into another. For example: If someone sends you an email asking to be deleted, why would you store that email in the DB and nowhere else? Your team would read the email then update the database. After a crash, if you then restored a backup, why wouldn't you be able to review your last days email (since the last backup) for any updates? Of course you would. Even small teams could.
    - Silhouette 9y ago
      If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. "Who's IT?" -- Small and micro-businesses across Europe This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. "We can't even afford a GDPR consultant. And who's IT?" -- Small and micro-businesses across Europe A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Again, this is simply detached from the reality of many, many small and microbusinesses, community organisations, non-profits, etc. It's absurd to think that every organisation that has reasonable need to handle personal data has a dedicated IT team, the people and budget to drop a few thousand on professional advice, the budget to buy extra equipment that isn't otherwise needed, etc. It's also absurd to think that without those things, an organisation can't take reasonable precautions to protect that data or prevent its exploitation for illegitimate purposes. Unfortunately the GDPR (as often happens with EU legislation) makes little allowance for any of this and thus imposes absurdly disproportionate overheads on smaller organisations.
      - geocar 9y ago
        A flower shop owner who runs his own website off a laptop in his shop unattended but plugged into his DSL using Microsoft Personal web Server and Windows 98, who records customer data in that form without explaining to his customers that he's a fucking idiot deserves what he gets. It's a shame perhaps that the European courts probably won't bother with him. But the photographer that hosts her website and help forms on wix[1] isn't going to have any problems. The local restaurant using viewtouch PoS and a facebook page isn't going to have any problems[2]. [1]: https://support.wix.com/en/article/general-data-protection-regulation-gdpr https://support.wix.com/en/article/general-data-protection-r... [2]: https://www.facebook.com/business/news/facebooks-commitment-to-data-protection-and-privacy-in-compliance-with-the-gdpr https://www.facebook.com/business/news/facebooks-commitment-... Very few real people will have any problems, because the GDPR is fundamentally about tradeoffs: If you have a lot of personal data, you need to protect it and inform the subject what you do with it. If you can't afford to protect it and think that the subject wouldn't want you doing what you're doing with their data, then you probably shouldn't have that personal data.
    - eadmund 9y ago
      > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And process bugs/defects. And human error. Human error such as, for example, 'delete all of Mr. Smith's records.'
      - geocar 9y ago
        Sure. And if that same human error can also delete all the email and postal mail that Mr. Smith sent to your company, then your IT team is criminally irresponsible.
tyler_larson 9y ago
Encrypt all person-specific data with the a key unique to that person, and if the person requests deletion, delete the key. This effectively deletes all backups.
- mappu 9y ago
  Help me understand - that seems like it just centralizes the problem. Since the key is now PII-equivalent, how is the key storage backed up?
  - the_mitsuhiko 9y ago
    Revolving backups and you throw away old ones. After 30 days or so theast traces of a customer’s keys will be gone.
    - mappu 9y ago
      In that situation, the data is "inaccessible" but a data breach during the backup retention period will still leak their details. We can already achieve that result by removing records from the live DB and ignoring the whole backup situation. So what has this separate encryption process achieved?
      - the_mitsuhiko 9y ago
        It has achieved that within a time frame PII of a user are removed from backups.
the_mitsuhiko 9y ago
How so? The solution is pretty straightforward: encryption with a per customer key that can be discarded.
- Silhouette 9y ago
  For many businesses that won't be straightforward, it will be rocket science. Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example.
  - the_mitsuhiko 9y ago
    > Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example. But do you need to keep them forever? If you delete logs after 30 days you are unlikely to be impacted anyways.
    - Silhouette 9y ago
      We have server logs going back for years. Moreover, those older server logs have provided valuable information on several occasions for detecting abuse of our systems, attempted fraud, etc, so they are demonstrably useful for legitimate business purposes. We also have backups going back on a staged basis, more frequent backups from the recent past, less frequent going back further. This has been useful more than once for retrieving older information that someone had accidentally modified or deleted and not noticed immediately, so is also demonstrably useful for legitimate business purposes. Both of these appear to be at risk of conflict with the right to erasure under GDPR, in that for example old backups of emails will inevitably contain customer correspondence that can't readily be isolated.

It's not clear how to implement 'right to be forgotten' inside backed-up data, too.

by mappu 9y ago

It's not clear how to implement 'right to be forgotten' inside backed-up data, too.

It’s pretty easy: just don’t restore their data. Most businesses with personal data also have invoices. Since you don’t have to destroy those, simply note their request there. Other kinds of personal data like marketing leads and medical data should be much easier to see how to forget.

hamandcheese 9y ago
That isn’t easy from a technical perspective. The whole point of a backup is to restore to a state from a previous point in time... now they want future state (the “right to be forgotten” request) to modify how a backup should be restored?
- geocar 9y ago
  No. The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
  - hamandcheese 9y ago
    > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And to then restore to a point in time before the software or hardware bugs occurred, no? > A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Um what? There are ton of good reasons to stick to a single DB, it’s not unreasonable at all. The main one being that it massively simplifies ensuring data integrity compared to a distributed system. Also it’s just easier for a small team to manage.
    - geocar 9y ago
      A single point of failure isn't a good way to protect people's personal data that you have, but even small teams are unlikely to have a single golden source of data. Data tends to flow from one system into another. For example: If someone sends you an email asking to be deleted, why would you store that email in the DB and nowhere else? Your team would read the email then update the database. After a crash, if you then restored a backup, why wouldn't you be able to review your last days email (since the last backup) for any updates? Of course you would. Even small teams could.
  - Silhouette 9y ago
    If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. "Who's IT?" -- Small and micro-businesses across Europe This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. "We can't even afford a GDPR consultant. And who's IT?" -- Small and micro-businesses across Europe A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Again, this is simply detached from the reality of many, many small and microbusinesses, community organisations, non-profits, etc. It's absurd to think that every organisation that has reasonable need to handle personal data has a dedicated IT team, the people and budget to drop a few thousand on professional advice, the budget to buy extra equipment that isn't otherwise needed, etc. It's also absurd to think that without those things, an organisation can't take reasonable precautions to protect that data or prevent its exploitation for illegitimate purposes. Unfortunately the GDPR (as often happens with EU legislation) makes little allowance for any of this and thus imposes absurdly disproportionate overheads on smaller organisations.
    - geocar 9y ago
      A flower shop owner who runs his own website off a laptop in his shop unattended but plugged into his DSL using Microsoft Personal web Server and Windows 98, who records customer data in that form without explaining to his customers that he's a fucking idiot deserves what he gets. It's a shame perhaps that the European courts probably won't bother with him. But the photographer that hosts her website and help forms on wix[1] isn't going to have any problems. The local restaurant using viewtouch PoS and a facebook page isn't going to have any problems[2]. [1]: https://support.wix.com/en/article/general-data-protection-regulation-gdpr https://support.wix.com/en/article/general-data-protection-r... [2]: https://www.facebook.com/business/news/facebooks-commitment-to-data-protection-and-privacy-in-compliance-with-the-gdpr https://www.facebook.com/business/news/facebooks-commitment-... Very few real people will have any problems, because the GDPR is fundamentally about tradeoffs: If you have a lot of personal data, you need to protect it and inform the subject what you do with it. If you can't afford to protect it and think that the subject wouldn't want you doing what you're doing with their data, then you probably shouldn't have that personal data.
  - eadmund 9y ago
    > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And process bugs/defects. And human error. Human error such as, for example, 'delete all of Mr. Smith's records.'
    - geocar 9y ago
      Sure. And if that same human error can also delete all the email and postal mail that Mr. Smith sent to your company, then your IT team is criminally irresponsible.

tyler_larson 9y ago

Encrypt all person-specific data with the a key unique to that person, and if the person requests deletion, delete the key. This effectively deletes all backups.

mappu 9y ago
Help me understand - that seems like it just centralizes the problem. Since the key is now PII-equivalent, how is the key storage backed up?
- the_mitsuhiko 9y ago
  Revolving backups and you throw away old ones. After 30 days or so theast traces of a customer’s keys will be gone.
  - mappu 9y ago
    In that situation, the data is "inaccessible" but a data breach during the backup retention period will still leak their details. We can already achieve that result by removing records from the live DB and ignoring the whole backup situation. So what has this separate encryption process achieved?
    - the_mitsuhiko 9y ago
      It has achieved that within a time frame PII of a user are removed from backups.

the_mitsuhiko 9y ago

How so? The solution is pretty straightforward: encryption with a per customer key that can be discarded.

Silhouette 9y ago
For many businesses that won't be straightforward, it will be rocket science. Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example.
- the_mitsuhiko 9y ago
  > Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example. But do you need to keep them forever? If you delete logs after 30 days you are unlikely to be impacted anyways.
  - Silhouette 9y ago
    We have server logs going back for years. Moreover, those older server logs have provided valuable information on several occasions for detecting abuse of our systems, attempted fraud, etc, so they are demonstrably useful for legitimate business purposes. We also have backups going back on a staged basis, more frequent backups from the recent past, less frequent going back further. This has been useful more than once for retrieving older information that someone had accidentally modified or deleted and not noticed immediately, so is also demonstrably useful for legitimate business purposes. Both of these appear to be at risk of conflict with the right to erasure under GDPR, in that for example old backups of emails will inevitably contain customer correspondence that can't readily be isolated.