Fork me on GitHub
#datomic
<
2021-11-25
>
Ivan Fedorov10:11:54

Any new developments regarding GDPR approaches since https://vvvvalvalval.github.io/posts/2018-05-01-making-a-datomic-system-gdpr-compliant.html? UPD: Talking about Cloud

stuarthalloway12:11:21

excision performance is much better now

Ivan Fedorov12:11:08

@U072WS7PE thanks! Any thoughts on if it’s better to excise data from cloud or store private fields in a separate KV storage? __ UPD my bad – my question was supposed to be Cloud specific

steveb8n20:11:25

+1. Cloud excision would make a complex solution much simpler for me too. Can we dare to hope?

jaret12:11:55

I want to clarify since the question was modified to being Cloud specific. Excision is not available in Cloud. We are well aware of the desire for a feature in this space and are continuing to evaluate options. As of now the GDPR advice is the same. Specifically, an approach that I see customers using is to use "encryption + throw away the key", storing personal data outside of Datomic in another store. Referencing the specific user information as needed and throwing away the key when asked to comply with GDPR.

steveb8n22:11:37

@U1QJACBUM thanks for the update. Using encryption creates all kinds of complexity e.g. where to store the key, query matching and sorting, etc. Is there a blog post or some guide on how to address these issues? As far as I’m aware, the simplest solution is to move GDPR data out of Datomic and into xtdb or similar. Running 2 dbs adds complexity as well so hoping to avoid that but I know that decision is coming for me. It’s stating the obvious but I figure it’s worth reiterating that this can force your customers away from Datomic.

Ivar Refsdal19:12:16

I wrote a library to have finer control over excision: https://github.com/ivarref/rewriting-history This is for on prem only though.