Resisting the centralization of network infrastructure

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

GnuPG maintainer Werner Koch presented the Sunday keynote at GUADEC 2016 in Karlsruhe, Germany. He used the session to push back against the present trends in Internet architecture, which he called a reversion to the centralization of the mainframe computing era.

Network evolution

The talk began with a quick history lesson. In the early days, computers were all custom-built machines of which there were but a few, and all of them resided in laboratories. Importantly, there was no communication between machines. Standardization efforts in the 1960s (beginning with IBM's System/360) made it possible to communicate between machines, but only by physically transporting [Werner Koch] paper punch cards from one to another. The only networks of computers were those for large projects like NASA's moon program and the civil aviation infrastructure.

"In the Seventies, things got more interesting with the 'minis'," he said. Physically smaller machines like the PDP8 meant that smaller groups could share a machine, which led to Thompson and Ritchie's development of Unix. Networking at that time relied on leased lines and used store-and-forward protocols like UUCP. Then, with the advent of TCP/IP, he said, came the really interesting developments. The proliferation of PCs and workstations meant a lot more networked communication was needed, so new protocols followed.

But the Eighties were marked by a competition between the centralized mainframe model and the decentralized Unix model. Ethernet and local-area networks allowed PC and workstation vendors to offer stiff competition, but mainframe companies had their successes as well. It was only the invention of the World Wide Web in the Nineties that broke the stalemate permanently, he said. There was no longer any denying that having all machines interconnected was the best approach—and the web at that point was fully decentralized; anyone with an IP address could run a server.

And, of course, many people did, which led to the search-engine industry. Before Google, AltaVista was the dominant search engine and indexed everything on the web. But this millennium, after the dotcom bubble burst, things changed. The most important change, Koch said, was that search engines stopped being in the "search" business, which is to say that they stopped existing to point users to information elsewhere.

Instead, they shifted into the "user profiling" business. The search engine became a central place for information, rather than a portal to somewhere else. That led to the engines filtering the information they return on a per-user basis, storing user data centrally, and retrieving information from the users themselves.

Search engines are certainly not alone in the user-profiling game (other notable players include social-media services), Koch added, but the crux is that the Internet has shifted back to a model where there are just a few sites that host information, and users connect to them directly. Ultimately, he said, these services "trick the users into believing there is an Internetwork, but in reality users are connecting to a few data centers." It is more like CompuServe and similar dial-up services from the Eighties than it is the original World Wide Web.

The state of services

Koch then examined the most popular network services of today and pointed out ways in which recent changes have returned users to a dependence on centralized servers.

The first he looked at was the web. Most sites today run JavaScript programs on the user's browser, but those sites increasingly use JavaScript served up from a central service rather than hosting it locally. As a consequence, the site does not function without the services of api.google.com or some other server; offline usage no longer works, and users not using JavaScript lose access to content.

Even more troubling is the fact that server security certificates are no longer stored locally on users' machines. Instead, they are stored within the browser itself and they are updated at will by Google, Microsoft, Apple, and Mozilla. While this development was a necessity caused by the failed certificate authority model, it is still harmful. The browsers "phone home" regularly, and what is in theory a decentralized service is, in practice, fully centralized. The solution, he said, is for server operators to host their own JavaScript—or avoid it altogether.

Email is older than the web, so its design is older, too. It is fully decentralized and resistant to disruptions in connectivity for hours or even days at a time. This is because email was designed from the start to support multiple routing options. But, today, most email really goes through only a few providers (primarily Google). The practical problem is that these providers impose rules (such as server blacklisting and disabling Sender Policy Framework support) that interfere with others' ability to run their own services. The alleged reason for this is to stop spam but, Koch said, that is not true. Large-scale analysis by the mail services makes it easier to detect and block spam, without hampering interoperability. The solution is simply for users to host their own mail on their own boxes, he said. "Take back your mailbox."

The keyservers that support GnuPG and other OpenPGP implementations are another service that has slipped away from decentralization. Originally, keyservers were a loosely coupled network of independent machines. There have been moves toward a centralized design using services like keyserver.net and pgp.com, although most have failed. Today, the new attempt is Keybase.io, which many users like for its convenience (linking PGP keys to social media accounts). But it fundamentally violates the end-to-end privacy principle of PGP by binding keys to privacy-invading services. Periodically, he said, proposals pop up to implement "validating" PGP keyservers—but none of them work in a decentralized fashion. He urged users to stand up against all attempts to centralize PGP.

Finally, he looked at federation in general. Mail servers have more and more difficulty interoperating, he said, and XMPP has "lost its track" and is being replaced by centralized systems like WhatsApp and Signal. He encouraged developers to make federation a priority and to design for it from the beginning.

The state of the desktop

Koch then looked at desktop environments—although, he said, "I mainly have questions." These days, he continued, online services are constantly on our (and our users') minds. But developers need to be asking themselves how hard it will be to get rid of the data that has been relayed to these services. Similarly, desktop projects need to ask whether or not users can effectively use their system when offline. "If the network goes out, can you still work with your data?"

He pointed out a few network services essential to desktop projects like GNOME, starting with package updates. Who is in control of the update channel, he asked? Are the updates properly signed, and is the update system easy to use? Can the desktop be used on an air-gapped computer, with "swapping around USB sticks" as the only available method to access files?

There are positive signs that some network services take decentralization seriously, he said, like the Briar mesh network and the GNUnet peer-to-peer network. Desktops and other projects should support use of these types of services, he said. The online connections you have are not under your control, he concluded; you must be prepared for their disruptions and not find yourself relying on an Internet of centralized services.

In the brief question-and-answer period at the end of the talk, Koch added that he thinks SMTP needs to be replaced (and that it will be, eventually), but that none of the proposed replacements has so far solved the spam problem. That makes them non-starters, even if they improve on other features, like "trust on first use" encryption.

He also responded to a question about the use of JavaScript and remote services for other applications (specifically, for GNOME Maps and its remote map tile service support). JavaScript is acceptable for some applications, he said, but not where a user's personal data is involved. There are good alternatives to webmail, he said, such as Mailpile, and almost all of the page styling people do with JavaScript today could also be done using CSS.

Koch told another audience member that isolating browser tabs in separate processes improves on security, but that it does not solve the webmail problem because users must still place trust in their browser. He thinks it likely that GnuPG will see progress on convincing applications to support end-to-end encryption, but even then, "that doesn't solve the infrastructure problem. Someone has to set it all up."

Koch stayed after the session and answered questions for a number of people about GnuPG and security. The talk itself had other benefits, including re-igniting a discussion over how GNOME should address security and privacy. That discussion continued in the lightning talks, unconference sessions, and birds-of-a-feather days; more information from those meetings is still to come.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Note: you can avoid this step in the future by logging into your LWN account.