Name: Cristóbal Leiva < > | Blog | Github
Project: Relay Web Dashboard
Mentor: Damian Johnson

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

Localhost daemon

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)

The client will use WebSockets for stablishing long-lived connections with the daemon to fetch relay information, such as current bandwidth, logs, etc. WebSockets can be defined in Javascript and work with popular frameworks such as jQuery or AngularJS (one of my mentors suggested me to go with the latter). I don't have experience using AngularJS but I've been researching and I've found that it is a better option to use when developing web applications (rather than websites) because of its MVC oriented (among other features).

In addition, the client will use charting libraries to display information in a clean and nice way.

Relay information

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

Future work

By having two lines of work, back-end (daemon) and front-end (client), it would be more easy to attract future collaborators into the project. Front-end developers could collaborate on improving the client and back-end developers could collaborate on improving the daemon or in developing new client implementations for people that is not comfortable with Javascript-based solutions. Another good feature of having separated lines of work is that relay operators could choose to use the daemon but implement their own custom clients.

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:

  • 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.

  • 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!

About my free software development experience, I can say I've contributed with stem by solving a couple of issues (#14944 and #8250). I've also contributed with gh3 which is a Javascript API wrapper for Github API. Another contribution I can quote is a RCE-LFI bug (MDL-33791, CVE-2012-5479) that I found on Moodle 2.1-2.3, back in 2012.

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?

Yes! The project will have two clear lines of work. The daemon (back-end) and the client (front-end). Maintenance would be needed for both of them, as front-end libraries would certainly need updating (or replaced by new libraries) and/or new Tor capabilities could appear in the future. There is also the possibility of extending this project by adding new features to it (new charts/statistics/UI), and developing new clients (with no-javascript)

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 My IRC nickname is clv and I check @otfc at least once a day. My current time zone is UTC-3.

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.

Finally, a fun fact about myself is that I have a twin brother (ilv), who is already contributing to the Tor Project (at GetTor)

Let us know how you heard about Tor Summer of Privacy.

I heard of Tor Summer of Privacy from ilv :)