What project would you like to work on?
I would like to work on the Relay Web Status Dashboard project. Currently, relay operators have a good option for monitoring the status of their relays with nyx, which not only provides relay statistics, but also advanced functionalities such as an interactive interpretor for handling Tor commands, access to Tor configuration, etc.
The goal of this project is to develop a web based dashboard specifically for monitoring purposes, taking special care of following a read-only approach (i.e. it won't be possible to do anything to the relay) and a strong focus on security, as we must ensure that no sensitive information would be exposed by the application.
The project will include two parts: a localhost daemon and an AJAX site (a client), thus separating the relay statistics delivery (daemon) from the presentation (AJAX site).
Figure 1: Relay Web Dashboard Diagram
The localhost daemon will retrieve information from the relay with the help of stem, and will deliver such information to the client when asked. If necessary, the daemon could process this information and generate useful statistics before delivering it.
It is important to notice that stem, as a controller library for Tor, it is based on Tor's control protocol. This protocol is used to communicate with a running Tor process and interact with it in two ways: synchronous (request-reply) and asynchronous (suscribe to events), so we should think of a way to process both kind of requests. A good example of asynchronous events are Bandwidth events (BW). When suscribed to this events, Tor will reply every second with the number of bytes downloaded and uploaded.
As the client will be an AJAX site, the natural choice for implementing this daemon would be a web app. The web app will handle GET requests from the client and will reply with JSON-encoded data. My first approach was to use a lightweight and simple web framework, and I thought on using Flask. Nevertheless, it turns out Flask is WSGI compliant, which is a synchronous and blocking API. This means Flask can't handle asynchronous tasks and it will block others requests when working on long-lived tasks.
My second (and proposed) approach is to use Tornado, which is, by design, asynchronous. Tornado supports WebSockets, which is a protocol that enables long-lived connections between web browsers and web servers. In my opinion, this would be the best way to treat asynchronous long-lived requests from the client, reducing overhead (compared to making multiple HTTP requests every second). Thus, we could support (very naturally) a long-lived connection between the client and the daemon to send, for example, bandwidth information every second.
One of my mentors suggested me to use Cyclone instead of Tornado because it former implements the Tornado API as a Twisted protocol.
AJAX site (client)
In addition, the client will use charting libraries to display information in a clean and nice way.
A very important matter in this project is what relay information should and what information should not be available on the daemon. If we take a look at nyx, it currently shows information about:
- Bandwidth: information about current/average/total downloaded and uploaded bytes. Bandwidth rate, burst, observed, measured, etc.
- Logs: log information about several Tor events: DEBUG, INFO, NOTICE WARN, ERR, BW, ADDRMAP, etc. It also shows log information about nyx events.
- System resources: system information such as CPU usage, memory usage, process id (pid), uptime, etc.
- Connections: a list of current incoming/outgoing/control connections.
- Configuration/General Information: relay information such as fingerprint, flags, exit policy, nickname, etc. and
The information that will be available from the daemon is definitely a matter of discussion. The first part of the project (midterm evaluation) should be based on what nyx already has. The second part of the project should be to add new features (after a proper discussion) if neccesary.
WebSockets support traffic encryption by using TLS/SSL, so we would be able to set up self-signed certificates and fetch encrypted information back from the daemon. It also supports origin-based security, which means we will be able to run the AJAX client on a different host and keep things safe. A good analysis of WebSockets security model can be found in the following link.
Figure 2: HTTP and WebSockets
The following is an estimated timeline of the tasks to be accomplished during Tor Summer of Privacy. As I mentioned earlier, a first task would be to work on what relay information should and what information should not be available from the daemon, since I don't have enough experience on running Tor relays to decide that on myself.
- July 6 - August 13
In this period I will work on porting of all the statistics that are already coded on nyx to the Relay Web Dashboard. This will imply defining all the proper WebSockets, both on the back-end (daemon) and the front-end (client). All of the code should be properly documented and logging should be a must.
In addition, I would like to start a discussion with Tor relay operators to get feedback and ideas for the project (tor-dev, tor-relays).
- August 14
Midterm evaluation. A first working version of the Relay Web Dashboard should be delivered at this time, ideally based on what nyx already has.
- August 15 - October 5
Implementation of further statistics that were not included in nyx but are going to be included in Relay Web Dashboard. Implementation of SSL/TLS support with Secure WebSockets (WSS). Implementation of integration and unit testing.
- October 6
Pencils down. A second version of the Relay Web Dashboard should be delivered at this time. Advanced features, secure connection and testing should be the milestones for this date.
- October 6 - October 12
Finish any unfinished work and code review.
- October 13
End of term
Point us to a code sample
You can take a look at a code sample in my github repo for this proposal. There, you will find a working prototype for what I described earlier in this document. More specifically, there some important files:
- daemon.py: a webserver that listens on both /bandwidth and /logs URIs to receive incoming websockets connections. When a connection is received, it is registered in the application and we send it information through previously registered listeners (BW event and LogEvent). This application runs on port 8000.
- client.py: a simple application that starts a webserver with a single file: index.html. This application runs on port 8001.
- dashboard.js: a jQuery file that connects to port 8000 and requests for two websockets: /bandwidth and /logs. When receiving the information, it does some processing to graph the bandwidth and show the logs.
The following is a screenshot of the working prototype. It has two charts (read bytes on the left, and written bytes on the right). It also has a box where logs are shown. (Tor's NOTICE logs).
Why do you want to work with The Tor Project? Tell us about your experiences in free software development environments.
Because I do believe in the right to privacy and free speech, and the Tor Project brings together this human endeavour of fighting for people's right with such a technical activity as it's free software development. I can't think of a better place to focus my efforts and motivation!
Will you be working full-time on the project for the summer, or will you have other commitments too?
June-August is winter back here in Chile, so I won't be in vacations as I would be in summer. My classes period ends in the first week of July, and should begin again in the last week of August, so July-August would definitely be a full-time period for this project. On the other hand, May-June would be a classes-and-SoP period. I'm currently taking just 4 courses given that I planned my classes considering I was going to apply for GSoC in the first place. But Tor wasn't selected at GSoC and I do have free time! I have all of my mornings free, and one day off (wednesday). This means my classes-and-SoP period would be roughly half-time SoP and half-time classes. To compensate this situation, I'm intending to begin early in the process (as depicted in my timeline) since I have a half-time availability right now.
I must say I do have experience with working and studying at the same time. I also have a close reference on that, because my brother (ilv) did the same thing on last year's GSoC (working on the GetTor project).
Will your project need more work and/or maintenance after the summer ends? What are the chances you will stick around and help out with that and other related projects?
I would be more than happy to keep maintaining this project, as I find it very interesting and challenging. I also think that collaborating with this project will involve collaborating with other projects, such as stem or nyx.
What is your ideal approach to keeping everybody informed of your progress, problems, and questions over the course of the project?
My ideal approach would be sending bi-weekly reports to the tor-dev mailing list (as suggested in this timeline). I'll also be on IRC in case of anyone would want to ask/suggest me anything. Also, I would be in touch with atagar by email (or IRC). I've already been mailing him (when contributing to stem) and he is very responsive, so that encourages me to be responsive as well :)
What school are you attending? What year are you, and what's your major/degree/focus? If you're part of a research group, which one?
I'm currently pursuing a Bachelor of Science in Computer Science at Universidad de Santiago de Chile. I'm in fourth year and this year I'm taking a series of courses on Cryptography (modern cryptography, elliptic curve cryptography).
How can we contact you to ask you further questions?
You can write me to
Is there anything else that we should know that will make us like your project more?
I've been a computing enthusiast since forever! I started using Linux when I was 16 or so, and I entered in the world of web development and later web defacement (kids stuff)... I was so motivated with it that I almost went to jail, but I was lucky to be a minor and charges were dropped. After that, I turned into the light side of the force! I went to the International Olympiads in Informatics '07, I participated in several ocassions at the ACM-ICPC South America Regionals (chilean site), I was awarded with Google Latin America Scholarship back in 2012 and attended to Google Scholars' Retreat at New York in 2013.
More recently, I did an internship at the National Laboratory for High Performance Computing, where I worked on a web dashboard (written in Django) to interact with slurm. After that, I was awarded with a scholarship for attending to the School on HPC at the Latin America HPC Conference. I'm also a volunteer at the technical committee of the Chilean Olympiads in Informatics since 2013, where I help configuring and running CMS.
Let us know how you heard about Tor Summer of Privacy.
I heard of Tor Summer of Privacy from ilv :)