[tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

[Tor Bug Tracker & Wiki]

#32740: Implement a feedback loop between BridgeDB and OONI
-------------------------------------------------+-------------------------
 Reporter:  phw                                  |          Owner:  phw
     Type:  project                              |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:
Component:  Circumvention/BridgeDB               |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  s30-o23a2, anti-censorship-roadmap-  |  Actual Points:
  2020Q1                                         |
Parent ID:  #31280                               |         Points:  10
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor30-must
-------------------------------------------------+-------------------------

Comment (by phw):

 Here are preliminary design considerations:
 * We want a standalone service (let's call it wolpertinger) that lives on
 polyanthum, alongside BridgeDB. Wolpertinger exposes an API that OONI and
 others (e.g., ICLab) can query to fetch bridges to test. Upon receiving a
 request, wolpertinger uses BridgeDB's SQL database and yet-to-be-defined
 heuristics to find a bridge that's worth testing, and returns its bridge
 line. While we are specifically designing wolpertinger to work well with
 OONI, other censorship measurement platforms should be able to use it too.

 * Arturo mentioned that OONI probes may not talk to wolpertinger directly,
 but rather proxy their requests over OONI's infrastructure. In this case,
 we don't need to worry about making wolpertinger resistant to censorship,
 but we may still want to make it available over domain fronting so we are
 prepared for a future in which censorship measurement probes (which are
 unlikely to be able to talk to *.torproject.org) connect directly.

 * When requesting a bridge to test, a censorship measurement probe should
 tell us the country it's in. We may also want to know its autonomous
 system. What else do we want to know?

 * We must authenticate incoming requests, so we can be sure that they are
 from OONI, and not from an attacker who seeks to collect bridges. A simple
 authentication token would do the job.

 * Once OONI has test results for a given bridge, these results have to
 make it back to wolpertinger somehow, so it can write them to BridgeDB's
 SQL database. Both a push and pull model are conceivable here; OONI could
 make another request containing the test results, or wolpertinger fetches
 the results from OONI's API.

 * Asked about the number of requests wolpertinger would be seeing, Arturo
 said "Looking at the number of opened reports per day (which is ~20k), we
 can estimate that it’s probably not going to be more than 20k requests per
 day for some time. Or somewhere in the range of 10-15 requests per
 minute."

 * Considering all of the above, wolpertinger's API could take the
 following JSON request format as input:
 {{{
 {
   "type": "TYPE",
   "country_code": "COUNTRY_CODE",
   "auth_token": "AUTH_TOKEN",
 }
 }}}
   `TYPE` identifies the censorship measurement probe, and could be "ooni"
 for OONI. `COUNTRY_CODE` identifies the country the probe is in and
 `AUTH_TOKEN` is an authentication token. Upon receiving this request,
 wolpertinger would then respond with:
 {{{
 {
   "bridge_lines": ["BRIDGE_LINE_1", ..., "BRIDGE_LINE_N"]
 }
 }}}

 Any thoughts on the above?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32740#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online