Refusing a Censored Internet: The Open Web's Call at FOSDEM 27

An article titled "I Refuse to Accept a Censored Internet — Come Find Me at FOSDEM 27" has gained 230 points and 106 comments on Hacker News. The core of the discussion is not any specific technical vulnerability, but an increasingly urgent question: who is redrawing the boundaries of the open internet, and how?

When "Censorship" Is No Longer an Abstract Word

The author writes in the first person to express a stance of refusal, and this wording itself is worth noting. In technical communities, "censorship" used to be treated as rhetoric in policy debates; today it increasingly maps to tangible everyday experiences: certain domains fail to resolve on specific networks, certain protocols are identified and rate-limited by middleboxes, certain content is silently demoted at the platform level. The author does not elaborate on specific cases in the abstract, but brings the issue to a public technical conference — FOSDEM — which is itself a signal.

FOSDEM is Europe's largest gathering of free and open source software developers, held annually in Brussels, with tracks covering kernels, network protocols, decentralized identity, privacy tools, and more. Putting "anti-censorship" in such a setting means the audience is not just policymakers but also the people writing code: protocol design, default configurations, and how infrastructure is deployed all materially affect how easily a network can be interfered with.

The "certain domains fail to resolve on specific networks" mentioned in the text typically involves DNS poisoning and DNS hijacking. DNS translates domain names into IP addresses, and this query process is by traditional design plaintext and unauthenticated. Middleboxes can race ahead of the real response and return a forged address before it reaches the user, causing the domain to "fail to resolve" or point to the wrong location; they can also filter at the recursive resolver level. Such interference is nearly invisible to end users, manifesting as "this website won't open." Countermeasures include DNS over HTTPS (DoH), DNS over TLS (DoT), and DNSSEC, which provide transport encryption and origin authentication respectively — but they have also sparked new controversy: encrypted DNS concentrates queries among a few large resolver providers, thereby reinforcing centralization.

"Certain protocols are identified and rate-limited by middleboxes" points to deep packet inspection (DPI) and traffic classification. Traditional firewalls look only at IP and port, whereas DPI inspects packet payload signatures, handshake patterns, and even timing characteristics to identify specific protocols — even when they run on non-standard ports. This defeats port-based evasion and has spawned an entire class of anti-censorship transport technologies, such as obfuscation protocols that disguise traffic as ordinary HTTPS, domain fronting, and various pluggable transports. The common idea behind these technologies is to make it hard for censors to distinguish "forbidden traffic" from "normal traffic," at the cost of performance overhead and deployment complexity.

The Real Disagreements in 106 Comments

The Hacker News comment section is often the most valuable part of such discussions. The ratio of 230 points to 106 comments indicates a dense discussion — readers are not just upvoting and leaving, they are arguing. Based on the common trajectory of such discussions, disagreements usually cluster around a few directions.

Some argue that the root of censorship lies in centralized architecture: when traffic must pass through a few entry points, domains must be answered by a few resolvers, and content must be hosted on a few platforms, the cost of interference is extremely low. The corresponding solution is to disperse power — self-hosting, federated protocols, end-to-end encryption, verifiable builds and distribution. Others caution that technical solutions cannot automatically solve governance problems: decentralized systems will also produce new gatekeepers, just a different set of people; encryption tools, while offering protection, can also be used to evade legitimate regulation.

These two positions are not mutually exclusive, but they determine the direction of the discussion: whether the problem is viewed as an engineering problem or an institutional one. The original article's choice to speak at FOSDEM clearly leans toward the former — first making the people who build infrastructure aware of how much their choices matter.

The "federated protocols" repeatedly mentioned in the text deserve elaboration. Federation refers to a group of independently operated servers communicating with each other under a common protocol, where users can register on any instance and interact with users on other instances without everyone crowding onto the same platform. Email and ActivityPub (used by Mastodon and others) are typical examples. The value of federation is that there is no single entry point that can be blocked or demoted wholesale, but it is not without gatekeepers: instance administrators have the power to ban users and cut off interconnection with other instances, and large instances can still form de facto hubs. This precisely confirms the text's reminder that "decentralized systems will also produce new gatekeepers" — power is dispersed but does not disappear; it merely shifts to operators.

Why a Developer Conference, Not a Policy Forum

One detail worth noting is that the article's title uses "Join Me at FOSDEM" rather than "Please Sign This Petition." This call to action sets the barrier to entry within the technical community.

What makes the open source community unique is that its output is executable: an encryption option enabled by default, a certificate scheme that doesn't depend on a single CA, a transport protocol that works on restricted networks — all of these materially change the difficulty of censorship. Such work rarely generates headlines, but years later it determines what kind of network ordinary users face. FOSDEM's agenda structure is well suited to accommodate these "unsexy but critical" topics, which is why it has long attracted developers working on privacy and internet freedom in Europe.

Conversely, conference talks alone cannot stop any specific blockade. Their value lies in bringing dispersed practitioners together, so that what each is doing can be seen, reused, and criticized. For a shrinking open internet, this connection is itself a form of resistance.

What It Means for Ordinary Readers

Such discussions are easily dismissed as "internal technical community affairs," but they actually affect everyone who goes online. Browser default behavior, how operating systems handle certificates, and carriers' ability to identify protocols ultimately manifest in the most basic form: "can I open this page or not."

The original article does not offer a list of solutions, nor does it claim any particular path is necessarily correct. It does something more fundamental: it re-labels a trend that is being normalized as unacceptable. The 230 points and 106 comments show that, at least in this community, this label resonated. Whether that resonance translates into code and deployment will be answered by the FOSDEM 27 agenda and the actual actions that follow.