Below is a clean, high‑level system design for a Tor bridge distribution model where the user never sees the bridge, yet can use new pluggable transports (PTs). This stays architectural (not exploit‑level), which is how Tor itself discusses these ideas. ------------------------------ Goal Design a bridge distribution system that: 1. Hides bridge details from the Tor Browser user 2. Supports new / experimental pluggable transports 3. Reduces bridge enumeration by censors 4. Works under heavy DPI and HTTPS‑only regimes 5. Fits Tor’s existing trust and threat model ------------------------------ Core idea: Brokered, capability-based bridge access Instead of giving users bridge addresses, give them temporary access capabilities that let Tor connect without the user ever knowing where. Think: “I have permission to use Tor right now” not “Here is a bridge IP:port” ------------------------------ 1. High-level architecture Tor Browser | | (Capability request) v PT Broker (trusted, rotating) | | (Ephemeral routing info) v Hidden Bridge Network | v Tor Network The user: - Never sees IPs, domains, fingerprints - Just toggles “Censorship Mode” or “Transport X” ------------------------------ 2. Step-by-step flow Step 1: Capability request (not a bridge request) Tor Browser requests: “I support PT-X, need access” This request: - Looks like normal HTTPS - Is indistinguishable from other web API calls - Contains no identifying Tor metadata ------------------------------ Step 2: Broker returns a capability, not a bridge Instead of: bridge 1.2.3.4:443 fingerprint=... The broker returns: Signed capability token: - Valid for N minutes - Bound to PT-X - One-time or rate-limited The user cannot: - Reuse it - Share it - Inspect it meaningfully ------------------------------ Step 3: PT resolves bridges internally The pluggable transport: - Uses the capability to: - Discover a relay internally - Or connect via indirection (proxy mesh, rendezvous, relay lottery) - Bridge details exist only inside the PT process Tor Browser: - Never logs - Never stores - Never displays bridge info ------------------------------ 3. Why this defeats mass bridge enumeration China can: - Request capabilities ✔ - Use them ✔ But they cannot: - Bulk harvest bridge IPs - Build blocklists - Learn topology - Distinguish user vs censor requests reliably Blocking becomes: - Reactive - Noisy - Collateral-heavy ------------------------------ 4. Enabling new pluggable transports This model is PT‑agnostic. A new transport just needs: - Capability verification - Broker interface support Examples of future PTs this enables: A. HTTPS semantic PTs (Webtunnel++) - PT pretends to be: - REST API - WebSocket app - Video streaming backend - Broker rotates semantics, not just IPs ------------------------------ B. Relay lottery PT - Capability unlocks: - One of many hidden bridges - Randomly chosen - Short-lived - Censor can’t predict which bridge they’ll hit next ------------------------------ C. Multi-hop PT - Capability allows: - Entry via CDN → hop → hop → Tor - No single blocking point ------------------------------ 5. Why hiding bridges from users is important Today: - Users copy/paste bridges - Bridges leak via screenshots, logs, malware - Support forums leak them - Censors scrape everything With this design: - No bridge strings exist - Nothing human-readable - Nothing stable to leak This is zero-knowledge bridge usage from the user’s perspective. ------------------------------ 6. Trust and failure model (important) This does not require trusting the broker with identity. Broker knows: - “Someone asked for PT-X access” - Nothing about browsing - Nothing about destination Even if broker is: - Monitored - Partially blocked - Compromised Worst case: - Access degrades - Tor safety remains intact ------------------------------ 7. Why Tor hasn’t fully done this (yet) Real constraints: - Backward compatibility - PT ecosystem maturity - Operational cost - Risk of centralisation - Need for multiple independent brokers But Snowflake is already halfway there: - User doesn’t see proxies - Dynamic routing - Indirection-based access This proposal generalises that model. ------------------------------ 8. One-sentence summary Replace “bridge distribution” with “capability distribution”, and let pluggable transports resolve bridges invisibly and ephemerally. ------------------------------ Next we can: - Map this design onto existing Tor components - Show how Snowflake already approximates it - Design a concrete PT using this model - Explain how this resists China specifically - Discuss centralisation vs censorship trade-off.