Re: [tor-bugs] #32662 [Circumvention/BridgeDB]: Rewrite BridgeDB with Django 3 and Python 3

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

#32662: Rewrite BridgeDB with Django 3 and Python 3
------------------------------------+------------------------
 Reporter:  moonsikpark             |          Owner:  (none)
     Type:  defect                  |         Status:  new
 Priority:  Medium                  |      Milestone:
Component:  Circumvention/BridgeDB  |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:                          |  Actual Points:
Parent ID:  #30946                  |         Points:
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------
Changes (by phw):

 * cc: cohosh (added)


Comment:

 (This is related to #30946, in which we're working on porting BridgeDB to
 Python 3, so Python 2's end of life won't turn into a bad surprise for
 us.)

 Do you envision Django to replace BridgeDB's user-facing frontend and the
 way it interacts with its database? Or more than that? I'm asking because
 I'm not familiar with Django and I'm trying to understand the intended
 scope of this rewrite. After all, there's a ton of backend code in
 BridgeDB.

 That said, here's a list of significant issues that we may want to keep in
 mind while rewriting (parts of) BridgeDB:

 * [https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt
 BridgeDB's specification] is outdated and in dire need of an update
 (#31426).

 * There's plenty of code in BridgeDB that seems unimportant and/or broken.
 PGP support for emails (#17548) is a good example and we may want to rip
 out this feature altogether.

 * BridgeDB's most significant conceptual issue is that it has poor
 defences against crawlers. Our CAPTCHAs are difficult to solve for people
 (#29695) but easy to solve for crawlers (#32117). A rewrite won't solve
 this issue; we'll have to do more thinking first.

 * Note that [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go snowflake's broker] and
 BridgeDB are conceptually very similar. Both provide clients with bridge
 addresses, but do so in different ways. Before rewriting BridgeDB, we
 should think about merging these two concepts.

 * There should be a feedback loop between bridge distribution and
 measurement. BridgeDB should get its bridges scanned by OONI, and then use
 the scan results to decide what bridges to hand out to users. For example,
 if OONI tells us that a bridge is blocked in Turkey, we should no longer
 hand it out to users coming from Turkey. Similarly, some countries are
 known to block certain circumvention protocols by DPI, so we shouldn't be
 handing these out (#31875).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32662#comment:1>
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