Snowflake

Snowflake is the WebRTC-based Tor pluggable transport for censorship circumvention — a Tor Project tool that lets people in censored networks reach the Tor network by tunneling through volunteer-run WebRTC proxies that look like ordinary browser video-call traffic. Listed at Grade A because Snowflake occupies a structurally unique position: it's the easiest way to volunteer infrastructure for the censorship-bypass commons (install a browser extension and your visitor flow becomes bridge capacity), and it's one of the most-deployed practical answers to bridge enumeration (since traffic to volunteer proxies looks like WebRTC, censors can't easily distinguish Snowflake traffic from legitimate video calls).

Background. Snowflake was developed by The Tor Project as part of their pluggable-transports research, with implementation work led by Cecylia Bocovich and David Fifield among others. Active development since 2018, with stable production deployment since 2020. Open source as part of the Tor Project codebase; main repos at gitlab.torproject.org/tpo/anti-censorship/. The protocol uses WebRTC (the real-time-communication standard browsers use for video and audio calls) as its transport, which has three properties that matter for censorship: (1) WebRTC traffic is already-ubiquitous on the open internet (Google Meet, Zoom, every browser video call), so blocking it would have huge collateral damage; (2) WebRTC connections are NAT-traversing, so volunteers behind home routers can serve as bridges without configuring port forwarding; (3) the rendezvous mechanism (how clients find proxies) uses a small set of resilient signaling channels (AMP cache, fastly CDN, Cloudflare worker) that censors can't easily enumerate.

What you trust. The Tor Project — same organisational backing as Tor Browser, with public mission alignment for censorship circumvention. WebRTC traffic obfuscation — your Snowflake-encapsulated traffic looks (from a censor's perspective) like an ordinary WebRTC connection to a random IP. NAT-traversing — Snowflake proxies can run behind home routers without port-forwarding, which means volunteer infrastructure is easy to deploy (browser extension is enough). Open-source pluggable transport — the protocol and reference implementation are auditable; censors can't fingerprint it via secret-algorithm tricks. Volunteer-run infrastructure — Snowflake's proxy network is decentralised; no single point of compromise. What you don't trust: the proxy you connect to — Snowflake proxies are run by anonymous volunteers; they see encrypted Tor traffic (not your content) but they see your IP and the timing of your connection. The Tor circuit itself (after the Snowflake proxy hop) provides the anonymity; the Snowflake proxy is just the entry point. Bandwidth and latency are variable — volunteer-run infrastructure varies in capacity; some proxies are fast, some are slow.

Operational specs. Client side (you, the censored user): Snowflake is bundled into Tor Browser as a pluggable transport — when you click "Configure" in Tor Browser's network settings and pick "Snowflake," your connection routes through a Snowflake proxy. No separate install needed; Tor Browser handles it. Volunteer side (you, running a proxy to help): install the Snowflake browser extension on Firefox or Chrome and you become a bridge — your browser's idle WebRTC capacity is offered to censored peers. Optional standalone runner: a command-line proxy for users who want to run a higher-capacity bridge from a server. Mobile: Tor Browser for Android supports Snowflake; iOS via the Onion Browser app. Performance: typical Snowflake bandwidth is constrained by the volunteer proxy's connection (often residential home internet); expect 1-10 Mbps in practice. Latency adds the WebRTC connection-establishment overhead on top of Tor's three-hop. Reliability: when one Snowflake proxy disconnects (volunteer closes the browser), your client automatically reconnects to a different available proxy.

Philosophy. Snowflake's editorial differentiator is the volunteer-infrastructure-via-browser-extension model — it's the only Tor pluggable transport where the volunteer barrier-to-entry is "install a browser extension." Compare to obfs4 (requires running a server with public IP), Meek (uses CDN domain fronting; CDN providers have started blocking the technique), or webtunnel (newer, requires server setup). Snowflake's design *explicitly* prioritises easy volunteer onboarding: if a million people in non-censored regions install the Snowflake extension, the censorship-bypass network has a million bridges, and no censor can block "people using WebRTC" without breaking the internet. The trade-off: residential-grade bandwidth, no service-level reliability guarantees. For mass-scale censorship circumvention this is the right model; for high-bandwidth specific-use circumvention, dedicated bridges (obfs4) may be more reliable.

Grade rationale. Grade A reflects: developed and maintained by The Tor Project (canonical anti-censorship organisation); open-source as part of the Tor codebase; 7+ years of operational continuity (active since 2018, production-stable since 2020); WebRTC-based protocol leverages traffic that's already ubiquitous on the open internet (high collateral-damage cost for censors); volunteer-run proxy network (decentralised, hard to enumerate); browser-extension volunteer onboarding (lowest barrier-to-entry in the pluggable-transport space); bundled in Tor Browser as a default option; available for Firefox, Chrome, Android, iOS (via Onion Browser); maintained official Tor onion at oljlphash3bpqtrvqpr5gwzrhroziw4mddidi5d2qa4qjejcbrmoypqd.onion; cross-listed in Privacy Guides peer directory. Last verified 2026-05-13.

Useful when. You're in a censored network (China, Iran, Russia in some periods, Turkey in some periods, etc.) and need to reach Tor — Snowflake is the recommended first-try pluggable transport in many regions. You want to volunteer infrastructure for the censorship-bypass commons — install the Snowflake browser extension and you contribute bridge capacity by just keeping the extension running. You're building censorship-resilient applications and need an embeddable Tor entry point that's hard to block — Snowflake's underlying protocol is reusable. You're a journalist or researcher working with sources in censored regions — recommending Snowflake (rather than direct Tor) is the right first step for someone who hits Tor-blocking. You're running a high-volunteer activist organisation and want a low-cost way for your supporters to help censored users access uncensored information. You're testing Tor Browser in a censored network simulation and need a pluggable transport that's representative of the typical user's first hop.

Caveats. Bandwidth is variable — volunteer proxies are residential-grade, often slower than direct Tor connections; expect performance to be inconsistent across sessions. Latency is higher than direct Tor — Snowflake adds a WebRTC-handshake hop on top of Tor's three-hop overhead. Volunteer proxy churn — proxies come and go as volunteers open/close their browsers; the client handles reconnection automatically but mid-session disconnects happen. WebRTC requires NAT-traversing infrastructure that censors *could* try to block — Snowflake's design makes blocking high-collateral-damage, but a determined censor could disrupt the rendezvous channels. The Tor Project maintains multiple resilient rendezvous channels; this is an active arms race. Doesn't replace direct Tor — if you're not in a censored region, use direct Tor (Tor's own default circuit). Snowflake is a censorship-bypass tool, not a privacy upgrade. Volunteer proxies see your IP — the proxy can't see your encrypted Tor content, but it sees your IP and connection timing. For most users this is fine (residential volunteers aren't surveillance threats); for high-threat models, evaluate whether a specific proxy you happen to connect to is trustworthy. Browser-extension volunteer mode uses idle bandwidth — when running as a volunteer, the extension uses some of your home internet bandwidth to serve censored peers. The default is conservative; you can adjust limits in the extension settings if you have constrained bandwidth or data caps. Don't expect Snowflake to be your-only-line-of-defence — in heavily-censored regions, expect to try multiple pluggable transports (Snowflake first, then obfs4, then meek, then webtunnel) depending on what the local censorship pattern blocks at any given time. Mobile UX is more limited than desktop — Tor Browser for Android supports Snowflake but the volunteer side is desktop-browser-extension only at this writing.