Robert Frost once wrote that good fences make good neighbors. Many developers today feel the same way about the Internet, yearning for a world where websites and their servers each live in separate spaces, free of tangles. Oligarchs aside, almost everyone loves the idea of a federated web.
The term federated alludes to federalism, the philosophy that guides the political structure of the United States. Each of the States retains its sovereignty and the whole country benefits from this independence. The Internet works the same way. As an ideal, it offers a combination of resilience, flexibility and distributed power that shines brightly for those who value freedom. In reality, the web today is a mixture of independent islands and tightly integrated silos. There are many examples of sites working together at arm’s length, embodying federated web design. There is also walled gardens, where a central administrator dominates all interactionsembodying control as a modus operandi.
For all the perceived advantages of a world populated by independent fiefdoms and principalities, the federated Web has its drawbacks. For the sake of understanding, let’s look at some of the Federated Web’s dark secrets, hidden issues that few of us like to examine. These issues may not be reason enough to abandon vision, but they can help us develop more balanced technical solutions.
No economies of scale
Many mergers and consolidations are driven by economies of scale. Hundreds or thousands of freelance websites means hundreds or thousands of databases full of accounts, logs, and other overhead. Each needs a separate system administrator, database administrator, or devops team. When the numbers start to run into the millions or billions, the economic pressure to bring it all together under one roof is powerful.
Open source platforms such as Drupal or WordPress offer a solution, allowing individual sites to retain their independence while shifting much of the development complexity and overhead to a larger system.
More logging
When two or more Federated Web sites want to collaborate, they begin by checking permissions, which they do by exchanging data packets. All of this information is in addition to bandwidth charges and the cost of log storage. While data storage is cheap and bandwidth costs aren’t bad for small packets, the never-ending stream of authorizations and coordination adds up quickly.
Some developers want to go further and use technology like blockchain to track an endless stream of transactions and events. The work of collecting these events and blessing them with the assurance of blockchain means even more overhead, especially if the IT heaviness proof of work consensus algorithm is used. Even lighter algorithms like proof-of-stake or a managed blockchain add to the burden of record keeping.
Digital signatures everywhere
The science of cryptology has given us many good algorithms for creating digital signatures that can certify every interaction in the Federated Web. The math is powerful and although it is not bulletproof or perfect, it can significantly improve the authenticity of data packets.
The good news for federated web is that some organizations are beginning to deploy these same security measures in their internal networks. Even though the databases and servers are all managed by the same company, many security professionals adopt a zero trust architecturewhich insists that every machine polls every packet.
Caching is complicated
Much of internet speed relies on smart caching policies. There is, however, a downside for federated architectures, which can run into legal and practical issues with caching. A friend spent months redoing the checkout system of an online store where he worked. Credit card processors had rules against caching, which caused some of its biggest performance issues.
Federated sites may be willing to share information once, but they may also have strict rules about how much data you can keep from the interaction. Maybe they’re worried about security, or they’re worried that you’re caching enough data that you don’t need it anymore. Either way, caching is often a problem with federated sites.
Forgot security holes
One of the ways sites try to simplify federated relationships is to store permissions and keep them running for months or years. On the one hand, users like to save the time it takes to re-authorize. On the other hand, they often forget that they have authorized a remote server, which can become a security hole. There is no simple solution. Asking users to authorize too often is annoying and time consuming. But not asking often enough leaves security holes. Some sites send out a message every few months asking users to review their authorized connections. It’s just a sweet way to get them re-authorized.
Cascading security failures
Ideally, a federated architecture must be resilient, especially in the face of security breaches. But systems sometimes end up influencing each other, so a problem with one can bring them all down. If several sites in a federation depend on a partner for, for example, authorization or identification, then this partner becomes a potential weak link. It is not uncommon for a failure on a site to lead to a cascade of security breaches.
Vulnerable dependencies
If you ever want to scare off a Java developer, mention the open source logging framework, Log4j. When a security vulnerability was discovered in the framework, which is used in almost all Java applications, developers around the world scrambled to fix flaws they didn’t know existed. Developers need to be sure that their libraries are secure, yet there is no way to certify code security without testing every line of code.
The Federated Web presents a similar danger. Your code may be clean, but what do you know about other websites you partner with or their partners? Federated Web idealists envision a vast and rich collection of interconnected sites that can be as public or as anonymous as they need to be. The challenge is to create real accountability within this system. No one wants their code checked by an unaccountable team, and the same goes for websites on a federated web.
Monoliths rule anyway
Monolithic companies like Amazon and eBay are actually constellations of millions of small businesses. Although they may appear to users as one giant system, there is often a bit of federation inside. The difference lies in the concentration of power. The central company makes the decisions, and the small companies do what they are told.
The conundrum is that all the work necessary to maintain a federated Web must be done, and the entity that does it inevitably has centralized power. The system evolves towards central control, no matter how much architects try to design around it.
Too much complexity
Ultimately, people, whether users or engineers, struggle with complexity. A simple example of how users undermine the Federated Web is password reuse. People can’t remember hundreds of different passwords, so they use the same one over and over again. In theory, each site should maintain an independent layer of security, but in reality, users cannot handle so much complexity. Thus, they constantly undermine the security of the federated web.
Competition and freedom of choice are wonderful options, responsible for much of the diversity that makes the Internet irresistible. But managing real federalism brings a level of complexity that often exceeds what real people – and the real systems we build – can handle.
Copyright © 2022 IDG Communications, Inc.