Which bridge protocols should we support?

Abstract: How to kill obfs2 for once and for good (#10314 (moved))? Should we stop spreading non obfuscated bridges entirely?

Minutes

We will always have bridges that are 'obsolete', because their transports are blocked in that country. What should we do with them? Should we give them to non-China?

Idea: only give one type of transport per user.

1. If you give them two, you give the attacker more chances to notice the user, and thus more chances for the attacker to see the other bridge.
2. If you give them two, it's harder for support people to figure out which transport they use

So the bridges who offer obfs3 also offer obfs2? Doesn't that mean if the attacker finds an obfs2 bridge, it's more likely they'll find the obfs3?

The ORPort is still exposed, so if they get the IP, they already have something they can scan.

Mike has been working on a Tor launcher wizard to let the user end up with the right transport for their country.

Need bridgedb user interface to let users specify their country, so we can select what transport to offer them.

Current state:

.cn    = -obfs2 (i.e. "everything but obfs2")
others = .      (i.e. "everything")

So Tor launcher can simplify its UI to "China, other" instead of country pulldown box

Mike points out a Tor bug where Tor launcher doesn't get 'bootstrap failed' events from Tor when pluggable transports are in use. (Is there a ticket for that?)

How to automate the detection that a given transport isn't working?

Option one, users tell support team, and support team looks for patterns of complaints. Option two, the bridge notices whether usage from a given country has dropped (we aggregate all bridges in the country to reduce variance).

We need to make sure that whatever transport we give to the user, his TBB supports it.

Answer: the PT TBB will become the standard TBB real soon now.

Workflow:

1. User learns about Tor, downloads tor browser bundle.
2. Tor launcher has a wizard to ask about country, and then ask if should use default (built-in) bridges, and it knows what transport to suggest for that country.
3. If not default, give them instructions on how to interact with bridgedb

TODO: Make sure Tor launcher recognizes and handles the "you configured a transport that Tor doesn't have a clienttransportplugin line for" error.

Idea: take a gsoc student to implement one of these simple circumventors to automate tor launcher helping the user getting bridges even when BridgeDB is blocked?

There's the other problem of how to get bridges to support new transports, when we need to move users to a new transport

Can we give Debian users an uberdeb that makes them keep up to date with new transport debs?

Idea: in the consensus, we could inform bridges whether they should stop offering a given transport.

Two missing steps in the short term:

• Fix Tor bugs
• Write text for how to interact with BridgeDB

Mike has a goal: this PTTBB should not expose the user to any additional risk of enumeration as being a Tor user. If every user has obfs2 bridges and also obfs3 bridges, and obfs2 bridges are loud announcements of Tor use on the local network, then they're harmful compared to not using them.

Long-term wishlist idea: ship ooniprobe or something like it with TBB, where if your Tor isn't working, you can ask it to probe your network and upload a report.