4 ms·

GDPR compliance will be tricky. How does one delete data?

okr 5y ago
You clone the database and remove/update the corresponding lines. GDPR does not mean, you have to fix it right away, imho.
- gnabgib 5y ago
  Article 17 does include the term "without undue delay"[0], but such vague language seems ripe for some court precedent. A clone and remove/update per GDPR request seems like undue delay, certainly one that could be avoided by alternative architecture choices (keep the personally identifiable information (PII) in a mutable store) [0]: https://gdpr-info.eu/art-17-gdpr/ https://gdpr-info.eu/art-17-gdpr/
  - deleted 5y ago
    [deleted]
  - sigzero 5y ago
    No, it's not undue delay. That's just how it currently works and that is a fine argument.
- peoplefromibiza 5y ago
  But you have to do in a pretty short timeframe > Under Article 12.3 of the GDPR, you have 30 days to provide information on the action your organization will decide to take on a legitimate erasure request. This timeframe can be extended up to 60 days depending on the complexity of the request. even if they ask for more time, first communication has to come within 30 days
  - topspin 5y ago
    So, no deadline for the actual deletion? Your 'first communication' could say "your data will be deleted at some point between now and ten years from now" and be compliant?
    - peoplefromibiza 5y ago
      No, it says: 30 days, maximum 60, if you need 60 you have to communicate it within the first 30 with a motivation. It looks pretty straightforward English to me. GDPR is published in 24 languages, including English, I don't know why people still don't get it and what's so hard to understand. It's not a single law, it's a collection of articles, the 17th says that data should be erased without undue delay. We don't have common law in Europe, EU is mostly civil law (emphasis on civil) or Romano-Germanic law. The only exception is Scandinavian law, which is very similar to (and a subgroup of) civil law anyway.
KarlKemp 5y ago
Pruning is on the roadmap.
- jquery 5y ago
  How is it immutable if you can prune it?
  - jeroiraz 5y ago
    several solutions may be possible. Simplest would be to delete payloads associated to entries. While the actual data won't be there, it will still be possible to build cryptographic proofs. Then it's possible to prune by physical deleting entire transaction data, which may or not affect proof generation. However, tampering will still be subject to detection.
    - jcims 5y ago
      Are records atomically immutable or is there a set concept such that the lack of mutation can be verified over a set of records?
      - jeroiraz 5y ago
        every change is made by appending a new transaction. immutability is intrinsic to transaction processing, it can not be disabled. Once a transaction (it may include several entries) is committed, the database state change accordingly and no change into already committed transaction may be done without clients being able to notice it. Note for this to be ensured, clients of immudb should keep track of the latest verified state. official sdks handle this for end-applications
fragmede 5y ago
Store the data encrypted, then delete the keys when requested.
- endisneigh 5y ago
  This isn't really deleting it though. What happens if in the future technology changes and current cryptography is moot?
  - nowherebeen 5y ago
    Then fire up a new database with the latest customer data every 18 months. And completely delete the old database once you confirm it no longer has value.
    - endisneigh 5y ago
      I thought the point of this is to have an exhaustive record for audit purposes.
    - cookiengineer 5y ago
      Or just store the customer database in /tmp and reboot the server every 18 months. /s
ledgerdev 5y ago
My preferred method is to tokenize sensitive data before storing in the immutable logs/database.
deleted 5y ago
[deleted]
jeroiraz 5y ago
currently it's logical deletion and time-based expiration. Actual values associated to expired entries are not fetched. Physical deletion is already in the roadmap.

okr 5y ago

You clone the database and remove/update the corresponding lines. GDPR does not mean, you have to fix it right away, imho.

gnabgib 5y ago
Article 17 does include the term "without undue delay"[0], but such vague language seems ripe for some court precedent. A clone and remove/update per GDPR request seems like undue delay, certainly one that could be avoided by alternative architecture choices (keep the personally identifiable information (PII) in a mutable store) [0]: https://gdpr-info.eu/art-17-gdpr/ https://gdpr-info.eu/art-17-gdpr/
- deleted 5y ago
  [deleted]
- sigzero 5y ago
  No, it's not undue delay. That's just how it currently works and that is a fine argument.
peoplefromibiza 5y ago
But you have to do in a pretty short timeframe > Under Article 12.3 of the GDPR, you have 30 days to provide information on the action your organization will decide to take on a legitimate erasure request. This timeframe can be extended up to 60 days depending on the complexity of the request. even if they ask for more time, first communication has to come within 30 days
- topspin 5y ago
  So, no deadline for the actual deletion? Your 'first communication' could say "your data will be deleted at some point between now and ten years from now" and be compliant?
  - peoplefromibiza 5y ago
    No, it says: 30 days, maximum 60, if you need 60 you have to communicate it within the first 30 with a motivation. It looks pretty straightforward English to me. GDPR is published in 24 languages, including English, I don't know why people still don't get it and what's so hard to understand. It's not a single law, it's a collection of articles, the 17th says that data should be erased without undue delay. We don't have common law in Europe, EU is mostly civil law (emphasis on civil) or Romano-Germanic law. The only exception is Scandinavian law, which is very similar to (and a subgroup of) civil law anyway.

KarlKemp 5y ago

Pruning is on the roadmap.

jquery 5y ago
How is it immutable if you can prune it?
- jeroiraz 5y ago
  several solutions may be possible. Simplest would be to delete payloads associated to entries. While the actual data won't be there, it will still be possible to build cryptographic proofs. Then it's possible to prune by physical deleting entire transaction data, which may or not affect proof generation. However, tampering will still be subject to detection.
  - jcims 5y ago
    Are records atomically immutable or is there a set concept such that the lack of mutation can be verified over a set of records?
    - jeroiraz 5y ago
      every change is made by appending a new transaction. immutability is intrinsic to transaction processing, it can not be disabled. Once a transaction (it may include several entries) is committed, the database state change accordingly and no change into already committed transaction may be done without clients being able to notice it. Note for this to be ensured, clients of immudb should keep track of the latest verified state. official sdks handle this for end-applications

fragmede 5y ago

Store the data encrypted, then delete the keys when requested.

endisneigh 5y ago
This isn't really deleting it though. What happens if in the future technology changes and current cryptography is moot?
- nowherebeen 5y ago
  Then fire up a new database with the latest customer data every 18 months. And completely delete the old database once you confirm it no longer has value.
  - endisneigh 5y ago
    I thought the point of this is to have an exhaustive record for audit purposes.
  - cookiengineer 5y ago
    Or just store the customer database in /tmp and reboot the server every 18 months. /s

ledgerdev 5y ago

My preferred method is to tokenize sensitive data before storing in the immutable logs/database.

deleted 5y ago

[deleted]

jeroiraz 5y ago

currently it's logical deletion and time-based expiration. Actual values associated to expired entries are not fetched. Physical deletion is already in the roadmap.