[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 cohosh):

 Replying to [comment:4 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.
 >

 Cool! I like the idea of having a standalone service with a general API
 that multiple external measurement platforms can use.

 I'm mostly thinking about this from a bridge enumeration standpoint at the
 moment, since this opens up another vector for attack. I guess my first
 question here, is what are we most interested in learning from this? Is it
 whether specific bridges have been blocked in specific places, or that
 countries X, Y, and Z are very effective at blocking bridges of type A?

 If we want general stats and information about what different censors are
 doing, then I would suggest making another partition of bridges and giving
 out these bridges to the probing services (as well as to users). This will
 limit the damage of a censor that uses an OONI client to figure out what
 OONI is probing.

 If we do want to know when and where each specific bridge is blocked, then
 we should make sure we know how useful this information is to us and what
 we're going to do with it. If it's not useful, perhaps we should re-
 evaluate whether it's worth the exposure. Or if there's a less risky (more
 passive) way to get this information.

 > * 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.

 Another question for the OONI side of things: are all OONI clients testing
 each bridge? Or just a subset of them? A subset will again limit exposure
 and make it difficult for a censor to be able to enumerate bridges just by
 running an OONI client.

 I like this design for now where OONI gets the bridge information and
 distributes it to probes as opposed to probes asking for it directly. This
 is much easier for us to secure and I'm not sure we'd ever want to the
 latter situation because of the potential for enumeration.

 >- 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?
 A timestamp for sure. I think it would be useful for the same probe to try
 multiple times within some time frame (4x/day for 2-3 days).

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