[anti-censorship-team] Plans for BridgeDB's future

[Philipp Winter]

This email introduces our plans for BridgeDB's future.  I attached a
diagram that illustrates how these plans integrate into BridgeDB's
existing design.  Red components in the diagram (Salmon, bridgestrap,
and wolpertinger) are new, and in the process of being built.  I
introduce these components below.

The Salmon social distributor
---------------------------------

A PETS'16 paper introduced the Salmon social proxy distributor:
<https://censorbib.nymity.ch/#Douglas2016a>

In a nutshell, Salmon hands out bridges to users while maintaining
per-user reputation scores.  Alice's reputation goes up if her bridge
remains unblocked after she got it, and it goes down if the bridge is
blocked after Alice got it.  Users can invite each other, which results
in an invitation graph.  Eventually, we will hopefully have a Salmon
distributor which will live alongside our Moat, HTTPS, and Email
distributors.

If this interests you, consider attending our anti-censorship meeting on
May 14 because we will be discussing the Salmon paper as part of our
reading group:
<https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#IRCmeetingsschedule>

We are only just starting to think about Salmon, so I have no code or
design to share at this point.  All that matters for now is that Salmon
needs to know where bridges are blocked.  BridgeDB does not have this
information but the following software components seek to fix that.

Bridgestrap
-----------

Bridgestrap exposes an API that takes as input a bridge line and
responds by telling you if it could establish a Tor circuit over the
given bridge.  BridgeDB will check with bridgestrap if the bridges it's
about to hand out actually work.  This isn't always the case as the
following ticket shows:
<https://bugs.torproject.org/30441>

We have a working prototype of bridgestrap:
<https://gitlab.torproject.org/phw/bridgestrap>

We coordinate development in this ticket:
<https://bugs.torproject.org/31874>

Wolpertinger
------------

Wolpertinger exposes an API that lets censorship measurement platforms
like OONI request bridges to measure.  Wolpertinger later fetches OONI's
test results and feeds them back into BridgeDB's bridge database.  This
allows BridgeDB to take into account a user's location when distributing
bridges: a user in Turkey won't be given bridges that are known to be
blocked in Turkey.

In addition to OONI, we could repurpose bridgestrap as another
censorship measurement tool by setting it up on a VPS in, say, Turkey
and have wolpertinger periodically feed it bridges to test.

Wolpertinger is work in progress but we already have some code:
<https://gitlab.torproject.org/torproject/anti-censorship/wolpertinger>

We coordinate development in this ticket:
<https://bugs.torproject.org/32740>

A practical example
-------------------

To illustrate how these pieces fit together, let us consider the example
in the attached diagram.  Imagine that the bridge 1.2.3.4:1234 was just
set up and reported itself to Serge, our bridge authority.  Serge syncs
its bridge descriptors to BridgeDB every 30 minutes and BridgeDB reloads
those descriptors every 30 minutes, so it takes a maximum of 60 minutes
until BridgeDB knows about this new bridge.

Now, a user from Turkey requests a bridge over HTTPS.  Since BridgeDB
sees the user's IP address, it knows that the request is coming from
Turkey.

First, BridgeDB will ask a local instance of bridgestrap if the bridge
it intends to hand to the user is working.  This is important because
the only testing we currently have in place is done by the bridge
authority, which makes sure that a bridge's OR port is reachable.
Nothing is testing a bridge's obfs4 port, which means that a user may
end up with a bridge whose obfs4 port is firewalled.

Bridgestrap can tell BridgeDB if a bridge is functional but it doesn't
know if the bridge is blocked in Turkey.  This is where wolpertinger
comes in.  Wolpertinger works in an asynchronous manner to BridgeDB and
1) hands out bridges to OONI probes, 2) collects OONI's test results,
and 3) writes these results back to BridgeDB's bridge database, allowing
BridgeDB to learn if a given bridge is blocked in Turkey.

If everything works out, our user will receive bridges that are
functional and unblocked in Turkey.

Please let me know if you have questions or feedback.

Cheers,
Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bridgedb-future.pdf
Type: application/pdf
Size: 72087 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/anti-censorship-team/attachments/20200512/e2509feb/attachment.pdf>