The Architecture of Privacy

Foreword

When I was an undergraduate majoring in computer science a few decades ago, books published by O’Reilly and Associates possessed talismanic power to me. As it happened, some of the earliest O’Reilly books were being published during my freshman year, and their mix of great writing, beautiful production value, and hyper-specificity were tailor-made for a young geek learning about Unix, perl, and the Internet for the first time. My dorm room bookshelves were lined with a rainbow of brightly colored book spines. Across my desk roamed a veritable menagerie of cover illustrations, from camels to grasshoppers, from crabs to crowned pigeons. I read every line of Dale Dougherty’s book, and Cricket Liu’s book; the tattered pages of my copy of Larry Wall’s Perl Programming began to fall apart in my hands. I even splurged (well, my parents did) and bought the entire set of pricey X Window System guides, although I confess that I didn’t read most of those.

I tell you this history to come clean: I gladly would’ve written a Foreword to contribute text to an O’Reilly book to honor my twenty-year-old self’s obsession even if that book was just average. What a happy moment it is for me, then, to be able to contribute front matter to an O’Reilly book that is much more than just average. You hold in your hands (or view on your screen) a fantastic contribution to the burgeoning literature of privacy engineering.

Privacy requires a dialogue between two types of people: those who speak policy and those who speak engineering. The most important word of that sentence—and the part that many people fail to understand—is “dialogue.” In many other spaces where tech touches policy, these two tribes stand across a chasm, reacting to one another but not conversing with one another. Thus, in modern digital copyright policy, creators create, technologists protect and circumvent, and lawyers create laws and spur lawsuits reacting to these actions. In telecommunications policy, engineers engineer and lawyers react and respond.

And even in a field that many people—including many experts—mistakenly think relates closely to privacy—information security—the dialogue is hardly essential. Security folks traffic in the impossible and possible—this crypto works or it is broken. The benchmarks for “victory” and “defeat” are entirely internal to the discipline. And the law and policy folks sit on the sidelines and react and respond.

Privacy doesn’t work this way. A privacy engineer, at least a good one, cannot live in ignorance of law and policy because the ideas of “victory” and “defeat” for privacy cannot be subjected to correctness proofs and measurements of algorithmic complexity. Engineers can tell you how to dial down or dial up a particular information flow, but it requires a source external and foreign to the engineer’s core training—maybe the law department, public relations, the shareholders, or the engineer’s moral compass—to determine right and wrong, acceptable risk or not, privacy violation or not.

As only one example, take the topics of data anonymization and re-identification, topics central to work I have done. This much we now know: “data can either be useful or perfectly anonymous but never both.” I said this once, and much ink has been spilled trying to prove me wrong. I’m not wrong, but at the same time, I am not being very interesting when I say it. Of course scrubbed data can be unscrubbed. You would be foolish indeed (or worse, trying to sell anonymization consulting services) to fail to realize that modern improvements in data processing, auxiliary data, and storage could lead to any other result. But recognizing this boring truth is far from knowing what to do about it. The lesson of powerful re-identification isn’t that we take our ball and go home. But it is just as unacceptable to continue to act as nothing has changed.

You cannot “solve” the re-identification problem without lawyers who understand tech and techies who understand policy. (I try to be both, as I went to law school a few years after obtaining that CS degree and now teach law.) It might be enough to delete eighteen identifiers or it might not. It might be enough to encrypt the data and leave the key with “Joan in the front office,” or it might not. Maybe you can distribute the data to a trusted third party, or maybe you shouldn’t. It’s nuance and hard choices and a dialogue between engineers and lawyers all the way down. We need to train a new breed of privacy engineer, and it starts with creating a literature elaborating this new discipline.

This bringing together of engineering and law means that it takes an exceptional group of people to come together to write a proper book on this topic. Luckily for you, and for the privacy community as a whole, the authors of this book compose such a group. They include top-notch engineers and good lawyers. But more importantly, they include people steeped in the weird mental gymnastics, arcane training, and time spent in rooms in Silicon Valley and state and national capitals required to be called privacy experts.

It is even luckier for you that they happen also to be extremely engaging writers. This is a very well-produced and organized book. It has the virtues of clarity and modesty, two virtues often lacking in books written by engineers. I call the book modest, because it recognizes that this field is new and that we don’t really even yet understand what we mean when we call somebody a privacy engineer.

I’m not sure I’m ready to call this book a classic or a new entrant into the canon. I think time will tell, and I hope I am invited back to update this Foreword for the second edition, when I can trot out those labels, if they stick. But this seems to me at least to be a very useful book, one that fills a gaping hole in the current literature. I’ll happily place my copy of this book on my shelf. I have a particular spot in mind where I think it will fit in well.

Paul Ohm

Professor of Law,
Georgetown University Law Center

Boulder, Colorado

July 2015