Author: Cecil Ellis (Page 7 of 22)

We like to think of technical standards as quiet, neutral infrastructure—just the plumbing that makes the internet work. But every standard, from BGP to HTTP/3, is a record of choices. Choices about who gets to control traffic, who shoulders the operational costs, and whose interests get baked into the defaults. When a new protocol drops and the applause starts, it’s worth pausing to ask: who was in the room, and what were they optimizing for? For network operators, end users, and platform providers, the answers shape who holds power in ways that are easy to overlook but hard to undo.

Look around the landscape and you’ll see the fingerprints of these decisions everywhere—in the way DNS resolution has quietly migrated toward a handful of global resolvers, in how congestion control algorithms favor content-rich giants, in the assumptions about bandwidth and latency that leave community networks and rural ISPs scrambling for workarounds. The organizations that write the rules—the IETF, W3C, 3GPP—each have their own governance quirks, funding models, and dominant players. Knowing who sits at the table isn’t a parlor game; it’s a way to understand why your traffic takes the path it does, why some encryption models win out, and why the network sometimes feels like it was built for someone else.

The Room Where It Happens

Standards bodies aren’t some meritocratic ideal. They’re arenas where competing economic interests hash out technical specs that will, in turn, reshape markets. The IETF likes to talk about rough consensus and running code, but look at who actually shows up. Participation leans heavily toward engineers from big equipment vendors, content delivery networks, and hyperscale cloud providers. A 2021 Internet Society study found that over 60% of IETF participants came from just 20 organizations—mostly large corporations. That’s not a conspiracy; it’s a simple matter of who can afford to send engineers to three meetings a year and pay them to write drafts in between.

The result is a set of standards that mirror the operational realities of the people in the room. Take Multipath TCP (MPTCP). It was built with assumptions about middlebox behavior that made perfect sense for large content providers but created real deployment headaches for smaller network operators. The standard wasn’t malicious. It was just written by folks whose primary experience of the network was from the data center outward, not from the last mile inward.

Case Study: The QUIC Working Group

QUIC, the transport protocol that underpins HTTP/3, often gets held up as a triumph of internet engineering. And it does some clever things: it cuts latency, improves multiplexing, and encrypts transport-layer metadata that TCP left hanging out in the open. But the working group that produced it was dominated by Google employees in its early, formative years. Google had already rolled out its own version of QUIC across its services and Chrome before the IETF process even kicked off. The standard that emerged wasn’t a clean-slate design; it was a negotiation between Google’s existing implementation and the concerns of other large players—middlebox vendors and mobile network operators, mostly.

This isn’t a knock on the engineers involved. Plenty of them worked hard to accommodate different viewpoints. But the starting point matters. When a single organization deploys a protocol at scale before standardization, the standard becomes a process of ratifying—with some modifications—what that organization already built. The operational complexity of running a global anycast network gets plenty of attention. The operational complexity of managing a rural ISP with a pile of legacy CPE? Not so much.

Who Pays for the Defaults?

Protocol defaults aren’t just technical knobs; they’re economic levers. Consider the evolution of DNS. The original design assumed a hierarchical, fairly static namespace managed by a small set of trusted operators. As DNS became a vector for censorship, surveillance, and commercial data collection, new standards popped up: DNS over HTTPS (DoH), DNS over TLS (DoT), DNS over QUIC (DoQ). Each one tackled real privacy problems. But each one also shifted control over DNS resolution toward the application layer and, in practice, toward a handful of resolvers run by Google, Cloudflare, and a few others.

For a network operator running a local resolver to serve a community or enterprise, DoH can be a real pain. It bypasses local policy, makes troubleshooting a nightmare, and centralizes visibility into user behavior. The privacy benefits are genuine, but so is the power shift. The standard was written mostly by people who saw ISPs as adversaries, not as infrastructure partners. The result is a protocol that treats network-level DNS as a problem to route around, not a function to improve.

The Middlebox Conundrum

Middleboxes—firewalls, NATs, load balancers, deep packet inspection devices—often get cast as the villains of internet innovation. The IETF’s historical stance, laid out in RFC 1958, was that “the network is a simple, dumb, minimal packet transport.” Middleboxes spit in the face of that principle. But they exist because network operators have legitimate needs: security, address conservation, traffic management, regulatory compliance. When standards are written by those who control endpoints, middlebox concerns get treated as obstacles to engineer around, not as requirements to meet.

This sets up a vicious cycle. A new protocol ignores middleboxes. Middleboxes break the protocol. The protocol adds workarounds to evade middleboxes. Middlebox vendors adapt. The result is a more complex, more brittle network where only the biggest players can afford to keep up. The standard, by refusing to engage with the operational reality of middleboxes, ends up reinforcing the dominance of those who can deploy end-to-end solutions at scale.

The Governance Gap

Standards bodies have governance structures, but they weren’t designed to balance power. The IETF runs on open participation and rough consensus, which sounds democratic but in practice favors those with the time, expertise, and travel budgets to show up. The W3C has a more formal membership model, with fees ranging from $2,250 to $77,000 a year depending on organization size and location. The 3GPP is a consortium of national standards organizations, where influence is mediated by membership tiers and the ability to contribute to multiple working groups at once.

None of these models is inherently illegitimate. But they all produce standards that embed the priorities of their most active participants. When a standard gets praised for its technical elegance, it’s fair to ask: elegant for whom? A protocol that shaves milliseconds off a streaming video platform might add jitter to a VoIP call. A security mechanism that shields user data from passive surveillance might make it harder for a network operator to spot a DDoS attack. These aren’t bugs; they’re features, chosen by the people who wrote the spec.

The Transparency Problem

One of the stickiest challenges in standards governance is the lack of transparency around participation and influence. Meeting minutes often get published, but they rarely capture the informal conversations, the hallway huddles, or the design decisions made in corporate labs before a draft ever sees the light of day. The IETF’s “Note Well” reminds participants of their responsibilities, but it doesn’t require disclosure of commercial interests. An engineer from a large CDN can push for a protocol change without ever spelling out how it benefits their employer’s market position.

This isn’t a call for conspiracy theories. Most standards participants are acting in good faith, trying to solve real technical problems. But their definition of the problem is shaped by their employer’s architecture, customer base, and business model. When those perspectives dominate a working group, the resulting standard reflects a particular view of the internet—one where the network core is dumb, the edge is smart, and the user is a consumer of services rather than a peer on the network.

What Gets Left Out

When standards are written by a narrow set of participants, certain use cases get systematically short shrift. Community networks, municipal broadband, research and education networks, and operators in the Global South often lack the resources to participate in standards bodies. Their requirements—affordable backhaul, resilience under constrained power, operation by non-specialist staff—rarely show up in protocol design discussions.

The result is a stack of protocols that assumes always-on connectivity, abundant bandwidth, and a clean split between producers and consumers of content. For a community network in rural India that uses Wi-Fi long-range links and solar-powered relays, those assumptions don’t hold. The network is intermittently connected, bandwidth is scarce, and every node is both a producer and a consumer. Standards written for data centers and CDNs don’t serve these networks well, but they become the default because no alternative is standardized.

The Cost of Ossification

Protocol ossification—the tendency of deployed protocols to become resistant to change—often gets blamed on middleboxes. But ossification is also a product of who writes the standards. When a protocol is designed by a small group of large players, it tends to be optimized for their use cases. Once deployed, it becomes difficult to change because the installed base is enormous and the costs of change fall disproportionately on smaller operators. The large players who drove the original design can adapt; everyone else is stuck with the consequences.

This dynamic is visible in the slow adoption of IPv6. The standard was written by a relatively broad community, but the transition mechanisms were shaped by the operational realities of large ISPs and content providers. Smaller operators, who couldn’t afford dual-stack deployments or carrier-grade NAT, were left with few good options. The standard wasn’t malicious, but it was written by people who could afford the transition costs and who assumed others could too.

What Would Better Look Like?

Improving the representativeness of standards processes isn’t straightforward. Simply adding more participants from underrepresented groups doesn’t guarantee better outcomes if the process itself is structured around the needs of incumbents. Some proposals include funding travel and time for participants from smaller organizations, requiring disclosure of commercial interests in draft submissions, and creating formal mechanisms for incorporating operational feedback from diverse network environments.

There are precedents. The Internet Research Task Force (IRTF) has a more exploratory mandate and has produced work on congestion control and routing that considers a wider range of network conditions. The Global Network Initiative has brought together companies, civil society, and academics to address human rights issues in network operations. These models aren’t perfect, but they suggest that broadening participation and making assumptions explicit can lead to more resilient outcomes.

Another approach is to treat standards not as finished products but as hypotheses about how a network should operate, subject to empirical testing in diverse environments. This would require standards bodies to invest in measurement, to collect data on how protocols perform in different network conditions, and to revise standards based on that evidence. It would also require a cultural shift away from celebrating a standard’s adoption as an unqualified success and toward asking who benefited, who was burdened, and what alternatives were foreclosed.

FAQ

Why does it matter who writes internet standards?

Standards define the default behaviors of the internet. They determine how traffic is routed, how congestion is managed, how security is implemented, and how new services can be deployed. When a small set of organizations dominates the standards process, the resulting protocols reflect their operational priorities and economic interests. This can create barriers for smaller network operators, limit user choice, and embed power asymmetries into the infrastructure itself.

Are open standards processes like the IETF’s truly open?

The IETF is open in the sense that anyone can join mailing lists, attend meetings, and submit drafts. But effective participation requires significant time, expertise, and travel funding, which favors employees of large organizations. The IETF’s culture of rough consensus also means that objections can be overridden if a sufficient majority agrees, which can marginalize minority viewpoints. Openness does not guarantee representativeness.

How can network operators influence standards that affect them?

Network operators can participate directly in standards bodies, though this requires resources. They can also contribute to operator-focused groups like NANOG, RIPE, or the IETF’s own Operations and Management Area, which provide feedback on protocol deployability. Engaging early in the standards process, before implementations are widely deployed, is critical. Once a protocol is baked into hardware or software, changing it becomes exponentially harder.

What is an example of a standard that failed to account for operational diversity?

The initial deployment of DNS over HTTPS (DoH) is a clear example. It was designed to protect user privacy from on-path observers, but it centralized DNS resolution among a few large providers and broke local network management practices. Subsequent revisions have added mechanisms for discovery and opt-out, but the initial design reflected the priorities of application developers and content platforms, not network operators or enterprise administrators.

Standards are not neutral. They are the residue of power struggles, compromises, and unexamined assumptions. The next time a new protocol is announced with fanfare, the useful question is not just “What does it do?” but “Who wrote it, what did they optimize for, and who pays for the defaults?”

How Encrypted DNS Resolvers Shift Trust Without Eliminating It

Every time you type a domain name into your browser, your device sends a DNS query. By default, that query travels in plaintext—readable by any network hop along the way. Encrypted DNS protocols like DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ) wrap that query in a cryptographic layer. But here’s the catch: the envelope still has a destination address, and the recipient still reads the message. Trust doesn’t vanish. It just packs its bags and moves to a new address.

For the people who design, audit, or govern infrastructure—the core readership of this blog—the interesting question isn’t whether encryption is good. It’s what happens to the trust model when the postcard becomes an envelope. The answer pulls in resolver consolidation, policy enforcement, and the quiet power of default settings.

The Old Postcard Model: Why Unencrypted DNS Became a Liability

Traditional DNS runs over UDP port 53 with zero confidentiality. Every query—whether for a bank, a health portal, or a news site—is visible to the recursive resolver, the authoritative server, and any network operator in between. That visibility propped up a whole ecosystem: ISP content filtering, ad-targeting data collection, government-mandated blocking. It also made DNS a handy vector for surveillance and manipulation.

The IETF responded by standardizing DNS over TLS (DoT) in 2016 and DNS over HTTPS (DoH) in 2018. Both encrypt the query between client and resolver, blocking on-path observers from reading or tampering with the request. DoT uses a dedicated port (853), so it’s easy to spot and block. DoH blends DNS into the HTTPS stream on port 443, making it tough to distinguish from regular web traffic. That distinction matters a lot for network admins who lean on DNS visibility for security or policy enforcement.

Encrypted DNS isn’t a privacy cure-all. The resolver still sees the query and the client IP address. The authoritative server still sees the resolver’s query. Encryption protects the path, not the endpoints. The trust that was once scattered across multiple intermediaries now lands squarely on the resolver operator.

Resolver Concentration: The New Gatekeepers

When DNS was unencrypted, your ISP usually picked the resolver. With encrypted DNS, users can choose any resolver that supports the protocol. In practice, a handful of public resolvers dominate: Google Public DNS, Cloudflare’s 1.1.1.1, Quad9, and OpenDNS. Each operates under a different privacy policy, logging practice, and threat intelligence model.

This concentration raises fresh governance questions. A user who ditches an ISP resolver for a public encrypted one might escape one kind of surveillance and walk straight into another. The ISP can’t see the queries anymore, but the public resolver can. The difference lies in the resolver’s stated policies, its jurisdiction, and its business model. Google’s resolver, for instance, logs temporary data for debugging and security but claims not to correlate it with user accounts. Cloudflare commits to not writing query IP addresses to disk and hires external auditors to verify. Quad9 blocks known malicious domains by default, making a security decision on the user’s behalf. Each choice is a governance decision, not just a technical one.

This shift also hits enterprise and institutional networks. Many organizations rely on DNS filtering to enforce acceptable-use policies, block malware, or comply with regulations. When a device uses an encrypted resolver outside the organization’s control, that visibility evaporates. The trust once placed in internal DNS infrastructure now shifts to an external provider—or to the device manufacturer that pre-configures the resolver.

Protocol Politics: DoH, DoT, and the Browser Battles

The choice of protocol is itself a governance decision. DoH embeds DNS queries in HTTPS, making them indistinguishable from web traffic. That design was intentional: it prevents network operators from blocking or redirecting DNS queries. But it also bypasses existing DNS-based security controls. A network that uses DNS sinkholing to block malware domains can’t see DoH queries unless it performs TLS inspection—a practice that brings its own privacy and performance headaches.

DoT, by contrast, uses a dedicated port. Network admins can choose to allow or block it. That makes DoT more compatible with enterprise policy enforcement but also more susceptible to censorship. The choice between DoH and DoT isn’t just a technical toggle; it’s a statement about who should control DNS resolution on a network.

Browser vendors have become central actors in this shift. Mozilla and Google both enable encrypted DNS by default in certain configurations. Mozilla’s approach uses a curated list of resolvers that meet specific privacy requirements. Google’s Chrome automatically upgrades to DoH if the user’s configured resolver supports it. These defaults shift trust from the operating system and the local network to the browser vendor and its chosen resolver partners. For users, this happens largely invisibly.

The IETF’s work on Discovery of Designated Resolvers (DDR) and Discovery of Network-designated Resolvers (DNR) tries to give network operators a way to signal their preferred encrypted resolvers. But adoption is slow, and the power of defaults remains strong. The entity that controls the application—the browser—often has the final say.

Policy Enforcement and the Erosion of Local Control

In many organizations, DNS is a policy enforcement point. Schools use DNS filtering to block adult content. Enterprises use it to prevent access to known phishing domains. Governments mandate DNS-based blocking of copyright-infringing or politically sensitive sites. Encrypted DNS complicates all of these practices.

When a device uses an external encrypted resolver, local DNS policies become invisible to it. The device simply bypasses the local resolver and its associated policies. This can be a feature for users seeking to avoid censorship, but a bug for network administrators responsible for security or compliance. The tension isn’t new—VPNs and proxy servers have long offered similar bypasses—but encrypted DNS makes it a default behavior for millions of users who never consciously opted in.

Some resolver operators have responded by building policy into their services. Quad9 blocks known malicious domains. Cloudflare offers malware blocking and family-friendly filtering as configurable options. These features shift policy enforcement from the local network to the resolver. The trust decision moves from “my network administrator sets the rules” to “my resolver operator sets the rules.” For some users, this is an improvement. For others, it’s a loss of local autonomy.

Jurisdiction and the Geography of Trust

When a user in Germany sends a DNS query to a resolver operated by a US-based company, which country’s laws apply to that data? The answer isn’t straightforward. The resolver may be subject to US law, the law of the country where its servers sit, and international agreements. The user may be protected by GDPR in Europe, but those protections depend on the resolver’s compliance and the enforceability of cross-border data protection.

This jurisdictional ambiguity isn’t unique to DNS. It mirrors broader debates about cloud services, data localization, and the reach of national surveillance laws. But DNS is particularly sensitive because it reveals the full pattern of a user’s internet activity. A resolver that logs queries—even temporarily—holds a detailed map of a user’s online life. The trust placed in that resolver isn’t just about technical competence; it’s about legal and political accountability.

Some resolver operators have responded by incorporating in privacy-friendly jurisdictions. Quad9, for example, is based in Switzerland and subject to Swiss data protection law. Others, like Cloudflare, publish transparency reports and submit to external audits. These are meaningful steps, but they don’t eliminate the trust requirement. They shift it from a technical guarantee to an institutional one.

What Encrypted DNS Does Not Solve

Encrypted DNS protects the confidentiality and integrity of queries between the client and the resolver. It does not protect against the resolver itself. It does not hide the client’s IP address from the authoritative name server. It does not prevent traffic analysis—an observer can still see which IP addresses the client connects to after the DNS lookup. And it does not encrypt the subsequent communication between the client and the destination server. That remains the job of TLS, VPNs, or other transport-layer protections.

This limited scope is important. Encrypted DNS is often marketed as a privacy tool, but it’s more accurately a confidentiality tool for one specific leg of the journey. It prevents the local coffee shop Wi-Fi operator from seeing your DNS queries, but it does not prevent the coffee shop from seeing which IP addresses you visit. It prevents your ISP from modifying DNS responses, but it does not prevent the ISP from throttling or blocking traffic to those IP addresses. The trust that encrypted DNS removes from the local network is partially replaced by trust in the resolver, and partially left unaddressed.

Practical Implications for Infrastructure Governance

For those responsible for network policy, encrypted DNS presents a series of practical questions. Should the network allow DoH, DoT, or both? Should it provide its own encrypted resolver? Should it block known public resolvers? Should it rely on application-level controls instead of DNS-based ones? The answers depend on the network’s threat model, its regulatory environment, and its relationship with users.

In a corporate network, the default answer is often to block external encrypted DNS and provide an internal resolver that supports encryption. This preserves visibility and policy control while still protecting queries on the local network. In a public Wi-Fi setting, the calculus is different. Users may reasonably distrust the network operator and prefer to use their own resolver. In a home network, the choice is often left to the device manufacturer or the ISP, with little transparency for the end user.

These scenarios highlight a recurring theme in protocol politics: the same technology that protects one party can disempower another. Encrypted DNS protects the user from the network operator, but it also protects the user from the network operator’s security policies. The trust that is shifted is not neutral. It has winners and losers.

Frequently Asked Questions

Does encrypted DNS make me anonymous online?

No. Encrypted DNS hides your queries from on-path observers, but the resolver still sees them. Your ISP can still see which IP addresses you connect to after the DNS lookup. Anonymity requires additional tools, such as VPNs or Tor, and even those have limitations.

Which encrypted DNS protocol is better: DoH or DoT?

Neither is universally better. DoH blends into HTTPS traffic, making it harder to block or identify, which can be good for privacy but bad for network management. DoT uses a dedicated port, making it easier to monitor and control. The right choice depends on your threat model and who you trust to manage the network.

Can my ISP still see my browsing if I use encrypted DNS?

Your ISP cannot see the DNS queries themselves if they are encrypted, but they can still see the IP addresses you connect to afterward. They can also infer which sites you visit based on traffic patterns, a technique called traffic analysis. Encrypted DNS improves confidentiality but does not provide complete privacy.

Who decides which encrypted DNS resolver my device uses?

It depends on the device and browser. Some browsers, like Firefox, can be configured to use a specific DoH resolver. Chrome can automatically upgrade to DoH if the system resolver supports it. Operating systems like iOS and Android also have settings for encrypted DNS. In many cases, the default is set by the browser or OS vendor, not the user or the network administrator.

Where the Trust Lands

Encrypted DNS is a genuine improvement over the plaintext status quo. It closes a long-standing vulnerability and raises the cost of mass surveillance. But it does not eliminate the need for trust. It moves that trust from the local network and the ISP to the resolver operator, the browser vendor, and the device manufacturer. Each of these actors has its own incentives, its own jurisdiction, and its own accountability mechanisms.

For the protocol politics community, this is a case study in how technical design choices distribute power. The decision to use DoH over DoT, the choice of default resolver, the handling of logs—these are not just engineering details. They are governance decisions made by protocol designers, implementers, and deployers. Understanding them requires looking past the encryption and asking: who holds the keys, and under what rules?

This article is part of a series on DNS governance. A future piece will examine the role of browser vendors as de facto policy enforcers in the encrypted DNS ecosystem.

The web didn’t start with a blank canvas. Every time you crack open a code editor, you’re stacking your work on top of choices made by people who, in many cases, are long dead. Those choices weren’t neutral. They baked in assumptions about who holds power, who gets access, and who controls the pipes. If you don’t know what those assumptions are, you’ll end up repeating them. Worse, you’ll think you came up with them yourself.

I get tired of seeing designers and developers act like the web began with React. It didn’t. The web has a history, and that history is political. The way data moves, who can publish, what a browser does with markup—these aren’t just engineering puzzles. They’re questions about who gets a voice and who gets silenced.

The Web Was Born from a Document Culture, Not an App Store

Tim Berners-Lee wasn’t dreaming of SaaS subscriptions. He wanted to link research papers. The first browser was also an editor. The web was read-write from the start. That’s not trivia. It means the whole architecture—HTTP, HTML, URLs—was built to share and connect documents, not to run remote code.

When you treat a web page as an app shell that pulls JSON and renders on the client, you’re working against that architecture. You break deep links. You hide content from search crawlers unless you bolt on server-side rendering. You force users to download and execute JavaScript just to read a paragraph. That’s not innovation. That’s a misunderstanding of the medium.

The early web was also simple on purpose. HTML was small enough to learn in a few hours. That wasn’t a limitation. It was an invitation. Anyone with a text editor and a modem could publish. Now, the barrier is a towering stack of build tools, frameworks, and dependencies. We’ve turned web development into a profession that locks out amateurs. That’s a political outcome, not a technical one.

The Browser Wars Were About Control, Not Features

In the 1990s, Netscape and Microsoft fought for dominance. The weapons weren’t better user experiences. They were proprietary HTML tags. <blink>. <marquee>. ActiveX. Each company wanted to make sites that only worked in their browser. The goal wasn’t a better web. It was a captive audience.

We see the same playbook today. Google’s Chrome dominates. They push features that feed their advertising machine. AMP was a perfect example—a format that looked like the web but lived on Google’s servers, giving them even more control over traffic and monetization. Developers adopted it because it was fast and boosted visibility. The trade-off was handing over more of the web’s infrastructure to a single corporation.

Knowing this history makes you skeptical. When a browser vendor proposes a new API, you ask: who benefits? Does this spread power or concentrate it? The web was meant to be decentralized. Every layer of complexity and centralization we add is a step away from that original promise.

The Web Is a Socially Constructed Technology

Technologies don’t evolve in a vacuum. They’re shaped by the people who build them and the economic systems they live in. The web’s shift from documents to apps wasn’t some natural progression. It was driven by venture capital, by the hunger to monetize attention, by the push to turn a public library into a shopping mall.

Take the hyperlink. It’s the web’s basic building block. It’s also a gesture of trust. When you link to something, you’re saying: this is worth your time. Google’s PageRank turned links into currency. That made the web more navigable, sure. But it also spawned an industry of link farming, SEO manipulation, and content mills. The link stopped being a social gesture and became a financial instrument.

Now think about what we’re building today. Web3. The fediverse. New protocols. Are we designing for community or for extraction? Are we building tools for people or platforms for rent-seeking? The web’s history shows these questions are never just technical. They’re always about power.

Accessibility Is a Legacy of the Web’s Early Choices

HTML was designed to work on any device. A heading is a heading whether you see it on a screen, read it on a text terminal, or hear it through a screen reader. That was intentional. It meant the web could serve blind users, people on slow modems, anyone with a device that could parse text.

Modern web development often trashes this. We build <div> soups with no semantic structure. We make basic navigation depend on JavaScript. We craft experiences that look gorgeous on a MacBook Pro and fall apart everywhere else. This isn’t just sloppy work. It’s exclusion. It says: this web isn’t for you if you can’t afford the latest hardware, if you have a disability, if your internet is slow.

The early web was inclusive by default. You had to go out of your way to make it exclusive. Now, inclusion takes extra effort. That’s a design failure, and it comes from not knowing where the web started.

Infrastructure Encodes Values

The web’s infrastructure—DNS, ISPs, hosting providers—isn’t neutral. It’s a stack of power relationships. Who controls the domain name system? Who can cut off your access? Who logs your traffic? These are political questions dressed up as technical ones.

When you design a web application, you make infrastructure choices. Do you host on AWS, feeding a single corporation’s monopoly? Do you use a CDN that logs every user request? Do you embed third-party scripts that track your visitors without their knowledge? These aren’t just performance or convenience decisions. They’re decisions about who holds power over your users’ data.

The early web ran on open protocols—TCP/IP, HTTP, SMTP. Anyone could implement them. No permission needed. That openness is what let the web explode. Today, we’re layering proprietary platforms on top of those open protocols. We’re building walled gardens on public land. The history of the web reminds us that this is a choice, not a force of nature.

What We Lost When We Got “Rich Experiences”

The web used to be a place where you could View Source and learn how something was built. It was a giant, distributed classroom. You could see the HTML, the CSS, the JavaScript. You could copy, tweak, and play. That’s how a generation of developers taught themselves.

Today, View Source is a joke. The markup is generated by frameworks. The CSS is minified and hashed. The JavaScript is a webpack blob. The web is no longer legible. We traded learnability for performance, and we never asked if the trade was worth it.

This has consequences. It raises the barrier for new developers. It concentrates knowledge in the hands of people who can afford bootcamps or CS degrees. It turns the web into a consumer product instead of a creative medium. The web was supposed to be a place where anyone could write, not just read. We’re losing that.

Designing for the Future Requires Historical Consciousness

If you don’t know where the web came from, you can’t know where it should go. You’ll mistake temporary trends for permanent truths. You’ll optimize for the wrong things. You’ll build fragile systems that break when the next framework arrives.

Historical consciousness means understanding that every technical decision is a trade-off. It means asking: what are we gaining, and what are we losing? It means resisting the hype cycle. It means valuing longevity over novelty. It means building for humans, not for algorithms.

The web is not a product. It’s a commons. It belongs to all of us. But it will only stay a commons if we understand its history and fight to protect its principles. Those principles are openness, accessibility, decentralization, and simplicity. They’re not outdated. They’re the foundation. Build on them, or watch what you build crumble.

Frequently Asked Questions

Why does the history of the web matter for modern developers?

Because the web’s architecture was shaped by specific decisions about openness, accessibility, and decentralization. Ignoring those decisions leads to building systems that break fundamental web functionality—like linking, bookmarking, and working across devices. Understanding the history helps you make informed trade-offs rather than blindly following trends.

How did the web go from documents to applications?

The shift was gradual and driven by economic incentives. Early web pages were static documents. JavaScript added interactivity. AJAX allowed asynchronous data loading. Then frameworks like Angular and React abstracted the page into a client-side application. Each step was sold as progress, but it also increased complexity and centralized control in the hands of a few large platforms.

What can I do to build a web that respects its origins?

Start with semantic HTML. Ensure your content is accessible without JavaScript. Use progressive enhancement. Choose open protocols and formats. Host on infrastructure that respects user privacy. Question whether every new framework or API actually serves your users or just adds complexity. Small, deliberate choices add up.

People toss around the words platform and protocol like they mean the same thing. They don’t. And the mix-up isn’t just a vocabulary fail. It’s a political blind spot. If you can’t tell a platform from a protocol, you can’t see who’s holding the reins, how they use that grip, or what happens when the rules shift under your feet without so much as a nod in your direction.

I’m Maren Solberg. I write about infrastructure because infrastructure has never been neutral—not once. The shape of a network decides who gets heard, who can trade, and who can be quietly erased. This piece is about two radically different ways of organizing digital life. One’s a platform. The other’s a protocol. Getting the distinction straight isn’t academic. It’s the bare minimum for any real talk about tech and society.

What a Protocol Actually Is

A protocol is a rulebook for how machines talk to each other. Not a product. Not a company. It’s a specification, usually published as a public document, that anyone with the chops can implement. The Internet Protocol (IP), the Simple Mail Transfer Protocol (SMTP), the Hypertext Transfer Protocol (HTTP)—these are protocols. They spell out message formats, the sequence of operations, how to handle errors. They don’t say who gets to join or what kind of content is okay.

Protocols get hammered out in standards bodies like the Internet Engineering Task Force (IETF) or the World Wide Web Consortium (W3C). These groups aren’t saints. They have their own politics, their own biases, their own corporate fingerprints. But the core architecture of a protocol is decentralized. Anyone can write software that speaks SMTP. Anyone can spin up a mail server. The protocol doesn’t care about your identity. It cares whether your packets are properly formed.

That’s not a footnote. It’s a constitutional principle. When you build on a protocol, you’re not asking for permission. You’re not bound by a terms of service that can flip overnight. You’re not one policy change away from being booted off because the network owner decided your content was a problem. The protocol is indifferent to your politics, your business model, your passport. That indifference is a kind of freedom.

What a Platform Actually Is

A platform is a privately owned space. It uses protocols under the hood—HTTP, TCP/IP, and the rest—but it layers control on top. Facebook, YouTube, Twitter, TikTok: these are platforms. They’re walled gardens built on open ground.

The thing that defines a platform is intermediation. It wedges itself between you and your audience, between buyer and seller, between writer and reader. The platform decides what surfaces, what gets recommended, what disappears. It enforces a terms of service that’s a legal document, not a technical spec. Break those terms, and you lose access—not just to the platform, but to the people you reached through it.

Platforms aren’t evil by nature. They do useful things. They handle spam, abuse, and illegal content at a scale that open protocols can’t easily match. But they also hoard power. When a platform becomes the main way people communicate, the owner of that platform becomes a de facto speech regulator. That’s not a glitch. It’s the business model.

The Governance Gap

Protocols are governed by standards. Platforms are governed by executives. The difference bites. Disagree with a protocol decision? You can fork the standard, write your own implementation, or join a competing standards body. The barriers are technical and social, but they’re not legal. Disagree with a platform decision? You’ve got nothing. You can’t fork Facebook. You can’t run your own YouTube instance that talks to the main network. The platform is a monolith.

This governance gap is getting wider. In the early internet days, most communication ran over open protocols: email, Usenet, IRC. Today, most communication runs on platforms. The shift wasn’t fate. It was driven by convenience, network effects, and a deliberate strategy by venture-funded companies to capture value that protocols left lying around.

Protocols don’t have a business model. They’re public goods, kept alive by volunteers or underfunded nonprofits. Platforms have a very clear business model: hoard attention, sell ads, extract data. The asymmetry is baked in. Platforms can pour billions into user experience, moderation, and growth. Protocols depend on the goodwill of engineers who are often working for free.

The Email Example

Email is the cleanest illustration of the split. SMTP is a protocol. Anyone can run an email server. Gmail is a platform. Most people use Gmail. Google didn’t invent email. They built a slicker client and a better spam filter, and they gave it away. Over time, Gmail became so dominant that running your own email server turned impractical. Deliverability now hinges on reputation systems controlled by a handful of big providers. The protocol is still open, but the ecosystem isn’t.

That’s the platform playbook. Build on an open protocol. Add proprietary features. Hit scale. Use that scale to make the open ecosystem unlivable for anyone else. Then tighten the screws. Tweak the algorithm. Raise prices. Hoover up more data. The protocol remains as a fig leaf, but the real power has moved elsewhere.

Why This Is a Political Problem

Infrastructure is political because it shapes who gets what power. A world of protocols is a world where power is scattered among implementers, users, and standards bodies. A world of platforms is a world where power pools in a few corporate headquarters. The choice isn’t between efficiency and chaos. It’s between different forms of governance.

When a government wants to muzzle speech, it can lean on platforms far more easily than it can lean on protocols. A platform is a single point of failure. A protocol is a hydra. Cut off one implementation, and others keep going. That’s why authoritarian regimes love platforms. They offer a handy choke point. The Chinese government doesn’t need to block every website. It just needs to control WeChat.

But the political problem isn’t just about authoritarianism. In democratic societies, platforms exercise a kind of private governance that’s largely unaccountable. Content moderation decisions shape public discourse, but they’re made behind closed doors. Appeals processes are murky. The rules change without warning. That’s not how public infrastructure should work.

The Interoperability Question

One way to bridge the gap between platforms and protocols is to mandate interoperability. If a platform gets big enough, it should be required to expose APIs that let competing services interact with it on equal footing. That’s the idea behind data portability and the right to exit. If you can leave Facebook and still message your friends, Facebook stops being a prison.

Interoperability isn’t a magic fix. It brings security risks, privacy headaches, and coordination snags. But it’s a structural remedy for a structural problem. The goal isn’t to smash platforms. The goal is to stop them from becoming permanent fixtures of the digital landscape. A platform should be a service you pick, not a territory you’re born into.

The European Union’s Digital Markets Act is an attempt to write this principle into law. It requires large platforms to offer interoperability for messaging services and to allow third-party app stores. The details are messy, and the implementation will be fought tooth and nail. But the direction is right. Lawmakers are starting to grasp that digital infrastructure is infrastructure, and infrastructure needs regulation.

The Historical Pattern

This isn’t the first time society has faced a choice between open and closed infrastructure. The 19th-century railroad barons built proprietary rail networks with incompatible gauges. The Bell System controlled telephone infrastructure for decades, blocking third-party devices from connecting. In each case, the early phase of proprietary control gave way to regulation, standardization, and eventually common carriage.

The internet repeated this pattern in fast-forward. The early internet was a network of protocols. The Web 2.0 era was a land grab by platforms. We’re now in a third phase, where the political fallout of platform dominance is getting too loud to ignore. The question is whether we’ll respond with the same tools our predecessors used: antitrust enforcement, interoperability mandates, and public investment in open alternatives.

History hints that platforms don’t last forever. They’re vulnerable to technological shifts, regulatory pressure, and user revolt. But the shift from platform to protocol isn’t automatic. It takes deliberate political action. It takes people who understand that the architecture of a network is a form of law.

What You Can Do

Grasping the difference between a platform and a protocol is step one. Step two is acting on that understanding. Use services built on protocols when you can. Support organizations that maintain open standards. Push for interoperability mandates. Run your own server if you’ve got the skills. If you don’t, pay someone who does.

This isn’t a call for digital puritanism. You don’t need to delete all your platform accounts and retreat to a cabin with a self-hosted email server. But you should be clear-eyed about the tradeoffs you’re making. Every time you post on a platform, you’re building value on land you don’t own. Every time you use a protocol, you’re investing in infrastructure that no single entity controls.

The difference between a platform and a protocol is the difference between a shopping mall and a public road. The mall is private property. The owner sets the rules. The road is a commons. Anyone can use it, and no one can be excluded without due process. We need both. But we should be honest about which is which, and we shouldn’t let the mall owners convince us that their private rules carry the weight of public law.

FAQ

What is the main difference between a platform and a protocol?

A protocol is an open set of rules for communication that anyone can implement without permission. A platform is a privately owned service that uses protocols but adds a layer of control, sitting between users and deciding what content or behavior is allowed.

Why do platforms tend to dominate over open protocols?

Platforms can invest heavily in user experience, moderation, and network effects because they have a business model—usually advertising or data monetization. Protocols, as public goods, often lack funding and dedicated teams, making them slower to evolve and harder for average users to adopt.

Can a platform become a protocol?

Not easily. A platform can open its APIs or adopt standards that allow interoperability, but the core control usually stays with the owning company. True protocols are defined by open specifications and decentralized governance, which is fundamentally different from a single company’s product roadmap.

Most people tap and scroll through the internet without a second thought about the scaffolding beneath it. They open an app, fire off a message, and assume the magic just works. But the way that magic is structured—whether it runs on a protocol or a platform—decides who holds power, who can build something new, and who gets locked out when the rules change. Maren Solberg has spent years watching these architectural choices shape societies, and the distinction isn’t just technical. It’s deeply political.

What a Protocol Actually Is

A protocol is a shared language. It’s a set of rules that lets different systems talk to each other without needing to know anything about the other’s internal wiring. Take TCP/IP, the protocol that stitches the internet together. Any device, running any operating system, made by any manufacturer, can send a packet across the network as long as it follows the agreed format. Nobody owns TCP/IP. Nobody can revoke your access to it. The protocol doesn’t care about your identity, your location, or your intentions. It just routes data.

Email works the same way. SMTP handles sending; IMAP and POP3 handle receiving. Because these are protocols, a person on a Gmail account can message someone running a self-hosted server with software from 2003. The protocol is the common ground. It’s a treaty, not a product. When you build on a protocol, you don’t ask for permission. You just speak the language.

What Makes a Platform Different

A platform is a controlled environment. It might use protocols under the hood, but it layers identity, policy, and a business model on top. Facebook is a platform. You can post, comment, and share—but only inside Facebook’s walls. The company decides what content gets promoted, what gets quietly buried, and who can access the API. When you build on a platform, you’re a tenant. The landlord can raise the rent, remodel the building, or evict you entirely.

This isn’t necessarily malicious. Platforms reduce complexity. They handle spam, host your content, and hand you a ready-made audience. But the trade-off is sovereignty. A platform’s terms of service override any technical capability. You might be able to send a message, but the platform decides whether it actually gets delivered.

The Political Layer Beneath the Code

Infrastructure is never neutral. The choice between a protocol and a platform is a choice about governance. Protocols distribute power; platforms hoard it. When email shifted from a messy web of self-hosted SMTP servers to Gmail’s polished interface, convenience won. But so did centralized surveillance. Google now scans your inbox to serve ads and can cut off your account without meaningful recourse. The protocol is still there, humming underneath, but the platform mediates your access to it.

This pattern repeats across the stack. The web was built on HTTP, a protocol. But today, most people experience the web through platform browsers like Chrome, which filters what you see through Google’s Safe Browsing lists. The protocol remains, but the platform decides what’s safe, what’s visible, and what loads quickly. The open road is still there, but most of us drive on private tollways.

Why Protocols Outlast Empires

Protocols are boring. They don’t have splashy launch events or quarterly earnings calls. But that dullness is their superpower. HTTP is over 30 years old. SMTP is over 40. They’ve outlived every platform that tried to swallow them. AOL was a platform. CompuServe was a platform. They’re footnotes now. The open protocols they tried to wall off are still running the world.

The reason is structural. Protocols have no single point of failure. No CEO can be indicted, no server can be seized, no terms of service can be rewritten to kill a competitor. Governance is distributed among the people who implement the standard, and if a faction goes rogue, the rest can fork the spec and carry on. Platforms, with their legal departments and quarterly pressures, can’t match that resilience.

The Cost of Convenience

When a society shifts its communication from protocols to platforms, it loses more than technical diversity. It loses the ability to route around censorship. During the Arab Spring, activists used Twitter—a platform—to organize. But Twitter could be pressured by governments, and it was. Meanwhile, the internet’s underlying protocols allowed the creation of mesh networks and alternative channels that no single entity could shut down. The platform was convenient. The protocol was freedom.

This isn’t a thought experiment. In 2021, Nigeria banned Twitter. The platform complied by restricting access. But the internet protocols underneath didn’t care about the ban. Nigerians who understood the difference used VPNs—tools built on open protocols—to bypass the restriction. The platform obeyed the state. The protocol ignored it.

How to Tell the Difference in Practice

You can spot whether you’re dealing with a platform or a protocol by asking three questions:

• Who can implement it? If anyone can write software that speaks the language without asking permission, it’s a protocol. If you need an API key, a partnership agreement, or a terms-of-service checkbox, it’s a platform.
• Who controls the data? If your data is portable and you can move it to another provider without losing functionality, you’re likely on a protocol. If your data is locked in and your social graph belongs to the company, you’re on a platform.
• Who sets the rules? If the rules are defined by a public specification and enforced by the community, it’s a protocol. If the rules are set by a legal team and enforced by content moderators, it’s a platform.

These questions cut through the marketing fluff. A company might call its API a “protocol,” but if it requires a key and can be revoked at any time, it’s a platform feature wearing a protocol costume.

The Hidden Tax of Platform Dependence

Platforms aren’t just technical choices; they’re economic choke points. When a platform controls the interface between creators and audiences, it extracts rent. YouTube takes 45% of ad revenue. Apple’s App Store takes 30% of transactions. These aren’t fees for hosting or bandwidth—those costs are marginal. They’re taxes on access to the platform’s user base.

Protocols don’t extract rent. Nobody owns SMTP, so nobody can charge you for the act of sending email. You pay for your own server or a provider, but the protocol itself is free. This is why platforms often start on open protocols and then wall them off. Facebook began as a website anyone could visit. Then it built an app. Then it acquired Instagram and WhatsApp. Now it controls the feeds, the algorithms, and the ad revenue. The protocol—HTTP—is still there, but it’s buried under layers of platform control.

The Illusion of Openness

Platforms love to market themselves as open. They offer APIs, developer tools, and “ecosystems.” But these are walled gardens with gates, and the platform holds the keys. When Twitter cut off third-party clients in 2023, developers who had built businesses on the Twitter API were left with nothing. They had mistaken a platform’s temporary generosity for a protocol’s permanent neutrality.

This isn’t a bug; it’s the business model. Platforms must grow and monetize. Protocols simply exist. The moment a platform needs to boost shareholder value, it will tighten the screws on the people who depend on it. That’s not a conspiracy theory; it’s fiduciary duty.

Building on Protocols Is a Political Act

Choosing to build on a protocol rather than a platform is a political act. It’s a declaration that you value long-term resilience over short-term convenience. It’s a bet that open systems will outlast closed ones, as they always have. When you host your own email server, run your own website, or contribute to an open-source project, you’re not just using technology. You’re participating in a governance model that distributes power rather than concentrating it.

This doesn’t mean platforms are evil. They’re useful for specific tasks. But they should be treated as what they are: rented space. Don’t build your home on rented land. Use platforms for distribution, but keep your core infrastructure on protocols you control. Own your domain. Run your own mail server if you can. Use open standards for your data. When the platform pivots or dies, you’ll still be standing.

FAQ

Is HTTP a platform or a protocol?

HTTP is a protocol. It defines how clients and servers exchange hypertext documents. Anyone can implement an HTTP server or client without asking permission. The web itself is not a platform, though many platforms are built on top of it.

Can a platform become a protocol?

Rarely. A platform can open-source its code or publish its API specification, but the power dynamics usually remain. True protocols are governed by neutral standards bodies or community consensus, not by a single company’s interests. ActivityPub is an example of a protocol that emerged to decentralize social networking, but it competes against platforms that have no incentive to interoperate.

Why do protocols feel harder to use?

Protocols prioritize interoperability over user experience. They don’t have a single design team smoothing out rough edges. Platforms invest heavily in UX because they need to retain users and sell ads. The friction of protocols is the price of freedom. Tools like RSS readers and Mastodon clients are improving, but they’ll never be as slick as a billion-dollar platform. The question is whether you value control over convenience.

Are blockchains protocols or platforms?

Blockchains are protocols at the base layer—Bitcoin and Ethereum define rules for consensus and transaction validation that anyone can implement. But many applications built on top of them function as platforms, with centralized interfaces and governance. The distinction depends on where the control lies. A smart contract on Ethereum is a protocol; a custodial wallet is a platform.