Team
Network Health Team
About us
Welcome to the Network Health page! There are several people in the Tor community taking care of the network's health.
The five areas that we focus on are:
- Track community standards about what makes a good relay
- Publish up-to-date expectations for relay operators
- Set best practices for how to set relay families
- Detect and resolve bad relays
- Exitmap, sybil detection, hsdir traps, etc.
- Anomaly analysis / network health engineer [with network team]
- Establish baselines of expected network behavior
- Look for and resolve denial of service issues
- Track connectivity issues between relays
- Look for relays hitting resource limits
- Make sure usage/growth stats are collected and accurate
- Track network performance, relay diversity by various metrics
- Count users [with network team]
- Monitor bridge growth and usage [with censorship team]
- Relay advocacy [with community team]
- Maintain docs for setting up and running relays and bridges
- Grow a cohesive community of relay operators so they have peers
- Keep relays on the right tor versions
- Relaunch a gamification / badge system for lauding good relay progress
- Strengthen relationships with non-profit orgs that run relays
- Help companies that want to offset their tor network load
- Maintain the components of the network
- Maintain directory authority relationships
- Keep bandwidth authorities working (including setting the right balance between speed and location diversity)
- Have enough tor browser default bridges, and keep them running smoothly [with censorship team]
- Update the fallbackdirs list
Communication Channels
Just go to #tor-dev, and somebody from the team might either be around or appear later and get back to you.
We use IRC for our meetings, we meet on the OFTC network.
Team meeting | UTC | Location |
---|---|---|
Primary team meeting | Monday 16:00 | #tor-meeting |
The Network Health's asynchronous medium of communication are the network-health@, tor-relays@, and tor-dev@ mailing lists, depending on which is more applicable. These lists are public in the sense that anyone can subscribe, send emails, and read archives. Feel free to subscribe and just listen if you want, and feel free to post if you have a question that you think is on topic.
For metrics related topic our asynchronous medium of communication is the network-health@ mailing list. This list is public in the sense that anyone can subscribe and read archives. But it's moderated on the first post, meaning that your first post will be reviewed to make sure it's not spam and on topic and all further posts will go directly to the list. Feel free to subscribe and just listen if you want, and feel free to post if you have a question that you think is on topic.
General Priorities
- Detect and resolve bad relays
- Exitmap, sybil detection, hsdir traps, etc.
- Anomaly analysis / network health engineer [with network team]
- Establish baselines of expected network behavior
- Monitor network disruption or problems
- Relay advocacy [with community team]
- Strengthen relationships with non-profit orgs that run relays
- Maintain docs for setting up and running relays and bridges
- Make sure usage/growth stats are collected and accurate
- Track network performance, relay diversity by various metrics
- Maintain the components of the network to keep it healthy
- Keep bandwidth authorities working (including setting the right balance between speed and location diversity)
PRIORITIES FOR 2024
- Network anomaly detection
- Bad-relay tooling improvements
- Deploy a data store for metrics services
- Map out possible plans for quantifying and improving our trust in relays/operators
- Deploy a data API for metrics services
- Establish community-driven behavioral agreements and consequences for relay operators
- Support OTF fellow on Relay Operators Community Health Research
- Evaluate and implement solutions to relay attacks
- Run bad-relay detection scripts
- Support for researchers for network experiments
- Handle EOL relays
- Improve monitoring and alerting for metrics service
- Rebuild Tor metrics website
- Relay-to-Relay connectivity tracking
- Work on onbasca (refactoring and redesign)
- Discuss possible list of metrics we want to have from arti-based relays with the arti team.
- Surprise 'anomaly analysis' on the network as needed
- Evaluate metrics for relays and VPN client and their possible privacy issues/risks
- Network diversity metrics tracking and build plan on how to improve upon that
Active Sponsor Projects
- Sponsor 112 - Combating Malicious Relays
Network Health
We are concerned with the well-being of the Tor network and its particular relays. There are currently five main areas of work involved in that effort, guided by processes and policies which we have developed over time:
- Bad relay work
- Relay health work
- Tor network health work
- Network data analysis work
- Network experiments
To work in those areas a lot of tools got developed over time both by Tor Project staff and external contributors and volunteers. Some of those tools are currently in use while others are obsolete or unused in our day-to-day work. For an overview see:
Metrics
We provide a set of monitoring and observability software tools and services for the public Tor network.
General Guides
Products
Product is a codebase of software maintained by the Network Health team. Not all metrics related products are mentioned in this section. Instead, we list some long-term products here that are or will be released in a way that a third party can decide to run a mirror of this type of service.
- CollecTor is the friendly data collecting service
- ExoneraTor helps to find out whether an IP address was used as a Tor relay
- Metrics Website is the primary place to learn interesting facts about the Tor network
- metrics-lib is a Java library that fetches and parses Tor descriptors.
- Onionoo is a web-based protocol to learn about currently running Tor relays and bridges
- Exit Scanner/TorDNSEL/Tor Check
- OnionPerf
- Metrics Timeline
Inventory
Metrics products are hosted on tpa maintained hardware, except for some onionperf installations which are administered via ansible.
We maintain a list of metrics VMs and the services they host.
Services Ops
We maintain a list of services and their operational documentation.