111–120 of 183 posts
Earlier quoted context omitted.
Your data modelling has to be GDPR compliant not your database.
How do you delete user data from an immutable store? You get into cryptography at that point and then some edge cases make it not so simple.
Earlier quoted context omitted.
You can use cryptoshredding: have an encryption key for each user (stored outside of this ledger) and encrypt all PII with that key. Throw away the key if the user wants you to delete their data.
But then you must also plan for what happens when that encryption is broken. So I think you also need to control and protect your storage in order to make that a safe strategy. The more I think about these things, the more I distrust cloud providers, and want my own hardware. Do you really trust these companies enough to hand them the keys to all your data? Is there really any way to provide secrets to your app witho…
Uhm... If some of my data is stored in one instance of that database and I then ask the owning company to delete such data in accordance to , say, GDPR... What happens ?
There's probably also an option for not keeping history for data that it doesn't make sense to have history for.
Earlier quoted context omitted.
You can use cryptoshredding: have an encryption key for each user (stored outside of this ledger) and encrypt all PII with that key. Throw away the key if the user wants you to delete their data.
What if the key leaked before you have thrown it away?
Is it possible to comply with GDPR while using this to store data? Given that it operates like an append-only log, is it possible to actually remove data to comply with a GDPR request?
But you probably wouldn't store sensitive user data in this kind of database anyway. Not ever use case is well-suited for a ledger like this. In most applications, this would be pointless overhead.
Earlier quoted context omitted.
What if the key leaked before you have thrown it away?
That's a good question! If your keys leaked, you'd probably have to assume you lost all of the data up to that point. To secure the data going forward, you'd need to generate a second key per user for all of the future data. Well, and hopefully shore up the security problems! I agree, though, that an immutable ledger like this complicates things in a way that you-shouldn't-mutate-but-can datastores do not.
I'm currently working on this problem in application to blockchains. The plan ATM is to implement cryptographic snapshots of the data, where the old transactions are erased but their proof is available.
Is it possible to comply with GDPR while using this to store data? Given that it operates like an append-only log, is it possible to actually remove data to comply with a GDPR request?
You can use cryptoshredding: have an encryption key for each user (stored outside of this ledger) and encrypt all PII with that key. Throw away the key if the user wants you to delete their data.
Why all of the Amazon spam? Three advertisements in 6 hours.
Especially when it's the biggest cloud provider that many of us depend on.