[tor-dev] Anti-censorship discussion with Briar devs

[Cecylia Bocovich <cohosh@xxxxxxxxxxxxxx>]

Hi,

I just had a really great conversation with some of the developers at
Briar about the recent work they've done in integrating some pluggable
transports into their messaging application. I thought I would summarize
some key points from the conversation here. In particular, this
information might prove useful for both the metrics and anti-censorship
teams to know how other projects are using our tools and what they would
like help with.

This summary is organized as follows:

I. How they used metrics data
II. Independent reachability tests they performed
III. What they did to integrate pluggable transports into Briar
IV. What they want help with


I. How they used metrics data

One goal the Briar project had was to automatically detect where bridges
are needed so they can be enabled automatically and for Briar to "work
out of the box" with minimal developer overhead as they do not currently
have dedicated anti-censorship funding. Here is the related ticket with
a lot of useful discussion:
https://code.briarproject.org/briar/briar/issues/1266

They wrote a collection of analytics scripts that use both OONI and Tor
Project metrics data to determine where bridges are being blocked.

Source code for the scripts:
https://code.briarproject.org/briar/tor-circumvention-analytics/

Results (outdated): https://grobox.de/tor/bridges.html

They rely mostly on OONI data but also use some Tor metrics to look at
the ratio of bridge users in a country. Their reasoning being that while
OONI shows what doesn't work, Tor metrics data shows what is currently
working.

Source code for Tor metrics script:
https://code.briarproject.org/briar/tor-circumvention-analytics/blob/master/tor-metrics-bridges.py

The ticket linked above has more discussion that might be useful to the
metrics team as well.


II. Independent reachability tests they performed

To validate some of the results from OONI and Tor metrics, they ran a
private bridge and did some reachability tests to it from China. They
found that the bridge was not blocked, however they did not perform
bandwidth tests to determine whether or not obfs4 bridges are being
throttled. This makes sense as briar produces probably fairly low
bandwidth traffic. When I asked them about it they suggested performing
the following test:

Set up obfs4 to forward connections to a local http server that servers
a large, static file. Have a contact in China set up a cron job that
periodically downloads the file from the bridge via obfs4.

Their original reachability test was not running for very long, so it's
still possible that prolonged use would result in its discovery but the
fact that it wasn't blocked suggests that China might be enumerating
bridges through the distribution mechanism rather than by something
identifiable from obfs4 itself. We should perform our own tests to
verify this, and to check for throttling.


III. What they did to integrate pluggable transports into Briar

My understanding from the issue text and commit messages about how briar
decides whether to use pluggable transports is to use the output of
their reachability analysis to determine user needs by country. If Tor
is not blocked, users just use vanilla Tor If it is they use obfs4. If
obfs4 is blocked, then they use meek (meek lite). Right now the
countries that use meek in briar are: China, Iran, Egypt, Belarus,
Turkey, Syria, and Venezuela.

As far as the integration, they wrote some code that makes reproducible
builds of obfs4 and meek and spits out a java/android library:

https://code.briarproject.org/briar/go-reproducer

Briar already uses Tor, so they configure these bridges in the usual way
using a torrc file and a hardcoded, shipped file of bridge information
(which I believe are also the default bridges used by Tor Browser). They
decided they didn't want to maintain any private bridges like the one
they used for their reachability tests. One of the concerns there was
the ability to fingerprint Briar traffic by bridge connection and
differentiate it from other Tor traffic.


IV. What they want help with

Because they do not have dedicated anti-censorship funding, they
mentioned a few things that would help them maintain their pluggable
transport use going forward and ease the integration of pluggable
transports.

The main thing they would like on the metrics side is up-to-date
information about which PT works in which country and where PTs are
needed at all in order to make quick and easy decisions based on
location about which transports to use. They started to work with OONI
to expand their tests but it turned out to be too much work for their
time/funding: https://code.briarproject.org/briar/briar/issues/1414

It's on our roadmap to work with OONI and other censorship measurement
tools (like Censored Planet) to expand our tests so we should get into
contact with them again once we have gotten farther with this.

On the PT development side, they expressed a desire to transfer
maintenance of their reproducible builds of obfs4 and meek to someone
else (that's the go-reproducer code linked above).


_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev