]>

Prahran Australia mnot@mnot.net https://www.mnot.net/

General governance This document discusses aspects of centralization that relate to Internet standards efforts. It argues that while standards bodies have little ability to prevent many forms of centralization, they can still make contributions that improve the Internet. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction One of the Internet's defining features is its purposeful avoidance of any single controlling entity. While originating in a desire to prevent a single technical failure from having a wide impact, the Internet's early avoidance of economic and political centralization arguably enabled its rapid adoption and broad reach: permission is not required to connect to, deploy an application on, or use the Internet for a particular purpose. Although maintaining this property remains a widely shared goal, consistently preserving it across the range of services and applications that people see as "the Internet" has proven elusive. Today, many successful services operate in a centralized fashion -- to the point where some proprietary applications have become so well-known that they are commonly mistaken for the Internet itself. These difficulties call into question what role architectural design -- in particular, that overseen by open standards bodies such as the IETF -- can and should play in controlling centralization on the Internet. This document discusses aspects of centralization that relate to Internet standards efforts. It argues that while standards bodies have little ability to prevent many forms of centralization, there are still contributions they can make. defines centralization, explains why it is often undesirable but sometimes beneficial, and surveys how it occurs on the Internet. explores decentralization and highlights some relevant strategies, along with their limitations. Then, makes recommendations about the role that Internet standards can play in controlling centralization. concludes by identifying areas for future work. The primary audience for this document is the engineers who design and standardize Internet protocols. However, designers of proprietary protocols and applications can benefit from considering these issues, especially if they intend their work to be considered for eventual standardization. Likewise, policymakers can use this document to help characterise abuses that involve centralized protocols and applications and evaluate proposed remedies for them.

Centralization In this document, "centralization" is the state of affairs where a single entity or a small group of them can observe, capture, control, or extract rent from the operation or use of an Internet function exclusively. Here, "entity" could be a person, group, corporation, or government. An organization might be subject to governance that mitigates centralization risk (see ), but that organisation is still a centralized entity. "Internet function" is used broadly in this document. Most directly, it might be an enabling protocol already defined by standards, such as IP , BGP , TCP , or HTTP . It might also be a proposal for a new enabling protocol, or an extension to an existing one. However, because people's experience is not limited to standards-defined protocols, this document also considers centralization in applications built on top of standard protocols -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking equipment, hardware, operating systems, and software that act as enabling technologies can also impact centralization. The supply of Internet connectivity to end users in a particular area or situation can likewise exhibit centralization, as can the supply of transit between networks (so called "Tier 1" networks). Centralization is not a binary condition: a function might be vulnerable to it to various degrees. For example, a function that effectively uses federation () to enable easy switching between instances might have still have risk of centralization, but not as great as one that had a single, proprietary provider. Some functions' centralization risk is mitigated so effectively that they are not commonly perceived as being centralized at all. Centralization also has many potential sources. A single function might be subject to many forms of centralization, due to technical, political, economic, social, and even cognitive factors. The forms of centralization that this document discusses are primarily economic and political -- for example, one company (or a cartel of them) capturing a function, or a country being able to control how a function is supplied in another jurisdiction. While legal constraints on the Internet within a single jurisdiction are of natural concern to the Internet community, they are not considered as centralization by this document. These forms of centralization can be driven by many factors, such as the strategies of Internet-focused businesses, government policies and regulation, Intellectual Property, and inherent forces like network effects. Centralization can also be technical; for example, a machine or network link being a single point of failure for the provision of a function. While an important factor in protocol design, this form of centralization is relatively well-understood by the technical community and therefore is not addressed by this document. A failure because of a cut cable, power outage, or failed server is qualitatively different from the issues encountered when a core Internet function has a gatekeeper.

Centralization Can Be Harmful Engineers who participate in Internet standards efforts often have a natural inclination to prevent and counteract centralization because they see the Internet's history and architecture as incompatible with it. As a "large, heterogeneous collection of interconnected systems" the Internet is often characterised as a "network of networks" who relate as peers that agree to facilitate communication, rather than having a relationship of subservience to others' requirements or coercion by them. This focus on independence of action is prevalent in the Internet's design -- for example, in the concept of an "autonomous system". This reluctance to countenance centralization is also rooted in the many potentially damaging effects that have been associated with economic and political centralization, including:

• Power Imbalance: When a third party has unavoidable access to communications, the informational and positional advantages gained allow observation of behavior (the "panopticon effect") and shaping or even denial of behavior (the "chokepoint effect") -- capabilities that those parties (or the states that have authority over them) can use for coercive ends or even to disrupt society itself. Just as good governance of states requires separation of powers , so too does good governance of the Internet require that power (whether that be economic or political) not be consolidated in one place without appropriate checks and balances.
• Limits on Innovation: A party with the ability to control communication can preclude the possibility of "permissionless innovation" -- the ability to deploy new, unforeseen applications without requiring coordination with parties other than those you are communicating with.
• Constraints on Competition: The Internet and its users benefit from robust competition when applications and services are available from many providers -- especially when those users can build their own applications and services based upon interoperable standards. When a centralized service or platform must be used because no substitutes are suitable, it effectively becomes an essential facility, which facilitates abuse of power.
• Reduced Availability: Availability of the Internet (and applications and services built upon it) improves when there are many ways to obtain access. While service availability can benefit from the focused attention of a large centralized provider, that provider's failure can have a disproportionate impact on availability.
• Monoculture: The scale available to a centralized provider can magnify minor flaws in features to a degree that can have broad consequences. For example, a single codebase for routers elevates the impact of a bug or vulnerability; a single recommendation algorithm for content can have severe social impact. Diversity in functions' implementation leads to a more robust outcome when viewed systemically, because "progress is the outcome of a trial-and-error evolutionary process of many agents interacting freely."
• Self-Reinforcement: As widely noted (see, e.g., ), a centralized provider's access to data allows it the opportunity to make improvements to its offerings, while denying such access to others.

The relationship between these harms and centralization is often complex; it is not always the case that centralization will lead to them, and when it does, there is not always a direct and simple tradeoff. This makes it important to critically evaluate claims of centralization before allowing them to influence protocol design. For example, while centralization can impact availability, many other factors also influence it, and any relationship between them cannot be assumed without careful analysis of where and how centralization occurs. A system operated in a central fashion might be more available because of factors like the resources available to a larger operator, but also have greater impact when a fault is encountered; decentralized systems might be more resilient in the face of local failures, but less able to react to systemic issues. Consider a large variety of Web sites might depend upon a cloud hosting provider; if it were to become unavailable (whether for technical or other reasons), many people's experience of the Internet might be disrupted. Likewise, a mobile Internet access provider might have an outage that affects hundreds, thousands, or more of its users. In both cases, centralization is not indicated by the loss of availability or its scale, but it well might be if the parties relying on the function don't have reasonable options to switch to if they are unhappy with the availability of the service provided, or if friction against switching to an alternative is too great. Competitive constraints provide another example of a need for nuance. While making the Internet more competitive may be a motivation for many engineers, only courts (and sometimes, regulators) have the authority to define a relevant market and determine that a behavior is anti-competitive. What might be considered undesirable centralization by the technical community might not attract competition regulation. Conversely, what might attract competition regulation might not be of great concern to the technical community if other mitigations are felt to be adequate.

Centralization Can Be Helpful The potential harms of centralization listed above are widely appreciated. Less widely explored is the reliance on centralization by some protocols and applications to deliver their functionality. Often, centralization is present due to technical necessity. For example, a single, globally coordinated “source of truth” is by nature centralized -- such as in the root zone of the Domain Name System (DNS), which allows human-friendly naming to be converted into network addresses in a globally consistent fashion. Or, consider IP address allocation. Internet routing requires addresses to be allocated uniquely, but if a single government or company were to capture the addressing function, the entire Internet would be at risk of abuse by that entity. Similarly, the Web's trust model requires a Certificate Authority to serve as the root of trust for communication between browsers and servers, bringing centralization risk that needs to be considered in the design of that system. Protocols that need to solve the "rendezvous problem" to coordinate communication between two parties who are not in direct contact also require centralization. For example, chat protocols need to coordinate communication between two parties that wish to talk; while the actual communication can be direct between them (so long as the protocol facilitates that), the endpoints' mutual discovery typically requires a third party at some point. From the perspective of those two users, the rendezvous function is centralized. Even when not strictly necessary, centralization can be deployed to beneficial ends. notes that "centralized structures can have virtues, such as enabling publics to focus their limited attention for oversight, or forming a power bloc capable of challenging less-accountable blocs that might emerge. Centralized structures that have earned widespread respect in recent centuries – including governments, corporations, and nonprofit organizations – have done so in no small part because of the intentional design that went into those structures." This can be seen when a function requires governance to realize common goals and protect minority interests. For example, content moderation functions impose community values, but can also be viewed as a choke point. Likewise, complex and risky functions like financial services (e.g., credit card processing) can be seen as beneficially centralized into relatively few, specialized organizations, where they can receive the focused attention that they require. When centralization is purposefully used like this, Internet protocols often attempt to mitigate the associated risks using measures such as federation (see ) or governance structures (see ). Protocols that successfully do so are often reused to avoid the considerable cost and risk of re-implementing those mitigations. For example, if a protocol requires a coordinated, global naming function, incorporating the Domain Name System is usually preferable to establishing a new system. Ultimately, deciding when centralization is beneficial is a judgment call. Some protocols cannot function without a centralized function; others might be significantly enhanced for certain use cases if a function is centralized, or might merely be more efficient.

Decentralization While the term "decentralization" has a long history of use in economics, politics, religion, and international development, Baran gave one of the first definitions relevant to computer networking, as a condition when "complete reliance upon a single point is not always required." Avoiding technical centralization -- while not a trivial topic -- is relatively well understood. Doing so for political and economic centralization is considerably more challenge, especially when using only technical tools (like protocol design). Several issues are encountered. First, identifying which aspects of a function to decentralize and how to do so can be difficult, both because there are often many interactions between different types and sources of centralization, and because centralization sometimes only becomes clear after the function is deployed at scale. Indeed, efforts to decentralize often have the effect of merely shifting centralization to a different place -- for example, in its governance, implementation, deployment, or in ancillary functions. In other words, "decentralized technology alone does not guarantee decentralized outcomes." For example, a cloud storage function might be implemented using a distributed consensus protocol, assuring that the failure of any single node will not affect the system's operation or availability. In that sense, it is technically decentralized. However, if it is operated by a single legal entity, that brings the aspect of economic and latent political centralization, especially if there are few other options available, or if there is friction against choosing other options. Another example is the Web, which was envisioned and widely held to be a decentralizing force in its early life. Its potential for centralization only became apparent when large sites successfully leveraged network effects for dominance of social networking, marketplaces, and similar functions. Second, different parties might have good-faith differences on what "sufficiently decentralized" means based upon their beliefs, perceptions and goals. Just as centralization is a continuum, so is decentralization, and not everyone agrees one what the "right" level or type is, how to weigh different forms of centralization against each other, or how to weigh potential centralization against other architectural goals (such as security or privacy). These tensions can be seen, for example, in the DNS. While much of the system is decentralized through the distribution of the lookup function to local servers that users have the option to override, the DNS is also a name space -- a single, global "source of truth" with inherent (if beneficial) centralization in its management. ICANN mitigates the associated risk through multi-stakeholder governance (see ). While many believe that this arrangement is sufficient and might even have desirable qualities (such as the ability to impose community standards over the operation of the name space), others reject ICANN's oversight of the DNS as illegitimate, favoring decentralization based upon distributed consensus protocols rather than human governance. Third, decentralization unavoidably involves adjustments to the power relationships between protocol participants, especially when it opens up the possibility of centralization elsewhere. As Schneider notes in , decentralization "appears to operate as a rhetorical strategy that directs attention toward some aspects of a proposed social order and away from others", so "we cannot accept technology as a substitute for taking social, cultural, and political considerations seriously." Or, more bluntly, "without governance mechanisms in place, nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets." For example, while blockchain-based cryptocurrencies purport to address the political and economic centralization inherent in traditional currencies through technical means, many exhibit considerable concentration of power due to voting/mining power, distribution of funds, and diversity of codebase causes many to question how decentralized they actually are. Over-reliance on technical measures brings an opportunity for latent, informal power structures that have their own risks -- including centralization. In practice, this means that decentralizing a function requires considerable work, is inherently political, and involves a large degree of uncertainty about the outcome. In particular, if one considers decentralization as a larger social goal (in the spirit of how the term is used in other, non-computing contexts), merely rearranging technical functions may lead to frustration. "A distributed network does not automatically yield an egalitarian, equitable or just social, economic, political landscape."

Decentralization Strategies Despite the inherent issues in achieving political and economic decentralization through solely technical means, a few technical strategies are sometimes promoted as addressing not only technical centralization but also political and economic centralization. This section examines some, along with their limitations.

Federation Protocol designers often attempt to address political and economic centralization with federation: designing a function in a way that uses independent instances who maintain connectivity and interoperability to provide a single, cohesive service. Federation promises to allow users to choose the instance they associate with and accommodates substitution of one instance for another, lowering switching costs. However, federation alone is insufficient to prevent or mitigate centralization of a function, because non-technical factors can create pressure to use a central solution. For example, the e-mail suite of protocols needs to route messages to a user even when that user changes network locations or becomes disconnected for a long period. To facilitate this, SMTP defines a specific role for routing users' messages, the Message Transfer Agent (MTA). By allowing anyone to deploy an MTA and defining rules for interconnecting them, the protocol avoids the use of a single, central server. Users can (and often do) choose to delegate that role to someone else, or can run their own MTA. Despite this design, e-mail exhibits a degree of centralization. Part of the reason is a side effect of spam controls; many now consider running a personal MTA to be impractical because of the likelihood of a small MTA being classified as a spam source. Because large MTA operators are widely known and have greater impact if their operation is affected, they are less likely to be classified as such -- creating pressure towards centralization. XMPP is a chat protocol that demonstrates another issue with federation: the voluntary nature of technical standards. Like e-mail, XMPP is federated to facilitate rendezvous of users from different systems - if they allow it. While some XMPP deployments do support truly federated messaging (i.e., a person using service A can interoperably chat with someone using service B), many of the largest do not. Because federation is voluntary, some operators captured their users into a single service, denying them the benefits of global interoperability. The examples above illustrate that, while federation can create the conditions necessary for a function to be decentralized, it does not guarantee that outcome.

Distributed Consensus Increasingly, distributed consensus technologies (such as the blockchain) are touted as a solution to political and economic centralization. A complete survey of this rapidly changing area is beyond the scope of this document, but we can generalize about its properties. These techniques attempt to avoid centralization by distributing functions to members of a sometimes large pool of protocol participants. They typically guarantee proper performance of a function using cryptographic techniques (often, an append-only transaction ledger). A particular task's assignment to a node for handling usually cannot be predicted or controlled. Sybil attacks (where a party or coordinated parties cheaply create enough protocol participants to affect how consensus is judged) are a major concern for these protocols. They encourage diversity in the pool of participants using indirect techniques, such as proof-of-work (where each participant has to show a significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly). Even when distributed consensus is used for all technical functions of a service, some coordination is still necessary -- whether that is through governance of the function itself, creation of shared implementations, or documentation of shared wire protocols. That suggests a path for centralization, just of an indirect nature. For example, the Ethereum "merge" demonstrated that the blockchain could address environmental concerns, but only through coordinated community effort and governance. Furthermore, a protocol or an application can use distributed consensus for some functions, but still be centralized elsewhere -- either because those functions cannot be decentralized (most commonly, rendezvous and global naming; see ) or because the designer has chosen not to because of the associated costs and lost opportunities. These potential shortcomings do not rule out the use of distributed consensus technologies in every instance. They do, however, caution against uncritically relying upon these technologies to avoid or mitigate centralization.

Operational Governance Sometimes technologists attempt to mitigate centralization by incorporating a governance mechanism into a protocol's operation. Often, this is through the establishment of a multi-stakeholder body: an institution that includes representatives of the different kinds of parties that are affected by the system's operation ("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritative decisions. The most widely studied example of this technique is the governance of the DNS name space, which as a “single source of truth” exhibits centralization. The associated risk is managed through administration by the Internet Corporation for Assigned Names and Numbers (ICANN), a global multi-stakeholder body with representation from end users, governments, operators, and others. Another example is the governance of the Web's trust model, implemented by Web browsers as relying parties and Certificate Authorities as trust anchors. To promote the operational and security requirements necessary to provide the desired properties, the CA/Browser Forum was established as an oversight body that involves both parties as stakeholders. These examples are notable in that the governance mechanism is not specified in the protocol documents directly; rather, they are layered on operationally, but in a manner that takes advantage of protocol design features that enable the imposition of governance. Governance in this manner is best suited to very limited functions, like the examples above. Even then, setup and ongoing operation of a governance mechanism is not trivial, and their legitimacy may be difficult to establish and maintain (see, e.g., ); by their nature, they are vulnerable to capture by the interests that are being governed.

What Can Internet Standards Do? Given the limits of decentralization techniques like federation and distributed consensus, the voluntary nature of standards compliance, and the powerful forces that can drive centralization, it is reasonable to ask what stanards efforts like those at the IETF can do to accommodate helpful centralization while avoiding the associated harms -- while acknowledging that the distinction itself is a judgement call, and inherently political. The subsections below suggest a few concrete, meaningful steps that standards bodies can take.

Bolster Legitimacy While technical standards have only limited ability to control political and economic centralization of the Internet, legal standards (whether regulation or legislation) show more promise. However, regulating the Internet is risky without a firm grounding in the effects on the architecture, informed by a technical viewpoint. That viewpoint can and should be provided by the Internet standards community. To effectively do so, its institutions must be seen as legitimate by the relevant parties -- for example, by competition regulators. In particular, if the IETF is perceived as representing or being controlled by "big tech" concerns, its ability to guide decisions that affect the Internet will be diminished considerably. The IETF already has features that arguably provide considerable legitimacy; for example, open participation and representation by individuals rather than companies both enhance input legitimacy; a well-defined process with multiple layers of appeals and transparency contributes to throughput legitimacy, and a long history of successful Internet standards provides perhaps the strongest source of legitimacy for the IETF -- its output. However, it is also widely recognized the considerable costs (not just financial) involved in successfully participating in the IETF have a tendency to favour larger companies over smaller concerns. Likewise, the specialised and highly technical nature of the work creates barriers to entry for non-technical stakeholders. These factors have the potential to reduce the legitimacy of the IETF's decisions, at least in some eyes. Efforts to address these shortcomings are ongoing; see, for example, . Overall, bolstering the legitimacy of the organization should be seen as a continuous effort. When engaging in external efforts, the IETF community (in particular, its leadership) should keep firmly in mind that it is most authoritative when focused on technical and architectural impact. Straying from these topics will likely result in a loss of legitimacy that would likely be difficult to recover from.

Focus Discussion of Centralization Centralization and decentralization are increasingly being raised in technical standards discussions. Any claims needs to be critically evaluated; as discussed in , not all centralization is automatically harmful, and per , decentralization techniques do not automatically address all centralization harms -- and they may bring their own risks. In particular, claims of centralization can be proxies for power struggles between actors with competing interests. A protocol that is deployed by a large, centralized service does not necessarily cause that centralization, but a competitor might use a claim of centralization to deny them the benefit of standardization. Therefore, approaches like requiring a "Centralization Considerations" section in drafts, gatekeeping publication on a centralization review, or committing significant resources to searching for centralization in protocols are unlikely to improve the Internet. Likewise, refusing to standardize a protocol because it does not actively prevent all forms of centralization ignores the very limited power that standards efforts have to do so. Almost all existing Internet protocols -- including IP, TCP, HTTP, and DNS -- fail to do so. While the imprimatur of an Internet Standard is not without value, merely withholding it cannot prevent these sources of centralization. When claims are made that a given proposal is "centralized" or "decentralized", the context of those statements should be examined for presuppositions, assumptions, and omissions. One framework for critical interrogations is offered by , which can be adapted for centralization-related discussions:

1. What is the nature of the (de)centralization that is represented as being problematic?
2. What deep-seated presuppositions or assumptions (conceptual logics) underlie this representation of the "problem"?
3. How has this representation of the problem come about?
4. What is left unproblematic in this problem representation? Where are the silences? Can the "problem" be conceptualized differently?
5. What effects are produced by this representation of the "problem"?
6. How and where has this representation of the "problem" been produced, disseminated, and defended? How has it been and/or how can it be disrupted and replaced?

Discussions should focus on whether claimed centralization is harmful or, if helpful, whether it is justified. Centralization is concerning when it is not broadly held to be necessary, when it has no checks, balances, or other mechanisms of accountability, when it selects "favorites" which are difficult (or impossible) to displace, and when it threatens the architectural features that make the Internet successful. implores that proposals to decentralize be "really, really clear about what particular features of a system a given design seeks to decentralize" and promotes borrowing remedies from more traditional governance systems, such as separation of powers and accountability. When centralization is found, standards efforts should consider its relationship with architectural goals as they consider how and if it should be mitigated (if possible). In particular, attention should be paid to how effective standards (as a form of architectural control) is in achieving each goal. For example, privacy is often more effectively ensured by ex ante technical constraints, as compared to ex post legal regulation. Conversely (as discussed) some centralization may be more effectively addressed through legal regulation. Thus, a standards effort balancing these concerns might bias towards privacy, after informed discussion.

Target Proprietary Functions Functions that are currently only available from proprietary providers are ripe for standardisation efforts. That might include large-scale protocols for existing proprietary functions (e.g., chat) as well as smaller efforts to improve interoperability and portability of specific features that are often used to users into a platform; for example, a format for lists of contacts in a social network. A common objection to this approach is that adoption is voluntary, not mandatory; there are no "standards police" to mandate their use or enforce correct implementation. For example, specifications like ) were available for some time without being used in a federated manner by commercial social networking providers. However, while standards aren't mandatory, legal regulation is, and legal mandates for interoperability are increasingly discussed by policymakers as a remedy for competition issues (see, e.g., ). As such, appetite for regulation presents an opportunity for new specifications to decentralize these functions, backed by a legal mandate in combination with changing norms and the resulting market forces . That opportunity also presents a risk, however, if the resulting legal regulation is at odds with the Internet architecture. Successfully creating standards that work in concert with legal regulation presents many potential pitfalls, and will require improved and new capabilities (especially liaison), and considerable effort. If the Internet community does not make that effort, it is likely that regulators will turn to other sources of interoperability specifications -- most likely, with less transparency, more narrow input, limited experience, and without reference to the Internet’s architectural goals.

Enable Switching To minimize centralization, specifications should have an explicit goal of facilitating users' switching between implementations and deployments of the functions they define or enable. One necessary condition for switching is the availability of alternatives; breadth and diversity of implementation and deployment are required. For example, if there is only a single implementation of a protocol, applications that use it are vulnerable to the control it has over their operation. Even Open Source projects can be an issue in this regard if there are factors that make forking difficult (for example, the cost of maintaining that fork). explores some factors in protocol design that encourage diversity of implementation. The cost of substituting an alternative implementation or deployment by users is another important factor to consider. This includes minimizing the amount of time, resources, expertise, coordination, loss of functionality, and effort required to use a different provider or implementation -- with the implication that the standard needs to be functionally complete and specified precisely enough to allow substitution. These goals of completeness and diversity are sometimes in tension. If a standard becomes extremely complex, it may discourage implementation diversity because the cost of a complete implementation is too high (consider: Web browsers). On the other hand, if the specification is too simple, it may not enable easy switching, especially if proprietary extensions are necessary to complete it (see ). One objection to protocols that enable easy switching is that they reduce the incentives for implementation by commercial vendors. While a completely commoditized protocol might not allow implementations to differentiate themselves, they provide opportunities for specialization and improvement elsewhere in the value chain . Well-timed standards efforts leverage these forces to focus proprietary interests on top of open technology, rather than as a replacement for it.

Control Delegation of Power Some functions might see substantial benefits if they are provided by a third party in communication. Adding a new party to communication can improve:

• Efficiency: Many functions on the Internet are more efficient when performed at a higher scale. For example, a content delivery network can offer services at a fraction of the financial and environmental cost that someone serving content themselves would otherwise pay, because of the scale they operate at. Likewise, a two-sided market platform can introduce sizeable efficiencies over pair-wise buyer/seller trading .
• Simplicity: Completely disintermediating communication can shift the burden of functions onto endpoints. This can cause increased cognitive load for users; for example, compare commercial social networking platforms with self-hosted efforts.
• Specialization: Having a function consolidated into a few hands can improve outcomes because of the resulting specialization. For example, services overseen by professional administrators are often seen to have a better security posture and improved availability.
• Privacy: For some functions, user privacy can be improved by consolidating their activity to prevent individual behaviors from being discriminated from each other. Introduction of a third party can also enforce functional boundaries -- for example, to reduce the need for users to trust potentially malicious endpoints, as seen in the so-called "oblivious" protocols (e.g., ) that allow end users to hide their identity from services, while still accessing them.

However, if that new party is able to make their participation "sticky" -- for example, by leveraging their position in the network to require use of an intermediary, by exploiting their access to data, or by making it difficult to switch to another provider of the function -- there is a risk of centralization. Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constraints on these roles can prevent at least the most egregious abuses of such power. When adding new parties to communication into a protocol, two techniques have proven useful: first, third parties should only be interposed into communication when at least one of the primary parties takes a positive action to do so. Second, these parties should have their ability to observe or control communication limited to what is necessary to perform their intended function. For example, early deployments of HTTP allowed intermediaries to be interposed by the network without knowledge of the endpoints, and those intermediaries could see and change the full content of traffic by default -- even when they are only intended to perform basic functions such as caching. Because of the introduction of HTTPS and the CONNECT method (see ), combined with efforts to encourage its adoption, those intermediaries are now required to be explicitly interposed by one endpoint, and they only have access to basic routing information. See for more guidance on protocol intermediation. The term "intermediary" is also used (often in legal and regulatory contexts) more broadly than it has been in protocol design; for example, an auction Web site intermediates between buyers and sellers is considered an intermediary, even though it is not formally an intermediary in HTTP (see ). Protocol designers can address the centralization associated with this kind of intermediation by standardising the function, rather than restricting the capabilities of the underlying protocols; see .

Enforce Layer Boundaries Most Internet protocols and applications depend on other, "lower-layer" functions and their implementations. The features, deployment, and operation of these dependencies can surface centralization into functions and applications built "on top" of them. For example, application-layer protocols require a network to function, and therefore a degree of power over communication is available to the network provider. They might block access to, slow down, or change the content of a specific service for financial, political, operational, or criminal reasons, creating a disincentive (or even removing the ability) to use a specific provider of a function. By selectively hindering the use of some services but not others, network interventions can be composed to create pressure to use those other services -- intentionally or not. Techniques like encryption can discourage such centralization by enforcing layer boundaries. When the number of parties who have access to the content of communication is limited, parties at lower layers can be prevented from interfering with and observing it. Although those lower-layer parties might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic.

Consider Extensibility Carefully The Internet's ability to evolve is critical, allowing it to meet new requirements and adapt to new conditions without requiring a “flag day” to upgrade implementations. Typically, functions accommodate evolution by defining extension interfaces, which allow optional features to be added or change over time in an interoperable fashion. However, these interfaces can also be leveraged by a powerful entity if they can change the target for meaningful interoperability by adding proprietary extensions to a standard. This is especially true when the core standard does not itself provide sufficient utility on its own. For example, the SOAP protocol's extreme flexibility and failure to provide significant standalone value allowed vendors to require use of their preferred extensions, favoring those who had more market power. Therefore, standards efforts should focus on providing concrete utility to the majority of their users as published, rather than being a “framework” where interoperability is not immediately available. Internet functions should not make every aspect of their operation extensible; boundaries between modules should be designed in a way that allows evolution, while still offering meaningful functionality. Beyond allowing evolution, well-considered interfaces can also aid decentralization efforts. The structural boundaries that emerge between the sub-modules of the function -- as well as those with adjacent functions -- provide touchpoints for interoperability and an opportunity for substitution of providers. In particular, if the interfaces of a function are well-defined and stable, there is an opportunity to use different providers for that function. When those interfaces are open standards, change control resides with the Internet community instead of remaining in proprietary hands, further enhancing stability and enabling (but not ensuring) decentralization.

Future Work This document has argued that while standards bodies have little means of effectively controlling or preventing centralization on the Internet, there are still concrete and useful steps they can take to improve the Internet in this regard. Those steps might be elaborated upon and extended in future work; doubtless there is more that can be done. New decentralization techniques might be identified and examined; what we learn from relationships with other, more effective regulators in this space can be documented. Some have suggested creating a how-to guide or checklist for dealing with centralization. Because centralization is so contextual and so varied in how it manifests, this might best be attempted within very limited areas; for example, for a particular type of function, or a function at a particular layer.

Security Considerations This document does not have a direct security impact on Internet protocols. However, failure to consider centralization might cause a myriad of security issues; see for a preliminary discussion.

Informative References RAND Corporation The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Columbia Law School University of Chicago Law Review, Vol. 82, p. 573 George Washington University Georgetown University International Security, Vol. 44, No. 1, p. 42 Signal Journal of Legal Studies, Vol. 27 Governance: An International Journal of Policy, Administration, and Institutions, Vol. 25, No. 2, p. 237 Yale Law Journal, Vol. 124, No. 3 OECD Communications of the ACM, Vol. 24, No. 2 The Federalist Papers, No. 51 Harvard Business Review, "Breakthrough Ideas for 2004" Northwestern University Law Review, Vol. 104, No. 2 Journal of Cultural Economy, Vol. 12, No. 4 bitcoinera University of Amsterdam Durham University Radboud University Internet Policy Review, Vol. 10, No. 2 The Turn to Infrastructure in Internet Governance Berkeley Journal of Sociology, Vol. 17 Hacker Noon Chapter 2, Engaging with Carol Bacchi Ethereum This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community. This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. Mozilla This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide.

Acknowledgements This document was born out of early discussions with Brian Trammell during our shared time on the Internet Architecture Board. Special thanks to Geoff Huston and Milton Mueller for their well-considered, thoughtful, and helpful comments. Thanks also to Jari Arkko, Kristin Berdan, Christian Huitema, Mallory Knodel, Eliot Lear, John Levine, Tommy Pauly, and Martin Thomson for their comments and suggestions. No large language models were used in the production of this document.