Name: Translucent Databases
ISBN: 9780967584416

Translucent Databases

This is an introductory version of the widely acclaimed book that redefined how to build databases that protect the user's information. Instead of trying to store sensitive data in a tightly guarded box, the book describes simpler, faster and more secure solutions that leave the user in control of personal information. The trick to building a translucent database is scrambling the personal information in a way that only the right person can recover it. The book describes how traditional and not-so-traditional techniques can create a database that can answer questions for the right person without holding any useful information that might be abused by an insider or an attacker who manages to slip inside the fold. The abridged version of the second edition includes the six chapters that form the core of the book. All of the chapters include detailed descriptions of the algorithms and many descriptions include working code.

What Hacker News says

specialistJun 2024

This is why I advocate all PII data be encrypted at rest at the field level.

Worked on EMRs (during the aughts). Had yearly HIPAA and other security theater training. Not optional for any one in the field.

Of course we had root access. I forget the precise language, but HIPAA exempts "intermediaries" such as ourselves. How else could we build and verify the system(s). And that's why HIPAA is a joke.

Yes, our systems had consent and permissions and audit logs cooked in. So theoretically peeking at PII could be caught. Alas, it was just CYA. None of our customers reviewed their access logs.

I worked very hard to figure out how to protect patient (and voter) privacy. Eventually conceded that deanon always beats anon, because of Big Data.

I eventually found the book Translucent Databases. Shows how to design schemas to protect PII for common use cases. Its One Weird Trick is applying proper protection of passwords (salt + hash) to all other PII. Super clever. And obvious once you're clued in.

That's just 1/2 of the solution.

The other 1/2 is policy (non technical). All data about a person is owned by that person. Applying property law to PII transmutes 3rd party retention of PII from an asset to a liability. And once legal, finance, and accounting people get involved, orgs won't hoard PII unless it's absolutely necessary.

(The legal term "privacy" means something like "sovereignty over oneself", not just the folk understanding of "keeping my secrets private.)

thread

specialistMar 2024

You are emphatically, logically, ethically, technically, securely, and in all other ways correct.

Yes and:

> Encrypting data while at rest (in storage) as well as in-transit is the way to go.

All PII must be encrypted at rest at the field level.

Just like how passwords are properly stored. This is not rocket science.

The book Translucent Databases demonstrates this technique for common use cases. Highest recommendation.

https://www.amazon.com/Translucent-Databases-Peter-Wayner/dp...

thread

specialistSep 2023

> Fine paid directly to the individual. Make PII data property.

Correct. Specifically, establish personal sovereignty over one's data.

If someone's using my data, I get my cut. Pay me.

I'll have to ponder the notion of receipts (provenance).

I can imagine how the provenance of my data probably matters. Prescriptions, test results, reading list, etc.

But PII is so ubiquitous now, it's part of the public record. Which, counter intuitively, is a good thing.

Establishing a stable universal identifier unlocks the ability to encrypt our personal data at rest.

In our current world of no universal identifiers, linking personal data data across systems requires it be stored as plaintext.

The book Translucent Databases (2nd ed) explains the techniques.

thread

specialistMar 2022

Much needed. Great opportunity. Happy hunting.

> ...the API provides synthetic data samples with the same schema and statistical distribution by default

Neat. Repurposing test data generators. I like it.

> Our model is a software license to run on our clients’ cloud.

Just to confirm my understanding: Sarus never sees the client's data? Cool.

I'm fine with differential privacy. I haven't read those most recent papers, so I'm a little out of date.

That said...

Encrypting data at rest at the field level is an important missing piece from the future perfect privacy stack.

Just like how proper password vaults work. Salt, hash, encrypt. Never store the actual password.

The book Translucent Databases details clever examples of this strategy for misc use cases. Never store PII as plaintext.

Translucent databases and differential privacy are orthogonal. I have no ideas on how to productize (or SaaS-atize) translucent strategies.

thread

specialistDec 2021

Two tangential "yes and" points:

I'm not smart enough to understand differential privacy.

So my noob mental model is: Fuzz the data to create hash collisions. Differential privacy's heuristics guide the effort. Like how much source data and how much fuzz you need to get X% certainty of "privacy". Meaning the likelihood someone could reverse the hash to recover the source identity.

BUT: This is entirely moot if original (now fuzzed) data set can be correlated with another data set.

All PII should be encrypted at rest, at the field level.

I really wish Wayner's Translucent Databases was more well known. TLDR: Wayner shows clever ways of using salt+hash to protect identity. Just like how properly protected password files should be salt+hash protected.

Again, entirely moot if protected data is correlated with another data set.

http://wayner.org/node/46

https://www.amazon.com/Translucent-Databases-Peter-Wayner/dp...

Bonus point 3)

The privacy "fix" is to extend property rights to all personal data.

My data is me. I own it. If someone's using my data, for any reason, I want my cut.

Pay me.

thread

specialistOct 2021

Agree on importance of correlating records across heterogenous systems.

AND:

All PII field level data must be encrypted at rest.

UUIDs unlock both the record linking and privacy achievements.

The book Translucent Databases shows how. Hide sensitive data with salt + hash, just like with proper password files. Use UUIDs as opaque pointers for linking.

thread