Help translate the
documentation into other
languages. See the translation
guidelines if you want to help out. We especially need Arabic or
Farsi translations, for the many Tor users in censored areas.

Below are a list of Tor related projects we're developing and/or
maintaining. Most discussions happen on IRC so if you're interested in any
of these (or you have a project idea of your own), then please join us in #tor-dev. Don't be shy
to ask questions, and don't hesitate to ask even if the main contributors
aren't active at that moment.

Central project, providing the core software for using and participating in
the Tor network. Numerous people contribute to the project to varying
extents, but the chief architects are Nick Mathewson and Roger Dingledine.

Tor Browser is an easy-to-use, portable package of Tor, HTTPS-Everywhere,
NoScript, TorLauncher, Torbutton, and a Firefox fork, all preconfigured
to work together out of
the box. The modified copy of Firefox aims to resolve the
privacy and security issues in mainline version.

Nyx (previously arm) is a terminal status monitor for Tor
intended for command-line aficionados, ssh connections, and anyone with a
tty terminal. This works much like top does for system usage, providing
real time statistics for bandwidth, resource usage, connections, and quite
a bit more.

The Amnesic Incognito Live System is a live CD/USB distribution
preconfigured so that everything is safely routed through Tor and leaves no
trace on the local system. This is a merger of the Amnesia and Incognito projects,
and still under very active development.

Shadow is a discrete-event network simulator that runs the real
Tor software as a plug-in. Shadow is open-source software that enables
accurate, efficient, controlled, and repeatable Tor experimentation.
For another simulator, see ExperimenTor.

Relay Search is a web application to discover Tor relays and bridges. It
provides useful information on how relays are configured along with graphics
about their past usage.

This is the spiritual successor to TorStatus, the original
codebase for which was written in PHP, and rewritten by students from
Wesleyan as Django. If you dig into this space then also check out Globe, another similar site that's since
been discontinued.

DocTor is a notification service that monitors newly published descriptor
information for issues. This is primarily a service to help the tor
directory authority operators, but it also checks for a handful of other
issues like sybil attacks.

The Tor Path Simulator (TorPS) is a tool for efficiently simulating
path selection in Tor. It chooses circuits and assigns user streams to
those circuits in the same way that Tor does. TorPS is fast enough to
perform thousands of simulations over periods of months.

Library and collection of services for actively monitoring the Tor network.
These include the Bandwidth Scanners (measuring throughput of relays) and
SoaT (scans for malicious or misconfigured exit nodes). SoaT was last
actively developed in the Summer of 2010, and the Bandwidth Scanners a few
months later. Both have been under active use since then, but development
has stopped.

You may find some of these projects to be good ideas for Google Summer of Code or the Tor Summer of Privacy. We have labelled each idea with
which of our core developers would be
good mentors. If one or more of these ideas looks promising to you, please
contact us to discuss your plans rather
than sending blind applications. You may also want to propose your own
project idea — which often results in the best applications.

Tor Browser is a privacy-preserving web browser used by millions of
users around the world. We are looking for a programmer fluent in JS
and C++ to implement new features to work closely with the Tor Browser
team.

Image files, especially photos taken by smartphones,
often carry hidden privacy-violating metadata, typically specified by
the EXIF format. Such metadata can include the user's geolocation and
various unique identifiers. In order to protect the user's identity,
we would like the intern to modify the file-upload feature in Tor
Browser such that metadata in image files is automatically removed
before the image is uploaded to a server. Ideally, the summer intern would
implement this feature for both desktop and mobile Tor Browser. If
there is time, we can envision sanitizing other kinds of uploaded
files, including movies, audio, PDFs and Office documents.

Download hidden service descriptors. Unlike relays, the descriptors for hidden services are only available over the ORPort. Once ticket 17945 is merged v3 HS descriptor downloads will require a multi-hop circuit. This requires an understanding of Tor's hidden service specifications, particularly the HSDir hash ring.

Authenticate our ORPort connection, checking that ORPorts we connect to have the right key fingerprint.

And more! Applicants are encouraged to get a decent understanding of Tor's ORPort protocol and come up with ideas of their own for neat directions that we can take this. To be clear this is not a particularly easy beginner project as it involves expanding stem.client to support more of Tor's ORPort protocol and crypto.

As part of applying for this project please get your hands wet with the codebase by contributing some patches for Stem!

Fuzzing coverage of Tor
Likely Mentors: Nick (nickm), ahf, teor

Starting in 0.3.0.x, Tor supports a few fuzzing systems to check our
code for bugs. But as of now, we only support a few possible entry
points to Tor. It would be great to add fuzzing support for more of
our codebase -- ideally to include our whole network-facing interface.
That way, we could find more bugs in our code faster, and fix them
before they can get out of hand.

This won't be so easy, however: to fuzz effectively, we need to
refactor or mock the target function so that it doesn't change any
global state, or verify any signatures, or take too long to run. With
lots of our network code, that's not so easy. Make sure you
understand how our mocking system works, and what the challenges are,
before you apply for this one.

Relay crypto parallelism
Likely Mentors: Isis, Nick (nickm)

Tor relays spend a lot of time encrypting and decrypting relay
traffic, doing SHA1 and AES-CTR operations. But right now, all of
this is done in the main thread! It would be cool to split this
across multiple cores instead.

This won't be so easy though. The code today is written to expect
immediate results from its encryption operations, so you would need to
do some pretty tricky refactoring in order get performance and
correctness here. Make sure you understand how circuit crypto is
invoked today, and what the challenges are, before you apply for this
one.

There are some places in Tor where we count things (like distinct IPs)
to later report anonymized statistics. But if the local Tor instance
were compromised, this data would be exposed. There are statistical
methods which insteasd allow us to record this data in a way that's
already anonymous, before we ever summarize it. Interested?

In proposal 229, we describe a bunch of additional SOCKS extensions
that Tor-aware applications could use to get more fine-grained control
over how Tor handles their streams. It would be cool to implement
this! If there's time remaining, you might want to add support to one
or more applications. Or maybe to torsocks?

Onion services, onion service clients, onion service directories,
and introduction points all need to do a few public-key operations as
they operate. But right now, these operations are all done on the
main thread. It would be good to have these run across multiple cores.

This could probably be done in a way similar to how we currently handle
circuit extension handshakes in onion.c and cpuworker.c, but we'd need
to extend the state machine for onion services to add an additional
state. It could help onion services operate much more efficiently.

Support all kinds of DNS in Tor
Likely Mentors: Nick (nickm), George (asn)

Right now Tor can query for the kind of DNS information you'd find in
A records, AAAA records, and PTR records. It would be neat to be able
to support more general DNS queries to allow things like MX loopups,
DNSSEC lookups, and so on. We have a design proposal (number 219) for
this, but it might need some clean-up.

Tor works over IPv6, but require some manual configuration.
Clients and relays could automatically detect IPv6 availability,
and configure themselves appropriately. Implementing a
"happy eyeballs"-like algorithm is a challenge in an anonymity
network: are you up for it?

Ahmia is a working search engine that indexes, searches, and catalogs
content published on Tor Onion Services. Furthermore, it is an environment
to share meaningful insights, statistics, insights, and news about the Tor
network itself. In this context, there is a lot of work to do.

The Ahmia web service is written using the Django web framework. As a
result, the server-side language is Python. On the client-side, most of the
pages are plain HTML. There are some pages that require JavaScript, but the
search itself works without client-side JavaScript.

Bring up new ideas!
Don't like any of these? Look at the Tor development
roadmap for more ideas, or just try out Tor and Tor Browser,
and find out what you think needs fixing.
Some of the current proposals
might also be short on developers.