Opened 8 years ago

Closed 7 years ago

#5484 closed project (fixed)

Make BridgeDB leave out blocked bridges

Reported by: karsten Owned by: aagbsn
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: SponsorF20121101
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From org/sponsors/SponsorF/Year2: "17. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out of the answer we provide. We'll want this building block once we have bridge reachability testing working."

From talking to Aaron in December:

  1. The current BridgeDB code contains a function to accept a list of blocked bridges by country to give out non-blocked bridges to users (#1837). This code needs testing. Also, there is a bug with how BridgeDB learns which country a user is interested in getting un-blocked bridges for, which currently conflicts with the language selection.
  1. There are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked" next to them. We're currently doing a), but we should do c) to improve usability. There are variants of b), e.g., b1) Christian suggests to give out exactly one non-blocked bridge if otherwise we’d give out zero bridges and b2) Roger suggests to give out the first three non-blocked bridges in a fixed set of five bridges. One part of this deliverable should be to discuss these alternatives and agree on one of them that shall be implemented.

Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?

Optimistically assigning to the July milestone.

Child Tickets

TicketStatusOwnerSummaryComponent
#1837closedbridgedb learns to load file of which bridges are blocked whereCircumvention/BridgeDB

Change History (12)

comment:1 Changed 8 years ago by aagbsn

#1837 is an easy fix that I dropped the ball on and forgot about. It should not take longer than few hours of work (call it a week) to do this bugfix if we agree that BridgeDB's user-interface can be changed. (See: #1837)

#5485 may require more rewriting of BridgeDB to make it behave the way we want to. I think it will take a few (2-3) weeks of debate to determine what we want to do, and another (2-3) weeks to implement the changes. Testing/Deployment has been historically rather slow, and we (I) aim to improve this now that we have a BridgeDB running on our own infrastructure.

comment:2 Changed 8 years ago by arma

The original text here was "leave the blocked bridges out of the answer we provide", and it somehow morphed in your title into "make bridgedb give out non-blocked bridges". If we give out working bridges in place of blocked bridges, without some significant cap on how many we give out, we undermine the whole rate-limiting plan. Let's not do that.

I think the work here should be quite simple and fast, and we should put the bulk of our time into actually getting "is it blocked" results for our bridge addresses. We can have the smartest algorithms in the world inside bridgedb, but if the "blocked bridge" files it reads are empty it's of no use.

comment:3 in reply to:  2 Changed 8 years ago by karsten

Summary: Make BridgeDB give out non-blocked bridgesMake BridgeDB leave out blocked bridges

Replying to arma:

The original text here was "leave the blocked bridges out of the answer we provide", and it somehow morphed in your title into "make bridgedb give out non-blocked bridges". If we give out working bridges in place of blocked bridges, without some significant cap on how many we give out, we undermine the whole rate-limiting plan. Let's not do that.

You're right. I fixed the summary. Feel free to fix it more.

I think the work here should be quite simple and fast, and we should put the bulk of our time into actually getting "is it blocked" results for our bridge addresses. We can have the smartest algorithms in the world inside bridgedb, but if the "blocked bridge" files it reads are empty it's of no use.

I disagree. The "is it blocked" results aren't part of this deliverable. This deliverable is specifically about preparing BridgeDB to be ready once we have these results.

comment:4 Changed 8 years ago by karsten

Some notes from the #tor-dev meeting on April 12:

  • Roger is worried that people have wildly different ideas of what algorithms BridgeDB should use. We agreed that doing a simple version for this deliverable is fine. If we have time left we should rather spend it on working on reachability testing (which is not part of this deliverable and which would be a sponsor Z deliverable).
  • In the context of algorithms that BridgeDB uses, Roger asked about the status of the BridgeDB spec (#1606). It was merged into bridgedb.git in April 2011 and is waiting for a review by Roger, Aaron, and Christian. It also wasn't updated since then, which may be due to lack of significant code changes. It should probably be updated once the changes for this deliverable are implemented.

comment:5 Changed 7 years ago by karsten

Milestone: Sponsor F: July 1, 2012Sponsor F: November 1, 2012
Owner: set to aagbsn
Status: newassigned

From talking to aagbsn today: there's a patch in aagbsn's development branch which is not yet merged into master, but which is in mergeable state. BridgeDB will process a file with lines "fingerprint address:port cc,cc,cc" meaning that the bridge running on the given address and port is unreachable from the given countries. We won't have a service putting out such a file very soon, but we still can call this ticket done once BridgeDB supports processing such a file.

Assigning to aagsbn and moving to November, because July 1 is already over.

comment:6 Changed 7 years ago by aagbsn

BridgeDB does support processing such a file.

comment:7 Changed 7 years ago by karsten

Awesome! Can you suggest a summary of a few sentences for the sponsor F page describing what we did and why we consider this deliverable done?

comment:8 Changed 7 years ago by karsten

Keywords: SponsorF20121101 added
Milestone: Sponsor F: November 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:9 in reply to:  7 Changed 7 years ago by karsten

Replying to karsten:

Awesome! Can you suggest a summary of a few sentences for the sponsor F page describing what we did and why we consider this deliverable done?

aagbsn, did you see this comment? (Thanks!)

comment:10 Changed 7 years ago by aagbsn

We won't have a service putting out such a file very soon, but we still can call this ticket done once BridgeDB supports processing such a file."

BridgeDB's censorship descriptor format was extended to support bridges that have multiple or-addresses or listening ports. BridgeDB now learns about bridge censorship by parsing a list of blocked addresses and ports in censored regions. BridgeDB supports requests for bridge addresses "not blocked in" a region, and also supports region detection with GeoIP. BridgeDB responds from the set of bridges that are not blocked in the requested or (configurably) detected region.

comment:11 Changed 7 years ago by karsten

Added as summary to the sponsor F page. Thanks!

What about the child tickets? We'll need to close them before closing this ticket. #1837 looks like it can be closed, and #5485 looks somewhat unrelated. Can we either close those tickets or remove the parent ticket relationship? And then we'll want to close this ticket.

comment:12 Changed 7 years ago by aagbsn

Resolution: fixed
Status: assignedclosed

I removed the parent relationship between #5485 and closed #1837.

Note: See TracTickets for help on using tickets.