So… I did a thing and spent some thought on our Internet today, and how our world is falling apart. What sparked these thoughts is research I did in the past, but also this blog article, which deals with the question of how we could rebuild the Internet once our world has finished properly burning down.
We currently live in a world that is evaporating under the human-made climate emergency and countless other shifts we find ourselves in at the moment. The Internet of today will certainly neither be sustainable nor resilient in the future we are heading towards.
Together with my colleague Doris Aschenbrenner, I wrote down these thoughts in a paper in the form of ’13 propositions’, which will appear in the proceedings of the joint workshops on Technologies, Applications, and Uses of a Responsible Internet and Building Greener Internet, co-located with ACM SIGCOMM later this year. Feel free to click through to the paper and get some spoilers. Otherwise, follow the forthcoming series.
Note, our propositions are based on our research contributions published in the past, public discourse, and are most certainly rooted in system administration lore and our own experience as system administrators. They are intentionally bold, and we make no personal claim to originality and completeness.
Proposition 1
‘Operating systems require operators to execute care, towards their system, their users, and the infrastructure as a whole.’
This one is not so much about operating systems but more about the process of running and maintaining a system.
In the first line, this statement draws on work by Mannat Kaur, a PhD candidate I have the privilege of working with who takes a unique safety-science and feminism-informed perspective on human factors and system administration. In her recent paper (pre-print), she looked at how sysadmins coordinated in the wake of the COVID-19 pandemic. A rather striking observation she made is that system administration has a major component of care work and emotional labour. This may be self-evident to any system administrator who ever had a user ask them if they happened to have ‘a backup’ of something important said user lost.
Maintaining the user’s emotions, fear, and anxiety, regardless of whether a backup is present, is a major part of the task. However, we also claim that the necessity to care for users extends beyond this example.
To operate systems means caring to create those backups in the first place. System administrators need to plan, anticipate needs, and provide solutions for problems before they materialize and are realized by users.
Furthermore, system administration means caring for systems in their whole life cycle. While building a system is fun, ensuring that it keeps running is a different and more complex task, especially under the security and privacy guarantees users expect. For example, following the gist of Limoncelli and fellow author’s book on system administration, providing a service is a responsibility that must be fulfilled, and the hard part is continuing to fulfil it.
So, if we want the Internet to be sustainable in our burning future, we have to reorient ourselves to actually caring for infrastructure and its users. If we do that, digital infrastructure might give us an edge in surviving the future to come. If we don’t start caring soon, it may very well become a liability (if it is not already) further dragging us down.
Proposition 2
‘The centralization of the Internet has been promoted by a lack of care.’
So, what is this about? Why did a lack of care lead to everyone running into the arms of a few big platforms?
In general, the early Internet used to be a rather collaborative network, and that showed in the protocols developed for it. For example, initial visions of SMTP assumed open relays being the default, and DNS — as a UDP based protocol —neglected the issue of spoofing.
Over time, the Internet has become more hostile — more of a ‘for one’s own benefit’ focused place, where features have been turned from useful to dangerous. Especially the abuse of DNS and similar protocols from the same era, which has given rise to large-scale Denial-of-Service (DoS) attacks.
Now, preventing large scale amplification attacks is technically surprisingly simple: You just have to make sure no one runs systems on the Internet that can be used as amplifiers, and people should prevent spoofing from their networks. The problem is, running an amplifier usually does not have a significant impact on one’s own network. It is the conglomerate of thousands of amplifiers sending packets that take down networks.
Operators have to care for the impact their own stuff has on others. Similarly, letting some spoofed packets out does not really harm yourself. After all, the idea behind amplification attacks is that the packets going out are, well, small.
Similarly, in the case of Internet of Things (IoT) devices and customer-premises equipment (CPE) that can serve as amplifiers, vendors have to care about fixing something that does not necessarily impact their customers. If your IoT camera participates in a DoS attack, you will most likely not even notice it. Why should you care if it does not affect you? Why should the vendor care if the entity that pays them is not affected?
Well, obviously, everyone should care because on a larger scale, this affects the infrastructure we all rely on. But that’s the issue with caring. You have to do it, usually without directly visible benefit for yourself. It is just about doing the right thing.
The prevalence of high-bandwidth DoS attacks that has arisen from a lack of care has essentially made it impossible to reliably run a service that is not shielded by the ‘just having a bigger pipe’ of a hypergiant (like Cloudflare, Amazon, or Google). If you don’t want to be impacted by others’ lack of care (and potentially your own), you now have to make the decision to follow the path of migrating behind a hypergiant that shields you from that lack of care. And this is besides all the existing economic incentives of centralization and cloudification.
So, in summary, as DoS attacks are enabled by careless system administration, like operators that leave amplifiers readily connected to the Internet and allow spoofing addresses on their network, or vendors that roll out carelessly thrown together IoT devices, shipped with default credentials. It has become common to provide services and run infrastructure without taking responsibility and caring for its impact on others. And we are all paying the price in the form of centralization, with all its implications.
Proposition 3
‘There is a tension between privacy and security pitting decentralization vs. centralization.’
This point confounds several aspects of centralization and cloudification. One part is that a major component of centralization and migrating to centralized cloud infrastructures is the reduction of capital expenses in terms of knowledge. While this means that organizations become dependent as they no longer retain the ability to run their own infrastructure, it also hints at the issue of security being ‘easier’ for centralized clouds.
In general, doing things properly and more securely becomes easier with more control. Security is already easier in a centralized ‘walled garden’, simply because there is more knowledge on what is normal, and consequently, to detect anomalies.
It is also easier when there are resources to run systems ‘properly’. A dedicated security team is simply unrealistic for smaller organizations, let alone small communities. Still, for hypergiants, we usually talk about security teams. In addition, building a system that tolerates human error and lessens the impact of security misconfigurations needs a certain scale.
This boils down to the common knowledge that operating systems get easier if you can treat them like cattle. This, in turn, needs scale to be feasible. And that’s where centralization bites its tail.
To be critical: This ultimately creates a choice between the devil and the deep blue sea: Either you allow a selected hypergiant to (technically be able to) read your emails, and their walled garden and ability to scale operations will keep your mail and you secure. Or you host your own system and it may be less able to deliver your mail to others, or find it leaked due to a configuration mistake.
The choice is yours, if there is one at all.
The idea of eternal growth and profitability are a cornerstone of our society (despite not being a thing). Especially in the IT world, the idea of ‘do start-up, be rich’ is the ultimate dream and fullfilment of an overcome deus-ex machina lifting one into the ranks of our new world’s aristocracy. At least, that’s the fairy tale we tend to tell ourselves.
There is another whole argument to be had about how having rich ancestors is beneficial in this process; however, this article is about another aspect of creating a large and profitable system that scales.
We claim, that:
Proposition 4
‘Centralization and profit are inherently incompatible with care for infrastructures.’
In our globalized economy, the idea is that people, especially corporations, naturally seek to maximize their profits and gains. We do not want to judge this perspective here. For our proposition, it is irrelevant whether this is a good or a bad thing. (Spoiler: We think it is a bad thing)
But why are centralization and profit incompatible with care?
Well, it starts with centralization:
Centralizing infrastructure also means centralizing control.
↓
Centralizing control means centralizing power.
↓
Centralizing power means that, all of a sudden, entities gain the ability to make decisions simply for their own benefit, disregarding the needs of others.
This, quite obviously, can become ‘suboptimal’ if we are talking about infrastructure others depend on.
Next, we have the profit component. The thing with the cloud, and digital systems in general, is that scaling needs a cattle-style approach. You reduce cost with automation and consistency when running your system and in supporting your users, in deciding which services to run (or discontinue), in deciding which integrations with external services you allow, and what freedoms your users enjoy in how they use and interact with your platform.
Caring does not only mean caring for the needs of the majority. However, caring for everyone in their uniqueness means that a lot of beautiful leaves in the end make a heap whose weight can make you collapse. Caring for users’ needs is simply costly.
Similarly, caring for infrastructures entails you doing things that have no measurable impact on users. Doing maintenance and ensuring things keep running does not constitute the holy grail of ‘innovation’ or the mantra of ‘moving fast and breaking things’. It simply ensures things stay working. Reducing that care will, ultimately, degrade your service. Slowly.
Users may not notice it at first. Users may never notice it at all. But ultimately, the infrastructure will fall apart — much like a frog finding themselves in a pot of slowly boiling water. So, if you want to quickly (within 5 -10 years) increase profits, why should you care about the infrastructure instead of banking resources from moving fast, doing more fun things (this includes engineers), innovating, and breaking things?
Consequently, in a profit-oriented world, it can become fiscally untenable to maintain sufficient care for a service/infrastructure and its users. To conserve their bottom line, corporations will discontinue services that users rely on, or apply support mechanics that cannot provide the care some users may need, or neglect maintenance of existing systems. For a profit-driven corporation, this is a rational decision, but it will mean a significant loss for users, no matter how mundane (your fancy home automation no longer working), unusual (you found love with a digital entity), or obviously essential (visual implants becoming obsolete), a service is.
For you, profit does not matter if your world — whatever that is for you—suddenly goes dark again. And (depending on the service) if the service ultimately breaks, it will not only be a loss for some, but for society at large.
So, in summary:
Centralization means power.
↓
Care reduces profits in digital infrastructure.
↓
Power allows you to ignore care to increase profits.
↓
A rational actor will increase profits.
↓
A caring one will not.
↓
Corporations are rational.
Stay tuned for propositions 5 – 13.
Adapted from 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.
We tried, and failed:
http://esr.ibiblio.org/?p=8383