Google Summer of Code

Polipo changes maintainer

phobos — Fri, 11 Dec 2009 13:02:36 -0800

Congratulations to Chrisd for assuming maintainership of the Polipo codebase from Juliusz. The full announcement is available at the mailing list archives.

Why Chris?

Chrisd was a 2009 Google Summer of Code for Tor/EFF. His project was Polipo Portability Enhancements. Chris has proven himself to be a very competent coder and able to design and implement features as needed. He even wrote a SOCKS layer fix for Firefox bugs, https://bugzilla.mozilla.org/show_bug.cgi?id=280661.

What does this mean to Tor?

It means we have a fantastic new coder maintaining the polipo codebase. Bugfixes, features, and more frequent releases should help improve polipo beyond where it is today.

Is Tor going to control Polipo?

We're not going to influence Chris on the direction of Polipo, but provide him support, volunteers, and an infrastructure to let him do what he needs to do. Juliusz created polipo and got it off to a great start. We're going to support Chris in continuing the progress. The world still wants an http proxy that's modern, fast, and flexible. Privoxy is a fine alternative to polipo, perhaps the two projects can come together.

What's happening to Juliusz?

Juliusz is a busy person. His free time has been concentrated on Babel, http://www.pps.jussieu.fr/~jch/software/babel/, over the past year. Juliusz is still a committer to polipo. We appreciate all of his help during the transition and for the years of maintenance of polipo.

BitTorrent support for Thandy

Sebastian — Thu, 10 Sep 2009 12:16:03 -0700

As a returning Google Summer of Code student for the second year in a row, I was thrilled to hear that I had been accepted again.

My task was to add BitTorrent support to Thandy, the secure automated updater developed by the Tor project, along with setting up and testing the necessary infrastructure. The goal is to better mitigate load spikes following the release of new software versions and allowing volunteers to easily help users to fetch Tor.

Of course, working wasn't without its own challenges. My mentor and I live in different parts of the world, and real-time communication was often difficult to achieve due to timezone differences. Another big challenge was staying motivated during the first month, where university demanded a lot of attention. The situation improved substantially after the mid-term evaluation, when school-related work became less time consuming and I could focus on SoC entirely. During the whole time, I communicated with some of Tor's other SoC students, helping, encouraging and sharing some great laughs with each other. I feel that the community aspect of GSoC worked out much better this year.

During the summer, it became apparent that following through with the original plan of using the C++ libtorrent implementation by rasterbar would be difficult, due to various platform-independence issues and a huge resulting binary. Especially the last point made it clear that we wouldn't be able to use that for our netinstaller, one of the most important reasons to develop Thandy. Eventually, I settled on the original BitTorrent implementation, patched by Debian to work around some issues with newer versions of Python.

It was great to see that this year, all my code has been merged into the Thandy source. I think my experience from last year saved me from making the same mistakes again, by focusing on small parts that work instead of re-designing major aspects of the software.

Overall, I'm very happy with how my Summer of Code turned out to be, and I hope to participate again (either as student or even mentor)!

EFF and Tor in Google Summer of Code 2009

karsten — Fri, 20 Mar 2009 19:30:25 -0700

Great news! We have been accepted as a mentoring organization for Google Summer of Code 2009 together with The Electronic Frontier Foundation. Yay!

This will be our third Google Summer of Code after 2007 and 2008. In our first year we had four students working on making relays work better (and not crash) on Windows, on a library and tool to try alternative path selection algorithms, on a fuzzing library to look for parsing problems, and on scalability and privacy for hidden services. In our second year we had seven students. One of our successful students of the 2008 program wrote a nice blog post reviewing how GSoC went for him, for the other students, and for the project in general.

We have made resolutions for our third GSoC participation to make it even more successful than in the past years. We have set ourselves the limit of accepting no more than 4 students (plus up to 2 students mentored by EFF). Rather than being persuaded by all those great applications, we want to focus on the most promising projects and students. We plan to assign up to 3 mentors to each student to provide optimal support. We will try harder to encourage students to interact with the community and become a part of it. It may be challenging to discuss project ideas on a mailing list or in a chat room with dozens or hundreds of unknown people listening. But communication is an important part of the GSoC experience (if not the most important).

It might seem that we have high expectations about our students (actually we do!), but we also have a lot to offer. Our students will work on one of the largest deployed anonymity systems with a few hundred thousand users. We encourage GSoC students to stick to The Tor Project after summer and become part of the team; did you know that two of our Core people are former GSoC students? Our mentors are cryptographers, researchers, and/or software developers who have published numerous papers on distinguished security and privacy conferences all over the world. We have an awesome community with a lot of people who will be interested in the students' projects and their progress. Ah, and finally Google gratefully pays $4.5K to each successful GSoC student. Isn't that a fine alternative to $your_last_summer_job?

Did we get you interested? These are your next steps: Look at Google's FAQ whether you are eligible to participate. Have a look at our ideas lists (one for The Tor Project, one for the EFF's Switzerland tool). Put some thoughts on the listed ideas, or make up your own. Talk to us. No, really, this step is important: Talk to us! Come to #tor on irc.oftc.net or send us an email and let us know about your project idea. Write down your application using our template and send it in until April 3, 2009, 19:00 UTC. Stick around for any questions we might have to you. We are looking forward to reading your application, erm, to talking to you and discussing your project idea!

Google Summer of Code 2008 review

Sebastian — Mon, 09 Mar 2009 04:48:11 -0700

As we started preparing to apply for the Google Summer of Code 2009, we realized that we haven't reported how last year's Summer of Code went for us.

Tor's 2008 Google Summer of Code was a victim of Tor's increasing growth! We've got a lot more people involved now, and we have a lot more projects we want to tackle. But that also means we need to work harder at coordinating everything, and that's not as smooth as we'd hoped.

Tor had the luxury to receive seven slots for students. GSoC 2008 overall, was a success; as the students and projects contributed a lot to the Tor project. Also, here I am, a former GSoC student writing a blog post for the project.

Below is an overview over the GSoC 2008 projects and a summary of their results.

Domenik Bork: Configuration of Hidden Services with User Authorization in Vidalia
Support for creating hidden services using a GUI was lacking from Vidalia, making it very hard for Vidalia users to correctly set up their own. It was necessary to change Tor's configuration file manually, and many users are overwhelmed by the task of even locating that file. Domenik created a new tab in the Vidalia settings to allow the creation and configuration of hidden services, and worked on the necessary UI changes to allow the creation of the new hidden services with user authorization (currently available only in alpha versions of Tor). As soon as the next stable Tor version lands, users will be able to set up their hidden services with user authorization with more convenience.

Fallon Chen: Improving Tor Path Selection
When Tor decides on a path for a new circuit, many factors come into play. Currently, latency does not factor into the equation a whole lot, but it is really important for the user experience. On the other hand, always choosing the fastest connection will harm anonymity. Fallon tried to find a model to reduce circuit establishment times, without affecting anonymity too much. During her project, she gathered a lot of data that helps shaping the current development of Tor. She discovered that a Pareto distribution is a good model for Tor circuit establishing times. Unfortunately, she had to quit working before much actual code could be produced; nevertheless, her research is the basis for the current development of Tor's path selection. She was also involved in the writing of proposal 151, which Mike Perry is currently implementing. The goal of the proposal is to allow Tor clients to automatically detect useful values for configuration options depending on the user's environment (mobile satellite connection vs. broadband, or changing conditions).

Aleksei Gorny: Tor Exit Scanner Improvements
To prevent exit nodes from maliciously (or unintentionally) interfering with traffic passed through them, we have SoaT (Snakes on a Tor) to automatically detect nodes that misbehave. It was Aleksei's task to extend SoaT to make it more useful, especially to make it execute tests automatically, so that eventually directory authorities can use its input to flag bad nodes appropriately. The result of the project is the foundation of our ongoing work there, and a functional version exists to be evaluated now.

Sebastian Hahn: Extending PuppeTor
During my project, I worked on extending PuppeTor to allow forming virtual networks that can run centrally coordinated tests (similar to buildbot, except with a test suite). I produced a version that allows basic tests to be run, but the API became incompatible with the pre-existing PuppeTor. Also, in its state immediately after the summer of code, writing tests was rather more difficult than with the original version. After the summer, we decided that there should be no two different versions of PuppeTor, and I continue to do work on top of the version produced during the summer. It will eventually be deployed as the new PuppeTor and used for regression testing as well as performance/anonymity evaluations. One of the specific challenges that both student and mentor learned from here was a lack of communication about what the result should look like. I ended up developing something that wasn't what some of the developers had originally envisioned, which caused quite a bit of extra work.

Simon Johansson: A Translation wiki for our website
The Tor Project has been working over the past year to set up web-based tools to help volunteers translate our applications into other languages. We finally hit upon Pootle, and we have a fine web-based translation engine in place for Vidalia, Torbutton, and Torcheck. However, Pootle only translates strings that are in the "po" format, and our website uses wml files. Simon's project was to come up with a way to convert our wml files into po strings and back, so they could be handled by Pootle. Unfortunately, communication between Simon and his mentor didn't happen often enough, and in the end we got very little useful work out of this project. Nevertheless, many components of the Tor project can now be translated by using Pootle.

Camilo Viecco: Providing Blossom functionality to Vidalia
Blossom allows to choose that the user prefers to exit from a specific country. The same can be achieved by manually changing Tor's configuration file, but Vidalia, our Tor configuration tool, did not have a way to easily let users select a country to exit from. Camilo's task was to integrate this functionality into Vidalia, so that mainstream users can benefit without needing to figure out how to use Blossom. During his work, a completely functional branch was created that can be used to achieve the goals. Due to some changes in the Vidalia UI, his work couldn't be merged into mainline Vidalia completely. Instead, his back-end changes will be cherry-picked into mainline as soon as the UI work is finished.

Christian Wilms: Performance Enhancing Measures for Tor Hidden Services
Hidden services are a very useful feature in Tor that allows anyone to host a location-hidden service. Unfortunately, accessing them is often a rather slow process. Based on a paper that he and Karsten Loesing had written, Christian started out by measuring connection times to hidden services under various conditions. He found and fixed quite a few bugs in the process. During the remainder of the summer, Christian worked on a larger-scale change to reduce connection times, and his work could be used as a basis for a later patch to fix the remaining issues.

The summary is that Tor took too many students last summer; as overall we were about 50% successful with project completion. Better mentoring, including being stricter with students and weekly progress reports, could have been very helpful for our students. I experienced it myself: towards the end of the summer I still had a lot of stuff on my plate that I needed to rush through. By having fewer students and better communication between mentors and students, and involving students more with the Tor project as a whole, we should be able to get even more out of the next summer, if Google invites us to participate again. Maybe the next GSoC blog post will be written by a GSoC 2009 student?

As a last note, next time around we plan to work more closely with the EFF (our sponsor organization for GSoC). In particular, we'd like to accept a few students to work with Peter Eckersley on Switzerland and other projects organized by EFF's engineers.