Security, privacy, and safety by design sounds like a good idea. Alas, it is not going to happen, at least not with innovative technology. Collingridge’s dilemma gets in the way: When a technology is new and therefore easy to shape, we do not understand its downsides – and the non-issues to be – well enough to make informed design decisions, and once we understand the problems, changing the now established and deployed technology fundamentally becomes hard. Expressed in terms of the Cognitive Dimensions framework, technology design combines premature commitment with high viscosity later on.

With digital technology evolving at high pace, we are continually facing Collingridge’s dilemma. Big data and Internet-scale machine learning, the Internet of everything, self-driving cars, and many inventions yet to come challenge us to keep things under control without knowing what to aim for. Any technology we never created before is subject to the dilemma.

A tempting but fallacious solution is the (strong) precautionary principle: to take all possible risks seriously and treat whatever we cannot rule out as a problem. This approach is fallacious because it ignores the cost of implementation. Every possible risk is not the same as every likely risk. Trying to prevent everything that might go wrong one will inevitably end up spending too much on some possible but unlikely problems. Besides, Collingridge’s dilemma may apply to the chosen treatments as well.

As an alternative we might try to design for corrigibility so that mistakes can be easily corrected once we learn about them. With respect to the information technology domain this idea seems to echo what David Parnas proposed in his seminal paper On the criteria to be used in decomposing systems into modules (DOI: 10.1145/361598.361623). Parnas argues in this paper that software modules should hide design decisions from their surroundings, so that the inner workings of a module can be modified without affecting dependent modules. Constructs supporting this found their way into modern-day programming paradigms and languages; object-oriented programming is the most abvious application of Parnas‘ idea.

But the dilemma is not that easily solved. First, software design is too narrow a scope. Technology is more than just software and can become quite viscous regardless of how easily the software is changed. Just think of the Internet and its core protocol, IP. Most operating systems come with support for IPv4 and IPv6 and there are many good reasons to move on to the new protocol version. Yet we are still waiting for the day when the Internet will abandon IPv4 in favor of IPv6. The Internet as a system is really hard to change. Nevertheless, modularity helps. When attacks against Internet banking users became widespread starting ca. 10 years ago, for example, banks in Germany managed to update their authorization mechanisms and increase security in relatively short time and with few troubles for their customers.

In their recent paper Cyber Security as Social Experiment (NSPW’14, DOI: 10.1145/2683467.2683469), Wolter Pieters, Dina Hadžiosmanović  and Francien Dechesne argue that experimentation could help us to learn more about the side effects of new technology. Since people are part of any interesting system, this amounts to running social experiments. If we do not care and just deploy a technology, this is an experiment as well, just less controlled and systematic. Particular to cyber security is the challenge of involving adversaries as they are the root of all security threats. The general challenge is to run social experiments responsibly within ethical bounds.

Even with experiments, some negative consequences will likely escape our attention. Some effects take too long before they show or show only after a technology has been deployed at a global scale. Could James Watt have thought of climate change due to the burning of fossil fuel? Probably not. But at least we understand what the meta-problem is.