Review: The Architecture of Privacy

The Architecture of Privacy

About the authors

Courtney Bowman has been working in the data analytics space for the last decade. He joined Palantir Technologies in 2010 as an in-house Privacy and Civil Liberties specialist.

Ari Gesher is a technologist and software generalist. He leads software engineering at Kairos Aerospace.

John K. Grant is a Civil Liberties Engineer at Palantir Technologies. He served for nearly a decade as an advisor in the U.S. Senate.

Daniel Slate worked as an engineering strategist and product manager for Palantir Technologies, where he focused on architecting privacy-safeguarding software for the international security community.

Inside The Architecture of Privacy

“Engineers can and should take privacy into account when designing and building technology,” the authors of this tome assert. “We have become heavily reliant on advanced information technology, and we need to be able to trust our systems and each other with our data.”

The Architecture of Privacy (the name of the book is a nod to Lawrence Lessig’s well-known essay with the same title) is roughly divided into four sections.

The first goes a bit into the history of how informational privacy, technology and law intersected and continue to intersect, and explains how privacy law lags behind technology, making it important for engineers to come up with their own (preferably ethical) decisions about collecting, keeping, transferring, using and destroying “data about people.”

Then it goes to explain the forms this data can take and how some of these forms are not considered very revealing, but in this age of Big Data can, in fact, reveal much (anonymization of data is not possible anymore, the authors feel).

They point out how engineers should keep two different but equally important goals in mind: the protection of data from authorized users (by creating privacy-protective systems) and from unauthorized ones (by making information security a priority).

They share insight into oversights in tech architectures that coud lead to privacy issues, note the importance of keeping the data secure every step of the way (and explained how, by implementing several infosec best practices), and present two high-profile case studies that show how even big companies like Google and Apple sometimes fail to build systems that express their intentions correctly (i.e. don’t collect data they did not want to collect, keep data that they didn’t intend to keep, etc.)

The second part is dedicated to access control. More specifically, to authorized data access. Here you’ll learn more about separating roles (end user, application admin, sysadmin, etc.) and powers, and making each of the roles secure by defining well what they can and should not be able to do, and simultaneously creating a framework for oversight.

Then, you’ll learn about access control models and granularity (with the help of a few real world scenarios that present different optimal choices), types of access, managing access and finally, about the strengths and weaknesses of access control – this chapter is all about access restrictions. The next one is all about limiting retrieval and use of data in ways it wasn’t intended to be used.

The third part adresses oversight, and touches upon the subjects of data sharing, audit logs, and data retention and purging (i.e. its removal from the system).

Part four starts with several use cases based on hypothetical technologies. The authors go through all the things a privacy architect should think about when: the created technology analyzes publicly available social media information, is a new secure messaging app, etc. These are a great set of examples that allow readers to get a taste of required thinking about privacy in the context of designing and building a product.

Those are not the only things that a Privacy Engineer is expected to do – he or she needs also to be involved in helping to come up with the right product distribution strategy, improving customer support, help with marketing, be close to the legal team, keep an open dialogue with the public and privacy advocates, and so on.

The chapter addresses the various skills and expertise such a person needs to possess. It also points out the need for the Privacy Engineer’s perspective to be challenged by individuals inside or outside of the company (the latter is better), and to keep up with the latest trends in privacy theory (a helpful list of conferences is provided here).

The book ends with a chapter of the future of privacy – market forces and law and policy – but the authors admit there a lot of it is pure speculation, a lot of “mights” that may or may not happen. “Expect the unexpected,” they say, and it becomes clear that privacy engineers are always going to be in the middle of some rough waters.

Final thoughts

Privacy is a subject that many have written about, but this book is definitely special, as it was written from a perspective of technologists, not law and policy makers.

When you think about it, it’s logical – when it comes to technological innovation, it’s the technologists who set the pace and ultimately push the boundaries of our concept of privacy. It should be on them, then, to make choices that will not result in the complete death of it. If they let it, this book will push them in the right direction.

I would also strongly recommend this book to academics and policymakers, as they will get a good overview of what can be asked of new technology in terms of privacy protection.

Don't miss