“Suggesting that technical standards are political is a good way to make a certain kind of standards person visibly uncomfortable.”

Not (always) angry, exactly. More like disappointed. As if someone has tracked mud across the data center’s floor.

The objection usually goes something like this: Standards are technical work. They define formats, protocols, interfaces, flows, and operational expectations. They are not legislation. They are not party platforms. They are not manifestos. The work is neutral because it is technology.

I understand the instinct. I share part of it. Standards development organizations should not become proxy legislatures. They are bad at that, and the world already has legislatures, many of which are also bad at it but at least have the decency to be designed for the purpose.

But “not partisan” is not the same as “not political.”

Technical standards have never been outside politics in the broader sense of the word. They shape who can communicate, who can interoperate, who can be observed, who can be excluded, who can assert authority, who has to trust whom, and who gets to decide when something has gone wrong.

That is not party politics nor is it campaign politics. It is politics in the older and more ordinary sense: the ordering of relationships among people, institutions, and power. Standards do that all the time.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

“Open and Neutral” Was Never Value-Free

The Internet’s self-image is built around openness, interoperability, and a certain kind of neutrality. Those are real technical principles. They are also value choices.

A network that allows many kinds of endpoints, applications, operators, and communities to connect without prior permission is not a value-free invention. It embodies a theory of coordination. It says that the network should make broad connection possible, even when the parties at the edge are different, inconvenient, commercially threatening, or politically irritating.

That is an architectural goal. It is also a political statement.

The same is true when a standards community says that the Internet is for end users. That sounds obvious until the interests of end users conflict with the interests of network operators, governments, platforms, vendors, publishers, or other intermediaries. At that point, “for end users” is no longer a slogan. It becomes a priority rule.

The W3C says this more plainly than many communities do. The Web Platform Design Principles start with “Put user needs first,” and the Priority of Constituencies explicitly ranks user needs above the needs of web page authors, user agent implementers, specification writers, and theoretical purity. That is not a minor process preference. It is a governance claim embedded in technical design guidance. When there is a tradeoff, the answer is not supposed to be “whatever is most elegant,” or “whatever is easiest for the largest implementer,” or “whatever keeps the specification shortest.” The stated priority is the user.

That is a value. A good one, in my opinion. But still a value.

We Already Admit This Sometimes

We have been more comfortable admitting the consequences of standards work in some areas than others.

Security Considerations are required because we know a specification can create risk. Privacy Considerations exist because we know protocol design can expose people, correlate them, identify them, or make surveillance easier. “Pervasive monitoring is an attack” is a technical assessment, but no one should pretend it has no relationship to state power, corporate power, or the politics of surveillance.

A decision not to build wiretapping requirements into Internet standards is an engineering boundary. It is also a statement about the kind of forum the IETF is and the kinds of governmental requirements it will not incorporate into its core work.

These are not embarrassing exceptions to the purity of technical standards. They are evidence that technical work has consequences, and mature standards processes eventually find ways to name those consequences.

The problem is that we often reserve that clarity for a small set of familiar categories. Security? Yes, we have a section for that. Privacy? Increasingly, yes. Internationalization? Accessibility? Operational considerations? Sometimes, depending on the community and the document.

But when the question becomes more obviously entangled with law or public policy, everyone gets twitchy.

Encryption, Age Assurance, and Other Impolite Examples

Take end-to-end encryption. Can a government require a technical capability to interrupt, inspect, or bypass it? Some governments will say yes. Many technologists will say no, because a system that allows third-party interruption is not providing the same security property anymore.

That answer is technically grounded. It is also politically meaningful. It prioritizes confidentiality, user security, and resistance to compelled access over certain models of law enforcement access. That does not make the technologist a legislator. It does mean the technical answer has public consequences.

Age assurance is another useful example, precisely because it is such a mess.

Can age be verified under specific circumstances? Yes, depending on what “verified” means, what level of assurance is required, what attribute is disclosed, who performs the check, whether identity is bound to the transaction, whether the relying party learns anything more than it needs, whether the system creates tracking infrastructure, and whether the people affected have realistic alternatives.

There is plenty of technology in that paragraph. There is also nothing politically neutral about it.

A standard can make one implementation easier and another harder. It can make surveillance expensive or cheap. It can require disclosure or enable selective disclosure. It can support anonymity, pseudonymity, verified attributes, organizational authority, delegation, parental approval, platform accountability, or some awkward combination of all of the above. Each of those design choices reflects a view about risk and legitimacy.

The standard may not decide the law. But it can absolutely decide which laws are easy to implement, which are hard to implement, and which are technically incoherent.

The Questions Hiding Inside Architecture

This is where the old comfort blanket of “open and neutral” starts to fray.

• Open to whom?
• Neutral among which parties?
• Neutral about what kinds of harm?
• Neutral between the person being monitored and the institution doing the monitoring?
• Neutral between a child’s access to information and a regulator’s demand for age-gating?
• Neutral between a dissident’s need for anonymity and a government’s desire for traceability?
• Neutral between a small implementer and a platform with enough market power to make its deployment choices feel like standards by other means?

These are not gotcha questions. They are the questions that appear as soon as a technical architecture meets actual society, which is rude of society but hardly new.

The traditional standards move is to say that we build mechanisms, not policy. There is value in that discipline. It keeps technical forums from pretending they can settle every moral and legal dispute. It also keeps specifications from becoming unreadable monuments to every unresolved argument in the room.

But “we build mechanisms, not policy” can become an evasion when the mechanism only works under one policy model.

A protocol that assumes cross-border reachability has something to say about fragmentation, whether or not the authors intended to make a geopolitical point. A credential format that assumes stable authoritative issuers has something to say about institutional trust. A discovery mechanism that assumes public metadata has something to say about privacy and correlation. An age-assurance flow that assumes every user can obtain a government-backed credential has something to say about exclusion. An agent protocol that assumes a human principal can always be identified, reached, and held responsible has something to say about authority and accountability.

The specification does not become non-political just because the political assumptions are implicit.

Implicit Politics Are Still Politics

In fact, implicit politics may be the worst kind for standards work. It allows everyone to claim neutrality while baking in a model of the world that may not survive contact with deployment. Then, when regulators, courts, companies, civil society groups, or governments respond badly, the technical community is shocked to discover that other people noticed the consequences.

This is not a call for every working group meeting to become a seminar in political theory. That would be cruel, and the coffee is not good enough. It is a call for more honesty about the values already present in the work.

When a standards community says that the Internet is for end users, that is a value. When the W3C says user needs should come before authors, implementers, specification writers, and theoretical purity, that is also a value. When a standards body says pervasive monitoring should be mitigated, that is a value. When it refuses to design wiretapping into core protocols, that is a value. When it requires Security Considerations and Privacy Considerations, that is an admission that technical specifications can create conditions for harm.

Good. More of that, please.

The Alternative Is Not Neutrality

The alternative is not neutrality. The alternative is unmanaged politics: politics handled by market dominance, regulatory pressure, regional fragmentation, procurement requirements, private platform rules, and after-the-fact outrage. Those forces will not politely wait outside the standards process because the agenda said “technical discussion.”

They are already in the room. Sometimes they are wearing a government badge. Sometimes they are wearing a corporate badge. Sometimes they are represented by an architectural assumption no one thought to question.

The question is not whether standards bodies should become political. They already are, in the sense that they make decisions that affect the relations between people, institutions, and power. The better question is whether they can remain technically credible while becoming more explicit about those decisions.

I think they can. More than that, I think they have to.

Relevance in a Fragmenting Internet

The Internet is fragmenting under pressure from regulation, national sovereignty claims, platform consolidation, security failures, commercial incentives, and incompatible views of trust and safety. Pretending that open and neutral architecture will naturally prevail because it is technically elegant is not a strategy.

It is nostalgia with a packet header.

At the same time, abandoning openness and neutrality as naive myths would be a mistake. They have never been perfect descriptions of reality, but they remain useful commitments. The work now is not to pretend they are value-free. The work is to say what they require under present conditions.

That may mean being explicit when a design protects end users over intermediaries. It may mean saying when a requirement would create an unacceptable surveillance risk. It may mean documenting when a mechanism supports compliance with some legal regimes and not others. It may mean admitting that a globally interoperable standard cannot satisfy every national policy demand without ceasing to be globally interoperable.

That will make some conversations harder. So be it.

Standards work has always depended on disciplined disagreement. The point is not to remove politics from the room. The point is to prevent unexamined politics from hiding inside architecture until it becomes infrastructure.

Naming the Values Already in the Work

Technical purity is comforting. It is also too small for the world our standards now inhabit.

We do not need standards bodies to become partisan actors. We do need them to stop treating values as contamination. Openness, interoperability, privacy, security, user agency, and resistance to fragmentation are not external to the work. They are part of the work.

And if we cannot say that plainly, someone else will define those values for us, probably in a venue with worse process, less technical competence, and far more confidence.

That would be unfortunate. Also, entirely predictable.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Suggesting that technical standards are political is an excellent way to make many standards professionals uncomfortable.

The response is usually predictable.

Standards, we’re told, are technical.

They define:

• Protocols
• Interfaces
• Formats
• Operational expectations

They are not legislation.

They are not political platforms.

And they certainly are not partisan manifestos.

I understand that instinct.

In fact, I share much of it.

Standards organizations should not become substitute legislatures.

However, there’s an important distinction that’s easy to overlook.

Not partisan is not the same as not political.

And that difference matters.

---

Politics Is Bigger Than Political Parties

When people hear the word politics, they often think about elections, parties, or legislation.

That’s not the meaning I’m talking about.

Politics also describes the relationships between:

• People
• Institutions
• Authority
• Power

Technical standards influence those relationships every day.

They determine:

• Who can interoperate
• Who can communicate
• Who must trust whom
• Who can participate
• Who may be excluded
• How authority is established

Those are political consequences in the broadest sense of the word.

Whether we acknowledge them or not.

---

Openness Is a Value Choice

The Internet often describes itself using words like:

• Open
• Neutral
• Interoperable

These are certainly technical principles.

However, they are also expressions of values.

Designing networks that allow different systems, organizations, and communities to communicate without prior permission isn’t value-free.

It reflects a particular philosophy about coordination.

It prioritizes broad participation even when participants are:

• Commercial competitors
• Political rivals
• Organizational strangers
• Technically inconvenient

That’s more than architecture.

It’s a statement about how the Internet should work.

---

Putting Users First Is Also a Value

The same principle appears throughout standards development.

For example, the W3C’s Web Platform Design Principles begin with a clear priority:

Put user needs first.

That priority explicitly places users ahead of:

• Web page authors
• Browser implementers
• Specification writers
• Theoretical purity

This isn’t simply a process preference.

It’s a governance decision.

When tradeoffs arise, the guidance isn’t:

“Choose the cleanest architecture.”

Or:

“Choose what benefits the largest vendor.”

Instead, the stated priority is the user.

That’s a value.

A good one, in my opinion.

But a value nonetheless.

---

We’ve Already Accepted Some Values

Interestingly, standards communities already acknowledge many value-based consequences.

Consider familiar sections within technical specifications:

• Security considerations
• Privacy considerations
• Accessibility guidance
• Internationalization
• Operational considerations

These sections exist because we recognize that technical design creates real-world consequences.

Protocols can:

• Introduce security risks
• Enable surveillance
• Expose personal information
• Improve accessibility
• Limit interoperability

We’ve become comfortable talking about these impacts.

The discomfort usually begins when the discussion extends into broader public policy.

---

Security Is Never Just Technical

Take pervasive monitoring as an example.

The IETF famously declared:

Pervasive Monitoring Is an Attack.

That’s certainly a technical conclusion.

However, it also reflects broader questions involving:

• Government surveillance
• Corporate surveillance
• User privacy
• Civil liberties

Similarly, declining to build mandatory wiretapping capabilities into Internet standards isn’t simply an engineering decision.

It also establishes an important boundary around what the standards process should and should not absorb into its work.

These aren’t exceptions.

They’re evidence that technical decisions always carry consequences.

---

End To End Encryption Is a Good Example

Debates around end-to-end encryption demonstrate this clearly.

Some governments argue for lawful interception capabilities.

Many technologists argue that introducing those capabilities fundamentally changes the security properties of the system.

The technical reasoning is genuine.

The public consequences are equally genuine.

Prioritizing:

• Confidentiality
• User security
• Resistance to compelled access

is simultaneously:

• A technical position
• A meaningful public policy position

The two cannot be separated entirely.

---

Age Assurance Shows How Complex This Becomes

Age assurance provides another useful example.

The question sounds straightforward.

Can age be verified?

The real answer quickly becomes much more complicated.

It depends on:

• The required level of assurance
• Who performs verification
• Which attributes are disclosed
• Whether identity is revealed
• Whether selective disclosure is possible
• Whether new tracking infrastructure is created

Each design choice affects:

• Privacy
• Surveillance
• User experience
• Regulatory compliance

Technology alone cannot answer these questions.

---

Design Choices Shape Public Outcomes

Standards don’t decide legislation.

However, they do influence which legal and policy choices become easier—or harder—to implement.

Technical designs can:

• Encourage anonymity
• Enable pseudonymity
• Require disclosure
• Support selective disclosure
• Increase accountability
• Expand surveillance

None of these outcomes is neutral.

Every architectural decision embeds assumptions about:

• Risk
• Trust
• Authority
• Legitimacy

Whether those assumptions remain explicit is another matter entirely.

---

Neutrality Can Hide Assumptions

Standards communities often describe themselves as:

• Open
• Neutral

Those ideals remain valuable.

However, they can also obscure important questions.

Neutral toward whom?

Open for whom?

Neutral between:

• Individuals
• Governments
• Platforms
• Regulators
• Service providers

These aren’t rhetorical questions.

They’re the questions that emerge whenever technical architecture meets society.

---

Mechanisms Are Not Independent of Policy

A familiar phrase within standards development is:

We build mechanisms, not policy.

That discipline serves an important purpose.

It prevents technical forums from attempting to solve every legal or ethical debate.

However, the distinction becomes difficult when technical mechanisms only function effectively under particular policy assumptions.

For example:

• Discovery mechanisms assume certain privacy models.
• Credential formats assume particular trust relationships.
• Cross-border protocols assume particular connectivity models.

The mechanisms themselves already contain assumptions.

Ignoring those assumptions doesn’t make them disappear.

---

The Risk of Implicit Politics

Perhaps the greatest risk is pretending those assumptions aren’t there.

Implicit politics often creates greater problems than explicit discussion.

When assumptions remain invisible:

• Regulators notice.
• Courts notice.
• Companies notice.
• Civil society notices.

Standards communities are then surprised when deployment becomes difficult.

Often, the problem wasn’t the technology.

The problem was the unexamined assumptions built into it.

---

Values Already Exist in Standards

This isn’t an argument for turning every working group meeting into a political science seminar.

Nobody wants that.

Especially with conference coffee.

Instead, it’s an argument for greater honesty.

When standards prioritize:

• End users
• Privacy
• Security
• Interoperability
• Openness

those priorities represent values.

Acknowledging them doesn’t weaken technical work.

It strengthens it.

---

Ignoring Politics Doesn’t Remove It

If standards communities avoid discussing values, those conversations don’t disappear.

They simply move elsewhere.

Those decisions become shaped by:

• Governments
• Large technology companies
• Procurement requirements
• Regulatory pressure
• Market dominance
• Regional fragmentation

Those forces won’t politely wait outside the meeting room simply because the agenda says:

“Technical discussion.”

They’re already participating.

Whether we recognize them or not.

---

Technical Credibility Requires Transparency

The question isn’t whether standards organizations should become political.

In many respects, they already are.

The better question is whether they can remain technically rigorous while becoming more transparent about the values informing their work.

I believe they can.

More importantly, I believe they must.

Today’s Internet faces growing pressure from:

• Regulation
• National sovereignty
• Platform consolidation
• Security threats
• Competing trust models

Pretending technical elegance alone will resolve those pressures isn’t a strategy.

It’s nostalgia.

---

Be Explicit About What Matters

Instead of pretending specifications are entirely value-free, standards communities should be more explicit.

For example, specifications should clearly acknowledge when they prioritize:

• End users over intermediaries
• Privacy over surveillance
• Interoperability over fragmentation
• Security over convenience

Not because these choices eliminate disagreement.

But because they make the underlying assumptions visible.

---

Final Thoughts

Technical standards have always balanced engineering discipline with difficult tradeoffs.

Disagreement is inevitable.

The goal isn’t to remove politics from standards work.

The goal is to prevent unexamined political assumptions from quietly becoming permanent technical infrastructure.

That requires openness.

Not only in our protocols.

But also in our conversations.

---

Conclusion

Technical standards were never outside politics.

They have always shaped relationships between people, institutions, trust, and authority.

Recognizing that reality doesn’t make standards bodies partisan.

It makes them honest.

Because if standards communities refuse to articulate the values embedded within their work, someone else eventually will.

And those conversations may take place in venues with far less technical expertise—and far fewer opportunities for thoughtful consensus.

---