[tor-bugs] #1837 [BridgeDB]: bridgedb learns to load file of which bridges are blocked where

[Tor Bug Tracker & Wiki]

#1837: bridgedb learns to load file of which bridges are blocked where
----------------------+-----------------------------------------------------
 Reporter:  arma      |          Owner:              
     Type:  defect    |         Status:  needs_review
 Priority:  normal    |      Milestone:              
Component:  BridgeDB  |        Version:              
 Keywords:            |         Parent:  #1608       
   Points:            |   Actualpoints:              
----------------------+-----------------------------------------------------

Comment(by aagbsn):

 Replying to [comment:7 karsten]:
 > Thanks for making the changes!  I ran your code on a local machine and
 it did what I expected.  Yay!
 >
 > Here are a few more comments, none of them preventing us from merging
 your patch:
 >
 >  - There's a typo in the README: "<ountry code>" should be "<country
 code>"
 >
 >  - Can you add a short explanation for installing the Maxmind GeoIP
 library and database to the README?  On Debian, this is just "apt-get
 install python-geoip", but adding a link to
 http://www.maxmind.com/app/python might be good, too.
 >

 all above fixed

 >  - Should BridgeDB only attempt to load a GeoIP database if we're using
 a blocked-bridges file?  Is there an easy way to change this?
 >

 good idea. It is easy to change:

 BridgeDB could check to see if the configuration object has a
 COUNTRY_BLOCK_FILE defined and if so try to import the GeoIP module there.

 Probably the best place for this is in the call to addWebServer() -- a
 similar approach is used to only import twisted ssl support if HTTPS_PORT
 is defined.

 >  - I noticed that the way to request unblocked bridges via HTTPS is to
 request https://bridges.tpo/cc , right?  Wouldn't it make sense to resolve
 the IP address to a country code, now that we have a GeoIP database?  No
 need to implement this now, but I'd like to know if it makes sense to do
 this in the future.
 >

 This is the current behavior. If the client specifies a cc this will
 override GeoIP.

 >  - The email distributor doesn't support removing blocked bridges from
 results, yet, right?  Again, no need to implement this now, but how would
 we implement it?  How would people provide their country code here?

 Blocked bridge filtering for email will work if a country code is passed
 to Dist.EmailBasedDistributor.getBridgesForEmail()

 People could provide the country code in the subject or body of the email.
 This might be a bit confusing because emails sent to bridgedb+cc at tpo allow
 the user to specify the language of the email and a second cc field may be
 confusing.

 The language of an email doesn't indicate the clients network location, so
 filtering options should be explicit and not assumed.

 >
 >  - I'm planning to add the following paragraph to the end of Section 4
 of the
 [https://gitweb.torproject.org/karsten/bridgedb.git/blob/refs/heads/spec
 :/bridge-db-spec.txt BridgeDB spec].  Does that paragraph make sense to
 you, and does it cover the most important parts of your patch?
 >
 >    "BridgeDB can be configured to read a file with the fingerprints and
 country codes where bridges are assumed to be blocked.  Bridge users
 requesting bridges via the HTTPS distributor can specify their country
 code cc by requesting URL /cc.  BridgeDB will then remove all bridges that
 are assumed to be blocked in that country from the result.  The idea is
 that bridge users don't learn about bridges that very likely don't work
 for them."

 +
 BridgeDB will use GeoIP-based country detection to remove blocked bridges
 from the result if GeoIP support is available.
 >
 > So, I say let's merge your patch.  Can you add a single commit on top of
 origin/master that contains your diff (plus the changes above)?  Bonus
 points for a good commit message. :)

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