Mark: Integrating new CAPTCHA for getting bridges.

Arturo: Still a lot that gets in the way of users for connecting to bridges in Tor Launcher. Case 1: Vanilla Tor just works for say 90% of users Case 2: Configuration of a proxy is requiring in order to get Tor connected (behind proxy). Can read settings from the OS in the future (and perhaps remove from Tor Launcher). Case 3: Vanilla Tor does not work. Pluggable transports are pre-baked. In some countries, default bridges don't work, user needs fresh bridges.

OONI has done a lot of thinking about their "onboarding" process; perhaps Tor Browser/Launcher can learn from their efforts.

New Tor Launcher UI is going to be released over the next few months.

One possible approach is for OONI to take a snapshot of data about where Tor is blocked; could ask users what country they are trying to connect from and optimize the workflow of which bridges to try, etc. based on country choice plus the OONI data.

Is it possible to detect the country? Maybe, although this could be viewed as privacy-invasive. This is also a UX problem of course.

Things OONI data can give us:

  • Vanilla Tor tests: what countries does Tor work 99% of the time?
  • We scan all default Tor bridges in Tor Browser for reachability.
  • We can use this data to skip trying the built-in PT bridges and go to the step of helping users request custom bridges.
  • Can we just choose the best bridge type for a given country?
  • OONI is working on adding support for a variety of transports to their library. Need APIs / cooperation from PT developers.
  • One issue is identifying a clear owner / maintainer for each PT. (Some kind of coordination page and PT mailing list might help.)
  • Currently, OONI does a reachability test for all of the built-in bridges. They also test meek end-to-end connectivity (although it is still possible that a censor could use traffic analysis or another technique to block meek when it is used within Tor Browser).

Per-counrty test data:

In the long run we will need a plan for updating the data that is in Tor Launcher (e.g., if a country starts blocking Tor tomorrow, we would ideally have Tor Launcher act differently for new users and to fix things for existing users within that country).

China currently: default bridges don't work. Apparently able to flag obfs4 traffic. meek seems to be the main option. A broader strategy question, given the cost of running meek, is what solution we should use for users in China.

Classes of PTs:

  • Try to make the data look like nothing or gibberish, e.g., obfs4 and ScrableSuit.
  • Make the cost of blocking too high due to collateral damage, e.g., meek.
  • Try to mimic the traffic of an existing protocol, e.g.. FTE (make it look like HTTP POST requests).
  • Distributed (which means difficult to block) but discoverable for Tor users, e.g., Snowflake.

Longer term:

  • Can Tor Launcher integrate some OONI tests to help automate the setup process? This would be based on ooniprobe.
  • Can can the data be sent to OONI on an opt-in basis, thus providing value to OONI?
  • Many countries are not currently covered.
  • We could also collect data that may be helpful to core Tor (e.g., performance data), to PT developers, and to others.
  • If other services such as Lantern and Psiphon also participate, could provide a service to users to help them choose the best solution. OONI is already talking to those other services.

Next Steps:

Last modified 3 months ago Last modified on Oct 12, 2017, 8:07:07 PM