The network still works. We’ve simply learned to ignore the points of control over the services built on top of it.
The servers are still running. The service is gone.
Imagine you’re running an online service. The servers are up, the software works, the database responds, and the logs show nothing unusual. Your infrastructure is healthy.
And yet, to anyone trying to reach you, the service no longer exists.
It isn’t a crash. It isn’t a bug. It isn’t even necessarily an attack on your servers. All it takes is for someone to sever one link in the chain that allows users to find you, authenticate themselves, or pay you.
That’s where I want to begin, because the title is deliberately provocative: the Internet is broken. But not in the way most people imagine. TCP/IP still works. Routers forward packets, open protocols do their job, and networks continue to communicate. What has gradually become concentrated is control over the services we’ve built on top of the network.
We’ve spent decades making those services more available, faster, and easier to use. Far less time, in some cases, asking who could shut them down without touching a single line of our code.
Autistici/Inventati: when the switch isn’t in the data centre
In August 2026, the case of the Italian collective Autistici/Inventati made this question anything but theoretical.
On 26 August 2026, the Office of Foreign Assets Control (OFAC), the US Treasury agency responsible for administering economic sanctions, included Autistici/Inventati in a designation as a Specially Designated Global Terrorist (SDGT). According to the US government, the collective had supplied technological services and infrastructure to violent extremist networks and parties already subject to sanctions. Autistici/Inventati rejected those allegations, defending its role as a provider of communications and digital self-defence tools.
Two distinctions matter here. An OFAC designation is a sanctions measure; it is not, in itself, a conviction handed down by an Italian court. And reconstructing the technical events does not require readers to agree with either side’s political position.
On 28 August, the autistici.org domain became unreachable. The collective traced the problem to domain and DNS management, pointing to action by the .org registry, Public Interest Registry. This was not a case of destroyed machines or servers unable to run their software. The name through which users reached those services no longer led to the expected destination.
In the following days, there were also repercussions for financial channels, according to material published by the collective and press accounts. On 6 September, Autistici/Inventati announced its decision to cease operations, considering the legal and operational risks to the group and its users unsustainable.
None of this means that one operator made every decision, or that OFAC directly ordered the registry to disable the domain: the sources examined do not establish that conclusion. What it does show is that a digital service can lose reachability and continuity because of decisions made at layers entirely separate from the application itself.
There was another incident around the same time: an intrusion into the Noblogs platform. That needs to be kept separate from the domain disruption. An application-security incident is not automatically the same event as an intervention at the DNS layer. Mixing them together would obscure precisely the technical point we’re trying to understand.
So the question isn’t simply, “Who was right in this particular case?” It’s also this: which dependencies can render our system unusable even when, from a computing perspective, the system can still function?
It isn’t TCP/IP that’s broken
The Internet emerged and developed as a network of networks. Open protocols and standards allow independent systems to communicate without all belonging to the same organisation. That is not a philosophical footnote; it is an architectural decision.
To send an email, in principle, the sender and recipient don’t need accounts on the same platform. They can use different providers, different infrastructure, and different software, provided those systems interoperate.
Try applying that logic to many services we use every day: proprietary messaging, social networks, digital identities, and app distribution. In plenty of cases, the value of the ecosystem is concentrated inside a single operator. Leaving can mean losing contacts, data, reputation, access, or functionality.
This is neither a new diagnosis nor one confined to hacker circles. RFC 9518, which discusses centralisation and decentralisation in Internet standards, describes the risk of functions that began as open systems becoming concentrated at the service and application layers. The Internet Society likewise continues to stress the role open standards play in enabling interoperability and innovation without requiring permission from a single platform.
But there’s an important caveat: centralisation didn’t arise solely from user laziness or provider greed. It solved real problems.
Operating a service for millions of people requires reliability, moderation, anti-spam measures, account recovery, support, protection against abuse, and an experience that doesn’t force every user to become a system administrator. Platforms made services possible that a multitude of small, independent nodes would have struggled to offer with the same immediacy.
The convenience is real. So is the price paid in control.
The problem begins when we treat that convenience as a free property of the architecture and ignore the cost of getting out.
Six places where someone can switch off your service
Let’s look at a typical web application, not through its Kubernetes diagram or load balancer, but through the dependencies that allow it to exist publicly.
Naming. DNS, registrars, and domain registries: your server may be available, but users might be unable to find it under its usual name.
Identity. Single sign-on, credential recovery, and authentication providers: an outage or revocation can prevent access even when the backend is healthy.
Compute and delivery. Cloud providers, hosting, and CDNs: we gain scalability and protection, but also concentrate some operational control.
Discovery. Search engines, social graphs, and recommendation systems: you can remain online yet become almost invisible to your audience.
Software distribution. App stores, repositories, and update channels: the ability to install or update a client often depends on external operators and their rules.
Payments. Banks, intermediaries, and payment networks: a commercial service may continue to deliver software yet lose the ability to collect payments or pay its suppliers.
These points of control aren’t equivalent. They are governed by different laws, procedures, and risks. Nor is every intervention arbitrary or illegitimate: preventing fraud, attacks, and unlawful activity is part of many operators’ responsibilities.
From an engineering standpoint, the question is different: is there a route to continuity when one of these dependencies disappears?
If the answer is no, we have a single point of failure that might not appear on any of our dashboards.
High availability does not mean autonomy
A company might run a multi-AZ setup, a replicated database, tested backups, around-the-clock monitoring, and automated deployments. All sensible. All useful.
At the same time, it might have a single registrar on which its public identity depends, a login system that’s extremely difficult to replace, data that can only be exported in proprietary formats, or a contractual relationship with no realistic exit plan.
The first category of problems is what we normally address with high availability: component failures, availability-zone outages, configuration mistakes, and infrastructure incidents.
The second is about replaceability. If a supplier stops providing a service, revokes access, or terminates the relationship, how long will it take us to become operational elsewhere? And what, exactly, can we take with us?
A database backup doesn’t guarantee that we can export identities, social relationships, keys, reputation, or distribution channels. A redundant cluster doesn’t guarantee that users can reach the domain. A perfectly automated system can also automate a dependency we have no idea how to escape.
In other words: HA is not the same as autonomy.
And no, the solution isn’t necessarily “let’s host everything ourselves.” Self-hosting transfers responsibility for patching, security, uptime, backups, and incident response. For a small organisation, it can even be the worse option when chosen for ideological reasons rather than actual requirements.
Digital sovereignty, as I mean it here, is not the complete absence of providers. It is the reasonable, demonstrable ability to change providers, retain our data, and continue operating.
Privacy, decentralisation, and sovereignty are not synonyms
We often use these three concepts as if they were interchangeable. They aren’t.
Privacy concerns who can read, correlate, or process information about us. A centralised service can deploy strong data-protection techniques, just as a distributed service can expose sensitive information through its design or poor configuration.
Decentralisation concerns how control—and the power to interrupt a system—is distributed. But a collection of nodes is not automatically immune to concentrations of governance, infrastructure, or economic power.
Sovereignty, finally, is about our ability to decide and act. Do we possess the necessary keys? Can we export the data? Can we switch software or intermediaries? Can we do so quickly enough to maintain continuity?
What interests me most is that third property, without pretending the other two don’t matter.
Because there’s an enormous difference between feeling independent when everything works and actually being independent when something important stops working.
The “provider switched off” test
I’d like to close this first part with four questions. They’re easy to ask, and rather less easy to answer when you sit down in front of a real service architecture:
- Can I export my data? Not just in theory: have I ever tried restoring it somewhere else?
- Can I change providers? How long would it take, what would it cost, and which features would I have to give up?
- Who controls the keys? The ones used to access data, control identity, and authorise important operations.
- Can the service survive revocation? Not necessarily without interruption, but with a concrete route back to operation.
This isn’t a test that only Linux users can pass. Nor is it one that cloud users automatically fail. It’s a way of measuring dependencies instead of turning them into beliefs.
The title of this article is provocative. But the answer can’t be limited to outrage over an incident, nostalgia for an Internet that no longer exists, or the familiar refrain that “we should decentralise.”
Alternatives exist. They’re varied, sometimes inconvenient, not always mature, and they don’t all solve the same problem. To discuss them seriously, we must acknowledge their costs too.
In the second part, we’ll start right there: what happens if we abandon the idea that a single provider must control every layer of our digital lives? And what if, for certain kinds of communication, the Internet itself weren’t even indispensable?