---

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.