Comment by nwatson | Hacker News Reader

Comment by nwatson | Hacker News Reader

Parent Full thread

The GDPR question and "right to be forgotten", consent, etc., gets asked around this time in the Epicenter podcast with the founders: https://youtu.be/fdne9EvFNaw?t=3147

* Brian Platz addresses the question

* first goes through benefits of immutability in Fluree in context of auditing

* suggests one approach is storing PII (personally identifiable info) in encrypted manner in public fields, and storing the decryption keys separately -- the act of "forgetting" is the act of destroying the decryption keys

* another approach: on the public Fluree blockchain DB store a UID that has no public ties to PII ... and store the PII in a private corporate-side Fluree blockchain DB ... the Fluree system allows JOINs across Fluree systems, so internal corporate-side queries can do JOINs to consolidate public info with PII stored internally ... now to the "forgetting" part ... in spite of immutability guarantees, Fluree does have one escape, which is the possibility in the private Fluree (for which the corporation completely controls consensus) to "retract" that entity containing the PII, along with a tombstone and a full audit trail of the retraction

Both these approaches seem to address the right-to-be-forgotten pretty well. The Fluree guy also suggests that for the PII part perhaps Fluree isn't the system you want, and perhaps that should be stored in some other system.

That obviously solves the problem. But do you see an application where Fluree adds value over just storing everything in the private database that keeps your PII?

I imagine the most interesting and relevant parts of Fluree-based applications will be in the data apart from the PII, the data visible to anybody who wants to view or update that info.

Yeah, but what's an application where this would be useful? What kind of other data would the database store, and for what purpose?

Hmmm ...

* governments want to improve public health

* parents in a given geographic region can opt-in on birth of a child to enroll their child in a longitudinal data-gathering regime

* parents' and child's PII (personally identifiable information) is stored in a special private Fluree instance (or other DB), and each is assigned UIDs that can be public without disclosing their identity

* the child's UID, along with basic demographic info (that can't be used to resolve their identity) is pushed to the public Fluree DB ...

* some info, such as genetic profile, very specific outcomes of educational tests, etc., might be stored over time in a very secure DB not open to the public

* basic measures of health, education, nutrition, could be stored publicly and available to researchers ... with more and more info stored over time

* more info about a child's "history" that might be useful in correlating with positive / negative outcomes also might be stored publicly

* public health researchers could analyze trends, etc., to determine what education and nutrition programs, environments, etc., contribute positively to good outcomes

* public health and other researchers, such as medical, pharma, nutrition, etc., researchers, could use public data to find "cohorts" of children that might be suitable for studies ... and reach out in the system to families (whose identities will not be disclosed until appropriate) of those children to give them more info about why their child should become part of a study, and give them a chance to opt-in or contact researchers for more info

That's just one very interesting application off the top of my head, and Fluree (I'm not associated), as a Public Benefit Corporation (PBC) who states they eventually plan to open-source all or much of their technology, might be a good venue in which to deploy such a system ... a system that would require high levels of confidentiality, trust, while still being open to the extent possible and advisable.

Sorry, but I think this is one of the worst use-cases of a distributed database. Many government databases are, by definition, centralized, no matter what technology it uses. The record the government holds is the official record.

As a result, copies of the original document are pretty valuables unless they are certified by a court/agency as being official. Governments should definite move towards more modern databases and technology, but given that they "are" the central database, I don't see the benefit of decentralized one.

Leaving aside any questions of how much data you could actually make public without risk of depseudonymization, what benefit does this have over a 1998-vintage database-backed website run by the government? Like, the government licenses doctors and schools and such, so aren't they the central party controlling who can write to the database regardless?

What about accidental releases in the public network? We know it's just a matter of time before someone makes a mistake.

> the act of "forgetting" is the act of destroying the decryption keys

I'm not sure cryto-shredding is a legit method to "delete consumer data"

Why wouldn't it be? An encrypted file with the appropriate cipher set is synonymous with noise. It is only the encrypted content plus the unlock key that makes the file contents accessible.

If it is irretrievable, and the crypted data looks like noise, I would argue that the content is gone.

Especially if quantum computing develops enough to break modern encryption.

Unless the encryption uses post-quantum crypto, in theory it’ll all be “un-shredded” if quantum computing becomes feasible. We’ll have bigger problems at that point, but still, it’d make you “unforgotten”.

If I could favorite comments, I'd favorite this one.

You can. That's an option on HN. I think you need to click on it to find the "favorite" option.

Reply on news.ycombinator.com