Terminology matters. OK, you’d expect me to say that, as a sometime mathematician, engineer and lawyer. But the importance to all of us is highlighted by a confusing tangle of terminology that has grown out of Ann Cavoukian’s original idea of “Privacy by Design”.
That phrase was introduced in 1995 – just too late to make it into the European Data Protection Directive – but was taken up by many Regulators as a requirement that “has always been an implicit requirement of data protection”, according to the UK Information Commissioner. While the general idea seems good the phrase itself is open to criticism, notably from engineers required to actually turn it into code: that lawyers and philosophers have been arguing about the meaning of “privacy” for at least a couple of millennia, making it tricky to understand what the design requirement actually is.
In 2016, the drafters of the General Data Protection Regulation avoided the phrase and, instead, created an obligation of “Data Protection by Design” (DPbD) in Article 25(1). According to the European Commission that requires “implement[ing] technical and organisational measures, at the earliest stages of the design of the processing operations, in such a way that safeguards … data protection principles right from the start”. So far, so good: the GDPR does define “data protection principles” (in Article 5) and most of them have reasonably obvious translations to technical requirements. Unfortunately, this change was made so late in the process that many privacy regulators simply retitled their existing “Privacy by Design” documentation, making it unclear whether Data Protection by Design is actually a new, clear, requirement, or just a rebrand of the old, unclear, one. For example the European Data Protection Supervisor’s Preliminary Opinion on Privacy by Design describes itself as “contributing to the successful impact of the new obligation of ‘data protection by design and by default’ as set forth by Article 25 of the General Data Protection Regulation”.
If that wasn’t enough, Article 25(2) added a third phrase and requirement: “data protection by default”, defined as “by default, only personal data which are necessary for each specific purpose of the processing are processed”. And, perhaps inevitably, the set was soon completed by authors referring to this as “privacy by default”.
So does it matter that we have “Privacy by Design”, “Privacy by Default”, “Data Protection by Design” and “Data Protection by Default”, all used pretty much interchangeably? I think it does:
- “Privacy by Design” is a good slogan and provided valuable direction for twenty years. But it now seems to be cited – worryingly often – as “unclear, so whatever I have done must be OK”. As a privacy-sensitive individual, and engineer trying to do the right thing, that’s a distraction I’d rather not have floating around;
- “Data Protection by Design” is, I think, much to be preferred. As in my new paper “Thinking with GDPR” it contains about a dozen specific obligations (the Principles, the Individual Rights, and the obligations of whichever Lawful Basis is chosen), most of which translate into clear engineering requirements;
- “Data Protection by Default”, even though it’s the phrase chosen by the GDPR, I find, frankly, scary. A default is something each individual can choose to turn off. Again, there are already too many claims that user behaviour can “opt out” of data protection, for example by publishing personal data (“it’s on the web, so I can use it how I like”) or, more often implicitly, by “consent”. Our terminology shouldn’t be giving support to such ideas;
- “Privacy by Default” – ironically, the phrase that doesn’t actually have official blessing – I find a much more helpful engineering requirement. Indeed looking at the explanation in Article 25(2) it seems a much more accurate description of what’s required: wherever we offer individuals a choice, the do-nothing option should be the one that provides the best privacy protection. That doesn’t require a philosophical debate about the global meaning of “privacy”, just that for each decision we must be able to locate the options on a linear scale. If we can’t do that, maybe the choice isn’t one that can be communicated in a “concise, transparent, intelligible and easily accessible form, using clear and plain language” (Article 12(1)), and we should do more work on our Data Protection by Design to come up with choice(s) that can.
So: four phrases, two of which positively support engineering that respects personal data, one of which obscures that goal, and one that actively undermines it. I think the choice does matter…
