2

Centralization, Decentralization, and Internet Standards

 2 years ago
source link: https://www.ietf.org/archive/id/draft-nottingham-avoiding-internet-centralization-05.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

2. Centralization

This document defines "centralization" as the ability of a single entity or a small group of them to exclusively observe, capture, control, or extract rent from the operation or use of an Internet function.

Here, "entity" could be a single person, a corporation, or a government. It does not include an organisation that operates in a manner that effectively mitigates centralization (see, e.g., Section 3.1.2).

"Internet function" is defined broadly. It might be an enabling protocol already defined by standards, such as IP [RFC791], BGP [RFC4271], TCP [RFC793], or HTTP [HTTP]. It might also be a proposal for a new enabling protocol, or an extension to an existing one.

However, the Internet's functions are not limited to standards-defined protocols. User-visible applications built on top of standard protocols are also vulnerable to centralization -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, networking equipment, hardware, operating systems, and software act as enabling technologies that can exhibit centralization. The supply of Internet connectivity to end users in a particular area or situation can also be subject to the forces of centralization, as can supply of transit between networks (so called "Tier 1" networks).

Centralization is not a binary condition; it is a continuum. At one extreme, a function absolutely controlled by a single entity (see Section 2.2.1) represents complete centralization; at the other extreme, a function whose value can be realised by any two parties without the possibility of any external interference or influence represents complete decentralization (sometimes referred to as "distributed" or "peer-to-peer").

While a few functions might occupy the ends of this spectrum, most reside somewhere between the extremes. Therefore, it is often useful to consider the amount of centralization risk associated with a function, depending on the scale, scope, and nature of the influences on it. Note that a function might have more than one source of centralization risk, each with its own characteristics.

Centralization risk is strongest when it affects the entire Internet. However, it can also be present when a substantial portion of the Internet's users lack options for a function. For example, if there is only one provider for a function in a region or legal jurisdiction, that function is effectively centralized for those users.

Centralization risk is most obviously created by the direct assignment of a role to a single entity, but it is also created when a single entity takes on that role for other reasons. For example, friction against switching to a substitute provider of a function often leads to concentration (see Section 2.2.3). If switching requires a significant amount of time, resources, expertise, coordination, loss of functionality, or effort, centralization risk is indicated. Conversely, a function based on a well-defined, open specification designed to minimize switching costs might be considered to have less centralization risk even when there are only a few large providers.

This definition of centralization focuses largely upon the relationships between parties to communication, rather than systems design. For example, a cloud service might use decentralized techniques to improve its resilience but still be operated by a single entity, thereby exhibiting the kind of centralization that this document is concerned with. A failure due to a cut cable, power outage, or failed server is qualitatively different from the issues encountered when a core Internet function has a gatekeeper.

As a result, the concept of availability is distinct from centralization, and any relationship between them cannot be assumed without careful analysis of where and how centralization occurs. Centralized systems might be more available due to factors like the resources available to them, but also have greater impact when they have a fault; decentralized systems might be more resilient in the face of local failures, but less able to react to systemic issues.

For example, a large variety of Web sites might depend upon a cloud hosting provider or content delivery network; 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 engaged 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.

Also, it is important to distinguish centralization from anti-competitive concerns (also known as "anti-trust"). While there are many interactions between these concepts and making the Internet more competitive may be a motivation for avoiding centralization, only courts have the authority to define a relevant market and determine that behaviour is anti-competitive. Furthermore, what might be considered undesirable consolidation by the technical community might not attract competition regulation, and conversely what might attract competition regulation might not be of great concern to the technical community if other mitigations are felt to be adequate.

2.1. When Centralization is Undesirable

There are three overarching reasons why centralization of Internet functions can be concerning.

First, the Internet's very nature is incompatible with centralization. As a "large, heterogeneous collection of interconnected systems" [BCP95] the Internet is often characterised as a "network of networks". These networks relate as peers who agree to facilitate communication, rather than having a relationship of subservience to others' requirements or coercion by them. This focus on independence of action carries through the way the network is architected -- for example, in the concept of an "autonomous system".

Second, when a third party has unavoidable access to communications, the informational and positional advantages gained allow observation of behaviour (the "panopticon effect") and shaping or even denial of behaviour (the "chokepoint effect") [JUDGE] -- capabilities that those parties (or the states that have authority over them) can use for coercive ends [FARRELL] or even to disrupt society itself. Just as good governance of states requires separation of powers [MADISON], so too does good governance of the Internet require that power not be concentrated in one place without appropriate checks and balances.

Finally, centralization of a function can have deleterious effects on the Internet itself, including:

  • Limiting Innovation: Centralization 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.
  • Constraining 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 encourages abuse of power.
  • Reducing Availability: Availability of the Internet (and applications and services built upon it) improves when there are many ways to obtain access. While centralized services' availability can benefit from the focused attention that their elevated role requires, failure of a large, centralized provider can have a disproportionate impact on availability.
  • Creating Monoculture: The scale available to a centralized service or application 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 these functions' implementation leads to a more robust outcome when viewed systemically. [ALIGIA]
  • Self-Reinforcement: As widely noted (see, e.g., [VESTAGER]), a centralized service's access to data allows it the opportunity to make improvements to its offerings, while denying such access to others.

See also [KENDE] for further exploration of how centralization can affect the Internet.

As discussed below in Section 2.2.2, not all centralization is undesirable or avoidable. [SCHNEIDER] 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."

With that in mind, centralization risk on the Internet is most concerning when it is not broadly held to be necessary, when it has no checks, balances, or other mechanisms of accountability, when it selects "favourites" which are difficult (or impossible) to displace, and when it has the damaging effects outlines above, or the potential for them.

2.2. Kinds of Centralization

Centralization on the Internet is not uniform; it presents in a variety of ways, depending on its relationship to the function in question and underlying causes. The subsections below describe different aspects of Internet centralization.

2.2.1. Proprietary Centralization

Creating of a protocol or application with a fixed role for a specific party is the most straightforward kind of centralization. Many messaging, videoconferencing, chat, social networking, and similar applications operate in this fashion currently.

Because they allow control by a single entity, proprietary protocols are often considered simpler to design, more amenable to evolution, and more likely to meet user needs [MOXIE], compared to decentralized alternatives. However, they have corresponding centralization risk -- if the function has no alternative providers, or switching to those providers is too difficult, its users are "locked in."

Proprietary protocols and applications are not considered as being part of the Internet per se; instead, they are more properly characterized as being built on top of the Internet. The Internet architecture and associated standards do not regulate them, beyond the constraints that the underlying protocols (e.g., TCP, IP, HTTP) impose.

2.2.2. Beneficial Centralization

Some protocols and applications have goals that require the introduction of a centralized function. In doing so, they are explicitly relying on centralization to deliver a particular benefit.

For example, a function that needs a single, globally coordinated "source of truth" is by nature centralized -- such as in the Domain Name System (DNS), which allows human-friendly naming to be converted into network addresses in a globally consistent fashion.

Another function exhibiting beneficial centralization is IP addresses allocation. Internet routing requires addresses to be allocated uniquely, but if a single government or company captured the addressing function, the entire Internet would be at risk of abuse by that entity. Similarly, the need for coordination in the Web's trust model brings centralization risk, because of the Certificate Authority's role in communication between clients and servers.

Protocols that need to solve the "rendezvous problem" to coordinate communication between two parties who are not in direct contact also suffer from this kind of 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 has centralization risk.

Likewise, when a function requires governance to realize common goals and protect minority interests, a "choke point" is naturally formed by the chosen governance mechanism, increasing centralization risk. For example, defining and applying a content moderation policy both have centralization risk.

Deciding what 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. Such judgments should be made in light of established architectural principles and how benefits accrue to end users.

When beneficial centralization is present, Internet protocols often attempt to mitigate the associated risks using measures such as federation (see Section 3.1.1) and multi-stakeholder governance (see Section 3.1.2). Protocols that successfully mitigate beneficial centralization 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, reusing the Domain Name System is usually preferable to establishing a new system.

2.2.3. Concentrated Centralization

Even when a function avoids proprietary centralization and mitigates any beneficial centralization present, it might become centralized in practice when external factors influence its deployment, so that few or even just one entity provides the function. This is often referred to as "concentration." Economic, legal, and social factors that encourage use of a central function despite the absence of such a requirement in the protocol itself can cause concentration.

Often, the factors driving concentration are related to the network effects that are so often seen on the Internet. While in theory every node on the Internet is equal, in practice some nodes are much more connected than others: for example, just a few sites drive much of the traffic on the Web. While expected and observed in many kinds of networks, network effects award asymmetric power to nodes that act as intermediaries to communication. [BARABASI]

For example, social networking is an application that is currently supplied by a few proprietary platforms despite standardization efforts (see, e.g., [ACTIVITYSTREAMS]), because of the powerful network effects associated. While there has been some competition in social networking, a group of people who wish to communicate are often locked in by the choices that their peers make, because of the coordination required to move to a new service.

See [ISOC] for a deeper exploration of concentration.

Concentration is difficult to avoid in protocol design, and federated protocols are particularly vulnerable to it (see Section 3.1.1).

2.2.4. Inherited Centralization

Most Internet protocols and applications depend on other, "lower-layer" protocols 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, the network between endpoints can introduce centralization risk to application-layer protocols, because it is necessary for communication and therefore has power over it. A network might block access to, slow down, or change the content of various application protocols or specific services for financial, political, operational, or criminal reasons, creating pressure to use other services, which can cause their centralization.

Likewise, having only a single implementation of a protocol is an inherited centralization risk, because applications that use it are vulnerable to the control it has over their operation. Even if it is Open Source, there might be inherited centralization if there are factors that make forking difficult (for example, the cost of maintaining that fork).

Inherited centralization is often present when network effects restrict choices, but can also be created by legal mandates and incentives that restrict the options for a function (such as Internet access), its provision, or the range of implementations available.

Some kinds of inherited centralization can be prevented by enforcing layer boundaries through use of techniques like encryption. When the number of parties who have access to content of communication are 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 traffic.

Note that the prohibitive effect of encryption on inherited centralization is most pronounced when most (if not all) traffic is encrypted. See also [RFC7258].

2.2.5. Platform Centralization

The complement to inherited centralization is platform centralization -- where a function does not directly define a central role, but could facilitate centralization in the applications it supports.

For example, HTTP [HTTP] is not considered a centralized protocol; interoperable servers are easy to instantiate, and multiple clients are available. It can be used without central coordination beyond that provided by DNS, as discussed above.

However, applications built on top of HTTP (as well as the rest of the "Web Platform") often exhibit centralization (for example, social networking). HTTP is therefore an example of a platform for centralization -- while the protocol itself is not centralized, it facilitates the creation of centralized services and applications.

Like concentration, platform centralization is difficult to prevent with protocol design. Because of the layered nature of the Internet, most protocols allow considerable flexibility in how they are used, often in a way that it becomes attractive to form a dependency on one party's operation.


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK