Using this award, we are targeting six objectives and associated outcomes:
- Strengthen our data collection infrastructure by building and distributing the primary data collection service (Tor CollecTor) as a "kit" of useful software components and user-friendly tutorials. Currently, CollecTor cannot preserve measurements in the case of a service malfunction on any instance: a fragile and limited set-up. Increasing the number of instances and operators will create a more reliable system and expand our observational capacity.
- Strengthen our performance measurement infrastructure. We want to make it easy for third parties to contribute to and benefit from Tor network observations and measurements by building and providing an observation "kit" that contains: Software (Tor DescripTor) that helps use and analyze CollecTor outputs, plus user-friendly tutorials on using DescripTor to analyze large amounts of network data.
- Strengthen our network status monitoring infrastructure. We want to encourage third-party operators to run Tor network monitoring services (Tor Onionoo) by building and providing a service implementation kit that contains related software tools and tutorials. We would also resolve some of the most pressing usability issues of Tor's Atlas network status website, which publishes network monitoring results.
- Improve the security of metrics reported by individual Tor network relays by reducing the amount of sensitive, potentially personally identifying, data we store for measurement and further obfuscating that data in the reporting process.
- Improve the accuracy and depth of performance measurements by developing better user models and by using an improved traffic generator.
- Make it easier for people to find, compare, and interpret Tor usage and performance metrics by redesigning the primary Tor Metrics website, reflecting Mozilla's 8th Principle. This includes adding metrics, such as Tor Browser download and update statistics requested by the community.
Additionally, to make it easier for other organizations to run Tor network-observation software or contribute to our code base, we plan, as time permits, to perform the following for all objectives:
A. Increase software stability, scalability, security, and maintainability by improving code quality, testability, and testing practices. A. Reduce software maintenance overhead with better developer documentation. A. Help non-developer operators to run metrics software by releasing it as executable components. A. Enrich software usability by writing configuration and user guides and rewriting existing end-user documentation for non-technical audiences.
1.1. Define a release process for CollecTor and put out one or more releases.
1.2. Provide user-friendly documentation that empower users to independently operate CollecTor instances.
1.3. Enable CollecTor to synchronize Tor network data from other CollecTor instances.
1.4. Set up a second CollecTor instance and enable synchronization with the first CollecTor instance.
2.1. Make a wider audience aware of the Tor descriptor parsing library metrics-lib/DescripTor by writing a blog post about it that explains how to use it.
2.2. Put out one or more metrics-lib/DescripTor releases.
2.3. Write user-friendly tutorials for metrics-lib/DescripTor that empower users to independently analyze large amounts of network data.
- Onionoo and Atlas
3.1. Define a release process for Onionoo and put out one or more releases.
3.2. Provide user-friendly documentation that empowers users to independently operate Onionoo instances.
3.3. Improve all usability issues of Atlas that are classified as High priority or above in the issue tracker as long as they are within scope and reported at least six months before the end of the award.
- Tor daemon
4.1. Perform an analysis on reducing the amount of sensitive, potentially personally identifying data stored in memory of Tor relays and bridges or reported to the directory authorities.
4.2. Reduce the amount of sensitive, potentially personally identifying data stored in memory of Tor relays and bridges by implementing at least one suggestion from the earlier analysis document.
4.3. Obfuscate data that gets reported by Tor relays and bridges to the directory authorities by implementing at least one suggestion from the earlier analysis document.
5.1. Replace all existing Torperf instances gathering current Tor network performance measurements with OnionPerf instances.
5.2. Develop and deploy at least one more user model in addition to the current model.
6.1. Conduct a usability analysis of the current Tor Metrics website to identify the most pressing usability issues.
6.2. Improve usability of the most pressing issues identified in the earlier usability analysis as long as they are within scope to make it easier for users to find, compare, and interpret Tor usage and performance metrics.
6.3. Add a visualization of Tor Browser downloads to Metrics.
6.4. Add at least one visualization to Metrics that is requested by the community.