Understanding Internet Censorship: How It Works & How Developers Are Pushing Back

JustinF — Tue, 21 Jul 2026 09:19:01 +0000

Internet censorship is not a distant problem that only affects people in faraway countries. It is a growing, technically sophisticated reality that touches developers, engineers, and everyday internet users across the globe. And it is evolving fast.

Whether you are building APIs that need to reach users behind national firewalls, deploying infrastructure in regions with restrictive network policies, or simply curious about how deep packet inspection actually works, understanding the mechanics of censorship is becoming an essential part of a developer toolkit.

Let us break down how internet censorship actually works at a technical level, who it affects, and what tools exist to push back.

How Governments and ISPs Block Content

Internet censorship is not magic. It relies on a handful of well understood network level techniques. Here are the most common ones.

DNS Poisoning and Filtering

When you type a domain name into your browser, a DNS resolver translates it into an IP address. Censors can manipulate DNS responses at the ISP level, returning incorrect IPs or no response at all for domains they want to block. This is one of the simplest and most widely used methods because it requires minimal infrastructure and is hard for end users to detect without technical knowledge.

IP Blocking

A more blunt instrument: the censor simply drops all traffic destined for known IP ranges associated with blocked services. This is easy to implement at the national gateway level but can cause collateral damage when those IPs are shared across many unrelated services (common with cloud providers like AWS and GCP).

Deep Packet Inspection

This is where things get more sophisticated. DPI systems inspect the contents of network packets in real time, looking for patterns that match protocols, domains, or keywords associated with blocked content. DPI can identify VPN traffic, Tor connections, and even specific TLS Server Name Indication fields allowing censors to block individual domains even when the connection itself is encrypted.

DPI is what makes modern censorship so resilient. Simple workarounds like changing DNS servers do not help because the blocking happens at the packet level, after DNS resolution.

SNI Filtering

Even with HTTPS, the TLS handshake includes a plaintext field called the Server Name Indication, which tells the server which certificate to present. Censors can inspect this field and reset the connection if it matches a blocked domain. Techniques like Encrypted Client Hello are being developed to mitigate this, but adoption is still limited.

The Real-World Impact

The scope of internet censorship has expanded dramatically. According to Freedom House, global internet freedom has fallen for 15 consecutive years, with countries including Russia, Iran, China, Egypt, and Myanmar implementing increasingly aggressive blocking regimes. Their annual Freedom on the Net report tracks these trends across dozens of nations with detailed methodology and scores.

The impact extends beyond individual users. Developers cannot pull packages from npm, PyPI, or Docker Hub when registries are blocked. Businesses lose access to collaboration tools like Slack, GitHub, or cloud consoles. Journalists and activists lose secure communication channels at critical moments. Students cannot access online learning platforms or documentation.

For developers specifically, this matters because the tools we take for granted CI/CD pipelines, package managers, API gateways, cloud dashboards can vanish overnight in a censored environment.

How VPNs Bypass Censorship

VPNs work by creating an encrypted tunnel between your device and a server in an uncensored location. All your traffic flows through that tunnel, meaning. Your ISP cannot see the destination (only the VPN server IP). DNS queries are resolved by the VPN server, not the local ISP, bypassing DNS poisoning. DPI sees encrypted traffic, but modern censorship systems can still detect and block standard VPN protocols which is where things get interesting.

The Arms Race: Obfuscation Protocols

To counter DPI based VPN detection, several tools have emerged to disguise VPN traffic as ordinary HTTPS or other innocuous traffic. Proton VPN developed the Stealth protocol, which wraps VPN connections in TLS like traffic that is extremely difficult to distinguish from regular browsing.

But VPNs are not the only option in the circumvention toolbox. The Tor Project maintains Pluggable Transports, a set of open source tools that transform Tor traffic to look like random noise, video calls, or regular HTTPS requests. These include obfs4, Snowflake, and WebTunnel, each with different trade offs for reliability and resistance to active probing.

Other projects like Shadowsocks, V2Ray, and Psiphon take similar approaches with different architectural choices. This is a genuine arms race: censors improve their DPI classifiers, and anti censorship tools evolve to evade them.

For a practical sense of what censorship actually blocks, the Proton VPN Internet Censorship Simulator lets you toggle between censored and uncensored states and see which services become available or disappear across categories like social media, messaging, streaming, gaming, and more. It is a helpful way to move from abstract theory to concrete examples.

Resources for High-Risk Users and Developers

If you or your users may face censorship threats, there are dedicated resources for help. Access Now runs a Digital Security Helpline providing 24/7 technical support for activists, journalists, and human rights defenders. They also publish guides on censorship circumvention tools and best practices for at risk communities.

The #KeepItOn coalition, led by Access Now, fights internet shutdowns globally and coordinates advocacy when governments cut connectivity during elections, protests, or crises.

What Developers Can Do

If you are building software that may be used in censored environments, here are some practical considerations.

Avoid hardcoded dependencies on single domains or CDNs that might be blocked. Mirror critical assets or use fallback origins.
Support proxy friendly configurations in your applications. Respect system proxy settings and avoid pinning certificates in ways that break MITM proxies (though this has security trade offs).
Consider domain fronting or alternative routing for critical services that need to reach users behind firewalls.
Keep Tor and pluggable transport compatibility in mind especially for tools serving journalists, activists, or at risk communities.
Educate your team about how censorship works. The more engineers understand DNS manipulation, DPI, and SNI filtering, the better they can design resilient systems.

Final Thoughts

Internet censorship is a technical problem with human consequences. As developers, we are in a unique position to understand the mechanics of how it works and to build systems that are more resilient to it. Whether that means designing censorship resistant infrastructure, supporting privacy preserving protocols, or simply understanding the landscape well enough to advocate for an open internet, the technical knowledge matters.

1 in 4 SMBs Hacked Despite Security Measures: Key Findings from Proton's 2026 Report

JustinF — Wed, 11 Mar 2026 08:38:51 +0000

Hey dev.to community! 👋

Welcome to the Proton organisational blog on Dev.to. We thought this would be a good place to share the original research we undertake, to do with data privacy and cyber security.

Here's what our latest survey data reveals about the current state of cyber security for small and medium businesses from our SMB Cybersecurity Report.

The Big Picture

Proton surveyed 3,000 decision-makers at companies with fewer than 250 employees across six markets: the US, UK, Brazil, France, Germany, and Japan.

The headline finding is that nearly 1 in 4 SMBs fell victim to cyberattacks in the past 12 months, despite having security measures in place. Well over 1 million SMBs in these markets suffered a cyberattack last year.

Key Findings That Matter to Developers

1. Spending Does Not Equal Security
Many SMBs have implemented formal risk assessments, regular audits, multi-factor authentication, and password managers. Yet breaches still happen. The report challenges the "SMBs are unprepared" cliché; these businesses are investing in security, but defenses are failing under real-world conditions.

2. Human Error Cannot Be Patched
39% of incidents stemmed from human error. Even with password managers deployed, credentials still circulate via email, messaging apps, shared documents, and written notes.

The takeaway is that training alone is insufficient. Security tools need to enforce good hygiene by default.

3. Cloud Dependency Creates Blind Spots
86% of SMBs rely on cloud providers like Google or Microsoft. However, 28% of that group say they do not feel in control of how their data is handled or are unsure. When your provider handles encryption keys and collects your data, third-party attacks can cascade to your business.

4. Security Is Now a Competitive Advantage
A clear majority of SMBs say demonstrating strong data protection is critical for winning new business. Clients are actively asking about security practices.

The Cost of Breaches

The financial and operational impact of these breaches is substantial:

Financial Loss: 57% of breached SMBs lost between $10,000 and $100,000.
Operational Downtime: 38% overall (rising to 51% in the US) suffered downtime or disruption.
Data Loss: 46% overall (53% in Brazil) experienced data loss.
Remediation Costs: 35% faced legal or IT remediation expenses (38% in Germany).
Penalties: 24% received regulatory penalties.

There are notable regional patterns:

US: Highest operational disruption (51%).
Brazil: Highest data loss rate (53%).
Germany: Highest legal and IT costs (38%).
Japan: Least impacted overall.

What This Means for Developers

If you are building tools for SMBs, consider the following:

Assume human error will happen: Design systems that contain mistakes rather than trying to prevent them entirely.
Default to secure: Optional security features get bypassed; baked-in security gets used.
Be transparent about data handling: 28% of SMBs do not feel in control of their cloud data.
Make security a feature, not a checkbox: It is now a selling point for your customers' customers.

Discussion

Have you worked with SMBs on security implementations? What gaps have you noticed between "security on paper" and real-world effectiveness?

Feel free to share your thoughts in the comments.

DEV Community: JustinF