Opened 8 months ago

Last modified 6 months ago

#32662 new defect

Rewrite BridgeDB with Django 3 and Python 3

Reported by: moonsikpark Owned by:
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords:
Cc: phw, cohosh Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

BridgeDB, to my knowledge, was developed more than 10 years ago. Although it is working well, it's ages are starting to show. Rewriting BridgeDB to be compatible with Python 3 while maintaining the status quo seems not only hard but also seems like missing a good opportunity to write it again.

I propose rewriting BridgeDB with Django. With Django, BridgeDB codes will be more compact, clean and easy to understand.

Child Tickets

Change History (2)

comment:1 Changed 8 months ago by phw

Cc: cohosh added

(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:

  • 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 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).

comment:2 Changed 6 months ago by phw

Parent ID: #30946

Note that our Python 3 port over at #30946 is now done. I'll leave this ticket open for now, in case anyone's interested in the Django part.

Note: See TracTickets for help on using tickets.