A common myth is that privacy is hard. Indeed, designing totally
‘private’ systems is next to impossible even under ideal
circumstances. (The same is true for designing 100% secure systems by
the way.) But we should not let perfect be the enemy of good. A little
bit of effort and consideration can actually prevent a lot of privacy
harm. In fact, just as technology can be used to invade our privacy,
it can also be used to protect our privacy by applying privacy by
design. Existing privacy-friendly technologies and privacy by
design approaches can be used to create privacy friendly alternatives
to the systems we commonly use today.
(This is the eight myth discussed in my book Privacy Is Hard and Seven Other Myths. Achieving Privacy through Careful Design, that will appear October 5, 2021 at MIT Press. The image is courtesy of Gea Smidt.)
Why, then, is designing privacy friendly systems considered hard? I think the main problem is that privacy as a concept is mostly a legal and ethical affair: the norms are soft, open to interpretation, and highly context dependent. But at the end of the day, when designing and engineering a system, concrete binary decisions need to be made. Even though Ann Cavoukian’s foundational principles of privacy by design do a good job explaining the privacy by design philosophy and the intended outcome, they offer little concrete guidance on how to get there. To bridge this gap between the legal/ethical world and the engineering world, and to make privacy by design concrete, we developed the eight privacy design strategies.
The primary purpose of the eight strategies (minimise, separate, abstract, hide, inform, control, enforce and demonstrate; they are all discussed in detail in the book) is to guide the initial definition phase of a system development project, to ensure that privacy is adequately addressed in the functional design specification. The privacy design strategies impose certain (technical) goals that, when reached, improve the privacy of the overall system. One could also view them as questions one can ask or talking points to raise during the software development process. How can I separate the processing of personal data? How can I properly inform my users about the processing of their personal data? Etc.
This should be done in a structured manner, involving all relevant stakeholders (process owners, technical experts, end users). This is necessary to guarantee that the process (and hence the analysis of the risks) takes all perspectives into account. Note that this clash of perspectives is one of the fundamental differences between security engineering and privacy by design and one of the reasons that the responsibility for addressing privacy protection within an organization should not be assigned to the same unit that is responsible for information security management.
Don’t focus on just one strategy. Each of the strategies may be relevant in a particular context and help to reach a more privacy-friendly initial design. Apply them all, one by one, to make your system as privacy friendly as possible. Depending on the context, though, you may find certain strategies more applicable than others.
The fact that the privacy design strategies have been developed in the context of the classical waterfall development methodology does not mean that they cannot be applied in other, more modern approaches, like agile software development. In fact, one can apply the privacy design strategies iteratively: an initial design based on a first analysis using the privacy design strategies can be refined by applying the strategies again at a lower level of detail.
Finally, privacy design strategies can also be used in procurement when determining the specifications for a product to be bought elsewhere or when drafting the system requirements for a system to be developed and built by an external contractor. Moreover, the strategies can be applied to (re)structure organizational processes as well. The privacy impact of a system is not only determined by the system itself. It’s also determined by the way it’s used within an organization.
(For all other posts related to my book see here)