We really have a tendency to build complex systems. There are countless discussions about the explosion in the complexity of protocols, for example, the DNS Camel is certainly one of the most iconic illustrations of this issue.
Sometimes, this complexity comes in the form of AI systems. Sometimes it throws resources at concepts looking for solutions. Sometimes it’s the issue of bloat on the web. Other times, we wonder where all the RAM went. Then there’s the environmental issues associated with the footprint of large models, proof-of-work-based blockchain technology, and the piles of IoT waste. The examples are endless.
In the end, this all boils down to the joint responsibility that we, as computer science people and ultimately those building these systems, have. Which leads us to our next three propositions:
Read: 13 Propositions on an Internet for a burning world (1-4)
Read: 13 Propositions on an Internet for a burning world (5-8)
Proposition 9
“Systems that are too complex to be understood by a single person cannot be sustainable.”
In a world burning down, it will be important to keep systems running. Systems may end up being isolated and small scale. They may depend on individual operators. They may depend on knowledge of how they are operated being easily transferable to another person.
Again, Solène provided the foundation of this proposition in a blog article. This article argues that the building blocks of automation and complex systems need to be understood before they can be ‘abstracted away’. However, to be sustainable in a burning world, systems will have to be run (and understood) by small teams and communities (see Proposition 7). Therefore, while automation is a necessity in an ever-growing and centralizing Internet, its complexity might become a curse in an Internet that is supposed to survive in a burning world. Or, to use an example: Without a central docker repository, there is no place where curl | sudo bash can pull the image from.
Proposition 10
“Systems should enable a better tomorrow and not burn the world even further.”
This responsibility can manifest itself in many ways.
One way is how more abstraction leads to more resource needs. With the wide availability of automation and support infrastructure — which, of course, has the good intention of enabling many people to build — the hunger for system resources steadily increases. Currently, we tend to to create a growing ball of systems supporting other systems — abstracting something simple to be more complex. This, in turn, becomes embedded in how we build and design systems, adding layers and using more resources for the same functionality, as best illustrated by web page bloat.
This overall development has probably been brought to the extreme by Bitcoin and its proof-of-work siblings, churning through energy on a nation-state scale, while having no purpose except profit. Bitcoin may very well be the perfect piece of performance art, illustrating the fall of a species burning itself and its planet, merely for the sake of more.
As such, we claim it is an engineer’s responsibility to ensure that the systems they build contribute to a beneficial purpose and do not harm society or the environment by needless and redundant processing. The system’s purpose should be tangible and reasonable in relation to the resource consumption of the system and serve the benefit of all instead of the profits of a few.
Proposition 11
“There are no technical solutions for social and societal problems.”
The Chaos Computer Club is a relatively old hacking community of people doing things with computers. Creating space for projects, an abundance of physical hackerspaces sprouted up in Germany.
Each of these spaces are very different in their look, feel, and social setup. But they have one thing in common: They all experience ‘unreliable’ payments for drinks available via a public fridge, via an honour system.
Usually and periodically, several tech-savvy people start to implement a complex digital cash-and-credit system to solve this issue, usually in a way that also includes a touchscreen and/or a Raspberry Pi. Ultimately, that approach will suffer from limited adoption and the same issues as before, so a social solution will have to be found instead. If the community is very unlucky, the technical solution will also introduce new social problems. The insufficient solution inevitably stays in place, usually until the next generation of local nerds experiences this issue and repeats. To summarize this with colloquial wisdom from the Industry 4.0 and production industry: Digitizing a shitty process won’t result in a better process but in a digitized shitty process.
The point here is that we try to apply the same ‘solving social problems with technical solutions’ reasoning to problems we face at the much larger scale of the Internet. We are computer scientists, and the hammer we wield is that of technology. So, every problem we encounter looks like a technology-shaped nail.
Ultimately, we consistently face the impact of social and societal issues (such as operators announcing routes they should not), attackers launching Denial-of-Service (DoS) attacks using amplifiers, and operators running amplifiers or failing to implement BCP 38. To counter them, we developed technical solutions, for example, RPKI to handle the issue of routes being announced by entities that should not announce them.
Of course, this attitude is not only limited to the Internet and its own wealth of problems. Instead, tech people are really good at trying to solve everything with an app. Given the example of the drink accounting system, the real question is what would a better solution be? We should stop wondering whether we could, and start thinking about whether we should.
Stay tuned for the final propositions.
Adapted from the original posts which appeared on Doing stupid things (with packets and OpenBSD).
Tobias Fiebig is a Postdoctoral Researcher at Max Planck Institute for Informatics.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.