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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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):

 Thanks for your feedback!

 Replying to [comment:5 cohosh]:
 > 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?
 [[br]]
 It's the former. We want censorship measurement platforms to tell us if a
 given bridge is reachable in country X. BridgeDB already has code that
 takes into account where a bridge is blocked and where a user is from. The
 goal is to optimise bridge distribution, so users end up with bridges that
 are (most likely) unblocked in their country.
 [[br]]
 > 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.
 [[br]]
 I suggest we start with low-risk bridges like our default bridges (which
 are already public anyway) and bridges in our HTTPS/Proxy bucket. We lose
 little to nothing if these bridges get into our adversaries' hands.
 [[br]]
 > > * 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.
 [[br]]
 That's a great question and I don't have satisfying answers yet. But I
 agree that we should start with a small set of bridges and iterate as we
 gain experience. We should at least build this system in a way that it
 doesn't make it easier for an adversary to collect bridges.
 [[br]]
 > 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.
 [[br]]
 Yes, agreed.
 [[br]]
 > >- 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).
 [[br]]
 I don't follow: do you mean an OONI probe should embed a timestamp when
 requesting a bridge to test? Why do we want a probe to request bridges
 multiple times per time frame?

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

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