The goal of this session was to identify questions that would need to be answered in order to build a solution into Tor Browser's launcher to automatically determine whether to use bridges in a particular country.

This automation would be driven by using data from OONI and Tor Metrics.

There is the potential to apply for a grant to support research in this area, mostly interested in improving usability, but also remaining safe while doing so.

The two big questions to emerge from this discussion were:

  • What data do we need in order to know which pluggable transports work, and where?
  • How can we apply this in mobile, desktop, live systems (e.g. TAILS), and other scenarios?

Data Collection

OONI's Vanilla Tor test is already collecting data from desktop probes. Most countries appear to have no issues directly connecting to Tor but there are countries that do show impairment. OONI also has tests for the reachability of TBB's default bridges and for the reachability of domains used by the meek pluggable transport.

Adding Tor support to measurement-kit is a work in progress and would be required to enable measurement of vanilla Tor and bridge reachability from mobile platforms. If possible however, this would considerably increase the counts of measurements as there are a lot more mobile platforms reporting measurements than desktop probes.

In order to expand the number of measurements, it would be possible to add an extension to Tor Browser to send OONI measurement reports including bootstrap time, transport and country, along with cached results of any failed transports attempted before being able to connect.

Tor relays also report statistics to the directory authorities that allow us to calculate the number of directly connecting users per country and likewise bridges report data that allows us to see the number of bridge users by country and transport. By correlating with these passive measurements we can give more weight to the measurement results provided by from OONI.

An adversary may try to affect OONI measurements to drive users towards an easily monitored transport. It would be possible, although it is not clear how easy it would be, to manipulate both OONI and Tor Metrics data simultaneously. One possible countermeasure is signed measurements from trusted individuals and OONI also has network of people in interesting countries that can provide local context.

Data Distribution

Getting up-to-date data to clients is another problem in itself. OONI has data to show that the state of censorship is fairly static and so perhaps updates don't need to happen that often.

Moat currently runs over a meek transport and could be used to distribute this data. meek appears to be very resilient, however it is also expensive (in bandwidth costs) and so it would be preferred to not have all clients attempting to use meek to download the latest censorship data. Using meek in this way would also provide meek endpoints with the IP addresses of all Tor's users.

The data could also be distributed as part of the Tor Browser Bundle, or even with the tor client itself, so that the client already has it.

Automatic Country Detection

  • What explicit consent is required from users before attempting automation of country detection and/or performing connections?
  • Can a country be predicted in a safe way?
    • Mac and Windows has location services, but may scare users if Tor asks for these permissions.
    • tor has geoip database already, if the user has an IPv6 global scope address this may be useful, not used for NAT'd IPv4 clients though.
    • On mobile, there may be APIs to get information from the operator, but may open user to attacks due to extra permissions that are only used once to bootstrap connection.
  • Country code is known on the download page.
  • Could use a CDN with DNS lookup to find the country, but then the CDN gets the IP address of every tor client.

Process and UX

  • UX should make it clear that country will not be reported back to Tor.
  • Need to talk to some users and ask them how they would use this setup.
  • Performing optimistic connections may have negative consequences for users, e.g. triggering stateful DPI or restricting internet access
  • Difficult to understand configuration and install pluggable transports
  • Currently only optimistic connection automatically available for direct connection, not pluggable transports.
  • Should we have a zero click option where we expect that Tor will just work. Could reduce user support issues to hide unneeded dialogs from users.
  • How does this apply to mobile, desktop, tails, and other platforms.
  • Need for clear language to explain bridges to users, currently PTs have confusing names.

Other Issues

  • Do we have the right pluggable transports?
  • Could Tor Browser set up private bridges on-demand in cloud providers?
  • How should users that travel often (in and out of censored networks) be handled?
Last modified 3 years ago Last modified on Mar 12, 2018, 5:30:17 PM