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

Let us know if you have a project you would like to work on, or check
our proposals and technical documents for various
ideas.

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?

Design and implement an extension for Tor Browser that can be used to gather
end-user UI/UX feedback on an opt-in basis. While the design and
implementation is left as an exercise for the applicant (and also serves as
the qualification task), examples of the information we are looking to gather
can include troubleshooting network connectivity issues, testing the various
pluggable transports, or gathering information about the network of the users.

Please propose the extension design in a way that the information is strictly
on an opt-in basis and scrubs any information that can be used to identify a
user, and also come up with a way to send the gathered information to a
central server, whether to an onion address (if the user has Tor running), or
otherwise. To start with, we are looking to gather only text as part of the
feedback process.

Currently Tor Browser disables the Crash Reporter. We would like to
build it reproducible, enable it, and configure it to report crashes
containing non-detailed and impersonal information to Tor, on a .onion
submission platform that would allow us to view and explore the
crashes.

The project will entail enabling the Crash Report on Tor Browser and
creating a backend to receive reports from it. Once created, the crash
reporter data will be analyzed and modified to fit Tor's requirements
for personal data collection. As time permits, we will update the
build system to ensure the crash reporter is built reproducibly and
add data analysis tools for the crash report database to visualize top
crashers and similar statistics.

This project will enable and take advantage of HTTP/2, the Alt-Srv
header, and tor's new single hop .onion mode to enable websites to
transparently move their traffic to a .onion address. In addition to
improvements in security, we will benchmark page load and paint times
under normal HTTP/1.1, HTTP/2, and when taking advantage of features
such as Server Push.

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.

There are several possible directions for this project, including...

Automate blacklisting (very important)

Fetch a list of child abuse media sites

Remove these sites from the search results

Add onion services function (very important)

You can add onions using HTML form

Call the crawler immidiately when a new site is added

Elasticsearch

Must be updated to 5.X.X sooner or later

Adjust the settings

Automatically remove data older than, for instance, 90 days

Maintainance

Update all software dependencies

Automate crash recovery for Tor, Elasticsearch and crawler

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.