Problem Statement & Use Cases for Human-Centric Networking

2.1.1. Surveillance Capitalism

The term is popularized in the 2019 book "The Age of Surveillance Capitalism" [AOSC], and is defined on Wikipedia as follows:¶

• Surveillance capitalism is a concept in political economics which denotes the widespread collection and commodification of personal data by corporations. [SURVEILLANCE-CAPITALISM]¶

Surveillance capitalism can only thrive in a system where personal data is easily available. Additionally, "data" is relatively worthless in itself until it is linked to other data, such as linking a name to the purchase of some medication. Once the link is established, one can infer further information, such as that the person making the purchase likely suffers from a condition that the medication is commonly prescribed for. It is then feasible to exploit this link by e.g. targeting advertising or deals at audiences with the highest probability of a "conversion" (i.e. sale).¶

One cannot link data without collecting it, which means that data collection is the activity that fuels the establishment of more links, and thus the opening of more potential revenue streams.¶

Attempts at curbing surveillance capitalism through policy tend to focus on company size or monopoly position. However, as Tarnoff notes in "Internet for the People" [IFTP], it is competition that drives data collection. Specifically, it is the competitive motivation to discover new or better monetizable links between individual data points.¶

2.1.2. Information Warfare

According to Zuboff, data collection is not necessarily problematic in itself. The problems arise during usage: when personal profiles are used to target advertising to the recipient, they can also be used to target disinformation, and thus drive decision making processes. Either is monetizable, and the logic of capitalism dictates that such monetization avenues must be exploited.¶

Surveillance capitalism, in other words, enables power brokerage to become indistinguishable from demagogy. It is no longer necessary to target specific powerful politicians to influence them, when instead one can manipulate their electorate.¶

A plethora of political events in recent years demonstrate not just the possibility of this, but the practice as well. Psychographic profiling of Facebook users, allowed and continues to allow for voter manipulation at a massive scale. And yet, the FTC response to one such event "has been criticized as failing to adequately address the privacy and other harms emanating from Facebook’s release of approximately 87 million Facebook users' data, which was exploited without user authorization." [CAMBRIDGE-ANALYTICA]¶

Meanwhile, these tactics are further expanded upon in so-called "hybrid warfare" that bridges the battlefield and disinformation campaigns [HYBRID-WARFARE]. The basis, however, remains the same: access to user information that permits to identify demographics vulnerable to disinformation attacks.¶

2.1.3. Centralization

Where surveillance capitalism describes the market mechanics that lead to data collection en masse, it fails to describe the more technical effect this has: the Web becomes increasingly centralized.¶

Web centralization has multiple contributing factors. One of the more fundamental ones, however, is that it is significantly easier to collect more data and establish more impactful links, the more data is funnelled through a centralized service. Competitive advantages are gained when one provides this service.¶

This is essentially equivalent to any other factor contributing to the emergence of monopolies; the key differences are that:¶

• Antitrust laws are more effective in other markets outside of electronic mass data collection, and¶

• centralization of data collection can be sold more easily as a feature than a bug; so-called "platforms" ostensibly create new markets while enabling the platform owners to skim a significant share of the proceeds.¶

The "centralization" term, however, is hotly debated. For every argument that a system is centralized, counter-arguments can be raised. The somewhat surprising realization in this is that most of these arguments are either due to¶

1. An instance of the "layering problem", whereby participants in a debate view distinct layers of the system stack (e.g. the World-Wide Web vs. the Internet).¶

2. Participants have an unclear definition of how one should measure "centralization".¶

For the purposes of this document, we define the "centralization" as more or less identical to the definition of "betweenness centrality" in network or graph theory. "Betweenness centrality" examines communication flows between nodes in a communication graph, from all nodes A via any number of intermediary nodes to all nodes B. For every node C (that is not part of A or B), it counts the number of communication flows it is part of along the path, i.e. it is "between"; higher counts mean higher centrality.¶

The measure is useful because it can be applied to any layer of a communications stack, and may yield different results at each layer. For example, an [OAUTH] provider may sit "between" an identity management system and many applications, even if at a lower network layer, traffic is routed to each of these parties along entirely non-overlapping paths.¶

Centralization as "betweenness centrality" illustrates the dangers of such centralized designs -- the highly centralized node becomes a single point of failure for a much larger system:¶

• It can disrupt many services when the centralized node experiences disruption.¶

• It is easier to gain access and maliciously manipulate or harvest data on one centralized node than in a widely distributed system.¶

The above describe failure modes of centralization. Proponents of centralization argue that mitigating against such failures also becomes easier with centralization. While true to an extent, similar effects can be achieved with processes and tooling, without introducing the risk of these specific failures.¶

2.1.4. Oppression & Genocide

The Internet is a great enabler for communities to come together; this is in particular the case for minority communities that have no other representation in popular media. The Uyghur of China are such a minority, whose usage of the Internet to keep their identity alive has been well documented [UYGHUR-INTERNET].¶

Equally well documented, unfortunately, is the "cultural genocide" of the Uyghur [UYGHUR-WAR]. The role of the Internet in this is just as central as it was in bringing the community together in the first place. Reports indicate that China is using artificial intelligence operating on personal profile data to identify Uyghur and to target them methodically [UYGHUR-AI].¶

Similarly, the Amnesty International report [AUTOMATED-APARTHEID] illustrates already in 2023 how Isreal's use of facial recognition "fragments, segregates and controls Palestinians" in the Occupied Palestinian Territories. A year later, the organization updates the situation specifically in Gaza, calling it "genocide" ([GAZA-GENOCIDE]) - a view informed by the ongoing and updated case 192 of the International Court of Justice against Israel [GAZA-GENOCIDE-ICJ].¶

From the perspective of Internet engineers, it is not necessary to understand the ins and outs of a specific political situation. What is required is the broad understanding that collecting large amounts of personally identifiable information (PII) in a central location enables devastating misuse. The consequence then must be to protect PII and avoid centralization to counteract this.¶

2.1.5. Machine Learning

The role of artificial intelligence in Section 2.1.4 is one use where access to PII can be abused. The article "Artificial Intelligence, Advertising, and Disinformation" [ML-DISINFORMATION] lays out the overlap between these technologies in more detail.¶

It is one thing where machine learning is used to impersonate a politician as part of a disinformation campaign. But images and videos of politicians are public goods, as such persons partially give up their right to privacy in being public figures.¶

Given access to PII, the exact same technology can be used in more personal cyber attack scenarios: for example, access to voice recordings can allow an attacker to use a cloned voice in an attack scenario [ML-VOICE].¶

The ramification is that with more PII available, ML-based attacks or attacks making use of ML techniques evolve to exploit this access.¶

2.1.6. State Control over Media & Censorship

Whereas previous examples focused to a large degree on availability of personally identifiable information which may be acerbated by centralization, centralization poses an additional risk all by itself: centralization aids censorship.¶

The CensoredPlanet project [CENSORED-PLANET] monitors censorship of the internet around the globe, using a variety of techniques. However, they all revolve around measuring access to parts of the internet, such as the parts serving a news site, or an entire country's network.¶

It's worth highlighting that access is not necessarily binary here. Rather than blocking access, a particular path may merely become slowed down to the point where Internet users prefer to turn to other resources instead.¶

In either case, censorship relies on identifying targets to censor. The more access to targets is funneled through centralized choke points, the easier it is to apply censorship in those locations.¶

In many cases, this can be as simple as government buying media outlets outright, a practice that has led to the establishment of the Media Development Investment Fund (MDIF) [MEDIA-INDEPENDENCE]. In this latter form, centralization affects media production in any given outlet than access to the results.¶

It is necessary to consider the entire pipeline from media creation to consumption, however. Arguably the role of media outlets has historically been to collect potential news, filter this for some notion of "quality" to bring a subset of this source material to production, and then to distribute it again.¶

In a fully digitized world, collection and distribution find equivalences in ingress and egress traffic, while the news production itself is a data processing task. In other word, the media outlet model is centralized largely because the data processing tasks would historically have been impossible to distribute. This centralization, however, is also the cause for its vulnerability to state control and censorship.¶

It is imaginable, then, that if data processing tasks are easy to distribute, and the Internet offers the infrastructure to do so, that media censorship would become a significantly harder endeavor.¶

2.1.7. Information Loss

Previous problems were for the most part focused on data collection and centralization of critical services. A different, yet technically related issue also plagues the Web, that of so-called "link rot".¶

The term describes the fact that when a web page links to some other page or resource on the web, the target may disappear at any time. For the most part, this is an unfortunate feature of decentralization - namely decentralization of editorial control, in this case. As the site hosting the target resource of a link may undergo redesign, and redesign often (unfortunately) goes hand in hand with reorganization of URLs, once valid URLs may become invalid. It follows that any link pointing at this URL equally becomes invalid.¶

The web is not the only system to link information. Scientific publications often reference each other. For purposes such as this, the Digital Object Identifier ([DOI]) scheme has been standardized. In order to remain relevant in hyperlinked systems, the DOI scheme also includes mechanisms for resolving a DOI to a URL that "owners" of the DOI can update. A specialized service by the DOI foundation resolves URLs with a DOI, and redirects to the current target URL. In this fashion, DOIs represent stable identifiers and can be used to create stable links on the web that resist bit rot.¶

However, as the example of [NIST.IR.8366] tragically showcases, nothing prevents the target website from keeping URLs intact, but alterting the content or redacting it entirely.¶

While all the reasons that make centralized control over information resources apply (see issues with e.g. mis- or disinformation above), lack of truly stable identifiers for information resources also make the building and maintenance of information networks significantly harder. Additionally, restricting access to once available information can be used to influence just as much as not granting access in the first place.¶

When considering the preservation of the total body of human knowledge, resilient to accidental or malicious loss, stable identifiers to information resources are a key ingredient that DOIs unfortunately fail to solve.¶

In addition to stability, identifiers should also be verifiable. That is, it should be possible to verify that a piece of information, a sequence of Bytes encoding some knowledge, is actually the sequence of Bytes that is meant to be indicated by an identifier. There are several technical means at our disposal to verify such things, but they require an information theory approach that URLs completely lack; URLs are not in themselves verifiable in this fashion.¶

Finally, if sequences of Bytes can be linked to identifiers, then the storage location of that sequence of Bytes on any particular server is no longer of paramount concern. Such sequences of Bytes can be infinitely copied and archived, and still be identifiable. In this way, verifiable identifiers become the engine of knowledge preservation that the current web lacks.¶

It should be mentioned that several attempts have been made to create stable identifiers on the web, but the efforts largely failed. The most noticeable remnant of these efforts is visible in the distinction between URIs and URLs, i.e. Uniform Resource Identifiers and Locators. The idea has been for a long time to introduce resolvers to the web that resolve from URIs to URLs, but a standard for such resolvers has not become commonplace.¶

2.1.8. Intermittency

Equally unrelated to problems of data and centralization, but equally linkable to such issues is the fact that neither the Internet nor Web truly deal well with intermittency, that is delay or disruption in communications.¶

The Internet is designed to be a synchronous communications network for computers. Its mechanics allow for short delays, and a fair few efforts are directed at making such delays as short as possible (e.g. [RFC9330] and related work).¶

The general approach to intermittency on both the Internet and Web is to introduce timeouts for queries, which then potentially result in renewed attempts to perform the query, or ultimately errors displayed to the user. While this is a valid approach for basic machine-to-machine communications, several use cases present rather more stringent requirements; these include e.g. command and control of vehicles in remote locations.¶

It's also worth highlighting that this approach to intermittency is actively exploited in censorship (see Section 2.1.6), that is, access to resources is deliberately slowed down to incur errors.¶

2.2.1. Internet vs. Web

In the above text, and the rest of this document, the term "Internet" and "Web" (referring to the World Wide Web, or WWW) are used more or less interchangeably.¶

It is clear to the author(s) that these are distinct technologies, and that from the Internet's point of view, the Web is but one of many application protocols.¶

At the same time, in practice the Web is used almost ubiquitously from the point of view of Internet users. This therefore raises the question why this has come to be?¶

The arguments for or against this state of things are too numerous to list here. To provide a simpler lens, consider the following statement: "The Internet connects machines. The Web connects people."¶

In fact, no parts of the Internet protocols are particularly concerned with people. Addressing happens on a per-machine basis -- ignoring for the moment the ability to address more abstract things such as multicast groups or more concrete things such as the link on the machine that is configured to respond to a particular address.¶

Web technology, on the other hand, is concerned with what it terms "resources", a malleable concept that can represent digital or physical "things" as well as oneself or other people's digital identities. Furthermore, through user based authentication methods, the Web firmly establishes itself as being concerned with bridging between the purely digital and the physical or hybrid worlds.¶

If this statement is true, then the prevalence of Web-based applications may simply be explained by the fact that humans are trying to solve human problems with technology, and this often involves having a notion of how a human may be represented in the digital realm.¶

Arguable, then, from this human perspective the distinction between the Internet and the Web is moot, even if the engineering perspective differs. This "end-user perspective" demands that future Internet evolution is free to adopt concepts from the Web, such as relating to e.g. resources and user identification.¶

Doing so may not only open avenues for evolution that the current stricter split of concerns keeps firmly closed. It also permits the Internet, rather than one of its applications, to become the substrate for transporting people's actual, real world concerns.¶

On the other hand, as Section 2.1.8 on intermittency highlights, this in no way implies that all characteristics of the Web's design should be adopted as they are in future Internet evolutions. In fact, the strong suggestion here is that neither the Internet nor Web can be the complete answer to current and foreseeable use cases for the Internet.¶

2.2.2. Generative Systems vs. Tethered Appliances

In "The Future of the Internet" [FUTURE-INTERNET], Zittrain describes what he calls "tethered appliances" and "generative systems". In this definition, a tethered appliance, like a kitchen appliance, fulfills a strictly limited set of functions, determined by the manufacturer. It may be "tethered" in the same way that telephone sets used to be distributed by Bell/AT&T, intrinsically linked to the purchase of a phone line.¶

Zittrain contrasts this to "generative systems" such as the Personal Computer (PC). Here, a semi-finished product with no particular purpose other than to provide compute resources was brought to market -- and flourished, and in so doing changed the world.¶

He argues that the Internet is such a generative system. When it came to be, few could envision the impact it would have on the world today. He identifies as the reason that, having no specific purpose, the Internet was open to be used for whichever purpose its users desired.¶

Generative systems not only offer incredible flexibility, and allow for providing solutions to age-old problems. Human ingenuity will also be able to monetize such solutions. Zittrain observes that the businesses that profit most from the generative nature of a system eventually reach a point where innovation no longer matters; instead, the logic of capitalism dictates that efforts now need to be expended to shut out competition. In effect, it is in the same businesses' interest now to turn the erstwhile generative system into an appliance tethered to their business model.¶

This view is picked up and largely confirmed in the latter "Internet for the People" by Tarnoff. Where the earlier book predicts the direction the Internet may evolve in, the latter confirms its evolution.¶

Both authors agree, each in their own terms, that the way to "save" the Internet is to re-focus attention on what made it generative in the first place: it served as a substrate for nothing specific, and so for everything and anything.¶

Where the Internet is perhaps more focused on the problems relating to establishing machine-to-machine communications, the Web has shown us that this "anything and everything" refers to human concerns.¶

3.1.1. Document Web

The original use of the Web was dissemination of knowledge in the form of publication of documents. This is effectively what the PUT, GET and DELETE methods of HTTP ([RFC7231], Section 4.3) embody: a means to store, retrieve and delete documents from a Web server.¶

The scope of these operations is an entire resource. HTTP permits optional Range requests [RFC7233] to target sub-resources, but here an interesting dynamic prevents its use across a wide variety of use cases.¶

On the one hand, the [REST] architectural style that HTTP implements requires that data transferred be "representational". The idea is that it is up to the service implementor how to persist data, which representations to send, and which to accept. However, it is explicitly not implied that the byte sequences that the service sends and receives are identical to the byte sequences it persists.¶

On the other hand, the Range header operates on byte ranges. Mapping byte ranges of a data representation that differs from the byte ranges of a data storage format onto each is no easy task; it should therefore not be surprising that Range headers are most often used when the representation matches the storage format, i.e. the methods operate on what's commonly described as Binary Large Objects (BLOBs).¶

In summary, the Document Web use case class is best described as one offering simple operations for manipulating entire resources (or their representations). This is likely why the "RESTful" design style (not to be confused with [REST] itself) is characterized by mapping the PUT, GET, POST and DELETE methods directly onto Create, Read, Update and Delete (CRUD) operations. Even though HTTP offers other uses with such extensions as the Range header, it is an uncomplicated mapping, and therefore easily and widely adopted.¶

3.1.2. API Web

The next use case class treats the Web as a remote procedure call (RPC) protocol, in which resources or resource collections are mostly referred to as application programmer interfaces (APIs) today.¶

The API Web is not fundamentally distinct from the Document Web in the HTTP methods it employs. But API endpoints (resources) no longer represent a document or document type, but a functionality the client wishes to invoke. As such, the data representation format chosen tends to reflect the needs of APIs, where structured data is transmitted, which may refer to multiple other resources ("connect 'foo' to 'bars' A, B and C"). More rigorous approaches in the API web identify abstract objects via their resource locators (URLs).¶

APIs, as the name suggest, provide interfaces also between distinct engineering teams. As such, common standards have been created and discarded across the existence of the Web, such as [SOAP] and the currently popular [OPENAPI]. These provide interoperability by layering a protocol for specifying RPC invocations onto the HTTP protocol.¶

In reality, services will usually provide a mixture of API and Document Web functions. The main conceptual distinction between the two use case classes lies in the expectations around the meaning and freshness of a response.¶

Documents are by nature fixed and self-contained. They can be revised, and refer to other documents to understand them. But each revision is effectively a new document, albeit sharing a history with its predecessors.¶

An API response, on the other hand, is ephemeral. It describes the result of an operation. The same operation performed at another point in time may yield a different result.¶

In HTTP, this difference is expressed in caching. The standard provides many headers relating to the longevity or freshness of a response. In Document Web use cases, it can typically be assumed that a response has a fairly long validity -- while in API use cases, this is not a valid assumption.¶

API Web then differs from Document Web in that the resources one accesses represent functions rather than documents, and the responses it produces are ephemeral and contextual rather than self-contained and long-lived.¶

3.1.3. Real-time Web/Streaming

Beyond the Document and API Web, there exists also a class of use cases related to data streaming.¶

Streaming is itself a term with somewhat ambiguous meaning. In our case, let's interpret it as one party in a network transaction consuming some related data (such as a resource), before the other party has finished producing it.¶

Consuming and producing can be understood as receiving and sending data over the network, but may also include processing on either side to create or display the resource in some fashion. That is to say, the sending party does not need to generate data in this view, but may simply not be finished sending it -- live data generation, however, is also included in this defnition.¶

In principle, this can be mapped onto HTTP in arbitrary ways. Range header usage is predestined for a subset of this sort of use, but it is equally possible to structure the resource into individual documents that are requested in sequence. This latter use, for example, is how "HTTP Live Streaming" [RFC8216] segments a streaming resource into individual media segments. Finally, repeated calls to the same or different API endpoints may produce the data incrementally.¶

The precise mapping onto HTTP mechanics barely matters. The main point of this use case class is that there is a real-time component to it in a processing pipeline. Producers of data can produce data only at a certain pace. Transmission is bounded by the available throughput rate of the network path. Consumers may also only render data at a given pace.¶

What distinguishes the Real-time Web use case class from the previous two is that it includes attempts at matching the network throughput rate and latency to the capabilities and expectations of either of consumer, producer or both. This is distinct enough from the other use cases to warrant its own use case class.¶

3.2.1. Resilience

Preceding the birth of the Internet, Paul Baran described different communication architectures in [RM3420], which he terms "centralized", "decentralized" and "distributed". He comes to the conclusion that the "distributed" model offers the highest resilience against communications failures, which led to the packet switching paradigm of the Internet.¶

In the "distributed" model, communications nodes have connectivity with multiple other nodes. In order to communicate with any node, the data packets they send can traverse many intermediary nodes. When one such node fails, a different path can be taken.¶

By and large, the Internet remains distributed in nature. A number of incentives may push towards more centralization, but this is less to do with the Internet's architecture than the interests of Internet service providers.¶

The Web, for similar reasons, shows much stronger trends towards centralization. Works such as [RFC9518] assess the specific reasons, as well as what standards can do about them in far more detail than this document can.¶

Centralization introduces real-world risks, as explored in Section 2, some of which directly relate to notions of resilience. One such example would be that centralization often weakens resilience against censorship. If the Web shows tendencies towards centralization, it follows that heightened resilience is a use case that is not typically captured by Web technology -- and yet may help mitigate issues raised in the first part of this document.¶

3.2.2. Remote Locations

There is no particular argument for physical location to factor into Internet or Web usage -- but underlying protocols that facilitate connectivity may suffer in some geographical locations. This has follow-on effects for performance and user experience of the Web stack as a whole, which may negatively affect its suitability for a particular use case.¶

3.2.3. Energy Usage

Of growing importance is the energy usage of any networked environment. Using renewable energy for e.g. hosting [GREEN-HOSTING] is commendable, but one cannot require green energy usage in a networking protocol; no practical means of enforcement of such rules exists. However, at the protocol design level, it is possible to consider how much energy may be used.¶

The approach, dubbed "green coding", is gaining attention in recent years ([GREEN-CODING-1], [GREEN-CODING-2], [GREEN-CODING-3], etc.). In the realm of networking protocols, the design approach reduces to a relatively simply method: reduce transmissions.¶

In practice, things are not as simple as that: measurements are needed to determine energy usage in a variety of scenarios. But each packet transmitted induces energy usage not only for the transmission itself, but also for the processors performing packet switching decisions. It is clear that reducing the packet transmission rate by design will have an effect on reducing energy usage.¶

One approach to this is to treat caching of remote data as a first class problem, such that transfer can be avoided as much as possible.¶

3.2.4. Data Protection

Increasingly, digital rights are seen as variants of fundamental human rights; in the European Union, the European Parliament and the Council of Europe jointly signed a European Declaration on Digital Rights and Principles, which some researchers consider "transformative" [DIG-RIGHTS].¶

This relatively local legislation reflects a larger trend in tending to digital rights of citizens worldwide, which inevitably influences data protection practices.¶