Tag Archives: privacy

The Cult of Security/Privacy By Design

I have been reading a lot of privacy literature lately and the more I read, the more I got frustrated with the “Privacy by Design” motto. It somehow was not right, and made me realise that “Security by Design” motto is similarly hyped and is just as misguided. Let me explain.

Why security/privacy wasn’t baked in at the start

First of all, the basics: “X by Design” means that security/privacy is baked into the product from the inception and design through to implementation,  and all the way to operation. This of course sounds great, and one can easily see that trying to retroactively implement security or privacy features/requirements into an already existing product is a lot harder than baking it in all from the start. Where I think this starts to fall apart is that often, the reason for something being only “an afterthought” is not that it wasn’t actually considered while e.g. conceptualizing the product. It’s because it was considered but either:

  1. There weren’t any people available who could help i.e. the security/privacy personnel were busy, expensive or too complicated to acquire/hire/consult or
  2. It wasn’t considered important to involve the right people/team because the project/product was supposed to be small/unimportant and security/privacy-irrelevant but over time it grew to be important/large

In other words, it was either resource constraints or legitimate business reason not to spend resources on something (that was meant to be) small/irrelevant.

Reminiscing of the past

What I see in a lot of these “X by Design” discussions is a set of technical people reminiscing about how awesome it would have been if e.g. Google built their search engine in 1998 with security/privacy in mind. Yes, it would have been, but the engineers writing the code had no idea if it would take off and had neither the time nor the money to spend on expensive consultants and long consultation periods to bake security/privacy in. The same can be said of many other startups’ products and of most projects in large companies that grow to become products of their own.

If security and privacy engineers would have to be involved in all smaller projects then innovation would seriously suffer, because there are simply too few of us and we would  take too long to take a sufficiently good look at everything (that might not take off anyway). So, since we cannot be involved at the beginning of every project, the best we can hope for is to fix it afterwards — there is no point in reminiscing in how awesome it would have been if we were there when Twitter started in 2006. We weren’t there, it now took off and they are offering value to their customers, bringing in revenue which they are (hopefully) using to fix their security/privacy issues. I think it’s too optimistic to assume they could have afforded the delay-to-market and the price attached to doing it “right” from the start. Most probably, they couldn’t.

Living in the present

All in all, I think a most of the “X by Design” is wishful thinking with some sermons attached to it, telling long tales of how things could have been so much better, had the right security/privacy people been consulted. What these tales often forget to tell is that when the idea was born, and the project/product was created, the situation was not even remotely amenable to such an intervention. Hence, I think it’s time to let go for the most part — we should concentrate on doing what needs to be done. We should make sure we have solid processes and good, flexible patterns for fixing already existing products.