The Exit country branch was sponsored by Google as a 2008 Google summer of code project. The project Manager was: Matt Edman, the student: Camilo Viecco. The objective was to add some 'blossom' functionality to vidalia, that is the ability to select a desired country to view the 'Internet' network from. The key assumtion is that the content of the network is different according to the users (ip address) country location. The second assumtion is that per country content views is pervasive while filtering on Tor exit nodes is not. 2. Implementaiton Overview The functionality was implemented as an additional 'tab' in vidalia's settings window. The interface provides checks to prevent users from accidentaly enabling this functionality as it significantly reduces users anonymity. The selection of the country is done via a 'combo-box', followed by an 'apply country' button. Every time the country is changed, the system close all built circuits, so that next circuit construction follows the policy. Also an 'avoid the following countries' selector was implemented. The implementation created a centralized geoip resolver class with a new and simplier API for any vidalia subsystem that desires geoip location. All of the geoip resolvers conforming to the API must be thread safe (after initialization) in order to be called from any place in the vidalia codebase. All implemented geoip resolvers (Tor,web,file) follow this restriction. The geoip parts were moved into a single directory. A new window tab 'policy settings' was created with the vidalia style for them (3 sets of files: page, ui, and settings). The system uses the new geoip api. Vidalia's 'netviewer' was modified to use this new geoip resolver (simplifying the netviewer class) The system has been tested in windows XP and Linux using qt 4.3.5. 3. Toughts and thigs to do. On the coding in general. The initial system implementaiton was straigtforward. However the need to build a unified API slowed down the coding. On things not implemented. A better way to detect if the current circuits satisfy the policy would be really handy, but is out of the scope for this summer. What I would do for a future student: Vidalia needs better documentation on its internal connectors. Reading the code is ok, but I found myself rebuilding some code to satisfy coding style that was not explicit. There is no need for students to be fluent in Qt, but c++ is really needed. What I would change in Vidalia. I disagree in the way comments are placed in the Hacking directives. I think that comments in /**/ are OK for .h files but are problematic for .cpp files as commenting large blocks of code for debugging/testing is cumbersome and leaves coders tempted to remove the comments. Otherwise I like it. //------------------------------- Appendix. GeoIP resolvers API. All Goip resolvers must implement the following functions: QString get_country(QHostAddress ip); GeoIp search(QHostAddress ip); void geoResolved(); If the modules uses a remote entitity for any part of the requests, the module MUST cache the answers. The cache MUST be at least 3000 entries in size. The functionality of the functions is: get_country -> gets the current known country of an ip address Syncronous. this function can open files, but should have a small bound on its termination time. If the module uses external resolving, the ip address should be added to the queue of unkown ip addresses. search -> gets the current known geoip info. Syncronous. this function can open files, but should have a small bound on its termination time. If the module uses external resolving, the ip address should be added to the queue of unkown ip addresses. geoResolved -> this function is called when the module has completed a new batch of requests, if the module has any remote resolving. //------------------------- Appendix. Code Details Modified files: src/vidalia/vidalia.h src/vidalia/vidalia.cpp src/vidalia/network/netviewer.h src/vidalia/network/netviewer.cpp src/vidalia/config/configdialog.h src/vidalia/config/configdialog.cpp src/vidalia/CMakeLists.txt src/vidalia/res/vidalia_common.qrc src/torcontrol/torcontrol.h src/torcontrol/torcontrol.cpp Moved/renamed/modified files: src/vidalia/network/geoipresolver.h -> src/vidalia/geoip/webgeoipresolver.h src/vidalia/network/geoipresolver.cpp -> src/vidalia/geoip/webgeoipresolver.cpp src/vidalia/network/geoip.h -> src/vidalia/geoip/geoip.h src/vidalia/network/geoip.cpp -> src/vidalia/geoip/geoip.cpp src/vidalia/network/geoipcacheitem.h -> src/vidalia/geoip/geoipcacheitem.h src/vidalia/network/geoipcacheitem.cpp -> src/vidalia/geoip/geoipcacheitem.cpp src/vidalia/network/geoipcache.h -> src/vidalia/geoip/geoipcache.h src/vidalia/network/geoipcache.cpp -> src/vidalia/geoip/geoipcache.cpp src/vidalia/network/geoiprequest.h -> src/vidalia/geoip/geoiprequest.h src/vidalia/network/geoiprequest.cpp -> src/vidalia/geoip/geoiprequest.cpp src/vidalia/network/geoipresponse.h -> src/vidalia/geoip/geoipresponse.h src/vidalia/network/geoipresponse.cpp -> src/vidalia/geoip/geoipresponse.cpp New files: src/vidalia/geoip/torgeoipresolver.h src/vidalia/geoip/torgeoipresolver.cpp src/vidalia/geoip/geoipresolver.h src/vidalia/geoip/geoipresolver.cpp src/vidalia/geoip/README src/vidalia/config/nodepolicypage.cpp src/vidalia/config/nodepolicypage.h src/vidalia/config/nodepolicypage.ui src/vidalia/config/nodepolicysettings.cpp src/vidalia/config/nodepolicysettings.h src/vidalia/res/country_loc.csv changes: -geoipresolver.* The vidalia geoipresolver class was renamed webgeoipresolver. The following chages were done: -Locks were added to make it thread safe -A new interface for querieng replaced the old one. This simplifies the entities that make the queries -Internal queues were inserted for the new interface. -filegeoipresolver.* A new geoiprsolver class that resolved geoip information from a local file. After initialization is thread safe -torgeoipresolver.* A new class that resolves geoip information by asking the Tor controller for information. After initialization is thread safe. -geoipresolver.* A new geoipresolver class, resolves via Tor, web or file depending on the availability of the resolvers. Assumes websreolver always exists but is the least prefereable way to do resolving.