Opened 2 years ago

Last modified 7 months ago

#26124 new enhancement

Bring​ back Tor​ Weather

Reported by: nusenu Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics Version:
Severity: Normal Keywords: network-health
Cc: phoul, gaba Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


TL;DR: I believe Tor Weather is the most efficient way to achieve and maintain a healthy Tor network on the long run.

This is an item on the metrics team road map ("Q4 2018 or later") but maybe the new relay advocate (Colin) can help with this?

Tor Weather has been discontinued on 2016-04-04,
see Karsten's email for the reasoning behind it:
but as he says "Tor Weather is still a good idea, it just needs somebody to implement it."

How Tor Weather looked like:


If a relay disappears today, it is unlikely that anyone will notice or even send an email to the operator unless it is a big one.

Relay operators and the entire tor network would benefit from a Tor Weather service because it notifies relay operators when the state of their relays changed (and more). This will increase the likelihood that relay operators notice problems and actually mitigate the problem otherwise there is no "user feedback" since tor can cope with disappearing relays quite well.
It also

  • shows the relay operator that someone actually cares if their relays go down or become outdated or have another problem
  • gives the operator relay best-practices information.

Expected Effects

If enough operators subscribe to such a service:

  • relays might become more long lived / the churn rate might decrease
  • the fraction of relays running outdated tor versions might decrease
  • the fraction of exits with broken DNS might decrease

It also has the benefit of being able to contact relay operators

  • completely automatically
  • even if they choose to not set a public ContactInfo string in their torrc files.

Ideas for Notification Types
(sorted by importance)

Support subscribing via single relay FP or MyFamily groups (should not need any subscription change if a relay gets added to the family).

[ ] Email me when my node is down
How long before we send a notification?
[ ] email me when my relay is affected by a security vulnerability
[ ] email me when my relay runs an end-of-life version of tor

[ ] email me when my relay runs an outdated tor version (note: this should depend on the related onionoo bugs to avoid emailing alpha relay people)

[ ] email me when my exit relay fails to resolve hostnames (DNS failure)

[ ] email me when my relay looses the [ ] stable, [ ] guard, [ ] exit flag

[ ] email me when my MyFamily configuration is broken (meaning: non-mutual config detected or relay with same contactInfo but no MyFamily)
[ ] email me when you detect issues with my relay
[ ] email me with suggestions for configuration improvements for my relay (only once per improvement)

[ ] email me when my relay is on the top [ ] 20 [ ] 50 [ ] 100 relays list

[ ] email me with monthly/quarterly status information that includes information like what my position in the overall relay list is (sorted by CW), how much traffic my relay did during the last month and what fraction of the months time your relay was included in consensus as running (this shows information on how many % of the months' consensuses this relay has been included and running)
[ ] aggregate emails for all my relays into a single digest email
[ ] email me about new relay requirements
[ ] email me about tor relay operator events

  • Write a specification describing the meaning of each checkbox

Security and Privacy Implications

The service stores email addresses of potential tor relay operators, they should be kept private and safeguarded, but a passive observer can collect them by watching outbound email traffic if no TLS is used. Suggest to use a dedicated email address for this service.

Additional Ideas

  • easy: integration into tor: show the URL pointing to the new Tor Weather service like the current link to the lifecycle blogpost when tor starts and detects to be a new relay
  • Provide an uptimerobot-style status page for relay operators using onionoo data

Child Tickets

Change History (9)

comment:1 Changed 2 years ago by phoul

Cc: phoul added

comment:2 Changed 2 years ago by phoul

After talking with Karsten, it seems like the best way forward is to wait until July / August when the metrics team will be more able to handle assisting with this. I will be circling back on this issue in July.

comment:3 in reply to:  description Changed 2 years ago by nusenu

Replying to nusenu:

[ ] email me when my exit relay fails to resolve hostnames (DNS failure)

This specific item will become obsolete once #24014 is implemented and #26691 is accepted.

Also add to the checklist:

  • support PGP encrypted outbound emails

comment:4 Changed 2 years ago by nusenu

with regards to the used data source:

for availability (is the relay in consensus?) I'd recommend to use the tor consensus directly since onionoo is usually a few hours behind and we want to inform relay operators as soon as their relays drop out of consensus

for most other cases we can probably use onionoo data

Last edited 2 years ago by nusenu (previous) (diff)

comment:6 Changed 2 years ago by nusenu

an important take away from the metric-team thread:

  • we will start with a feed-only product (without SMTP email notifications) since it avoids having to ask for any subscriber data (email addresses)

Since it is a feed please make also top X feeds like:

  • feed for top N exits
  • feed for top N guards
  • feed for top N families
Last edited 2 years ago by nusenu (previous) (diff)

comment:7 Changed 7 months ago by gk

Keywords: network-health added

comment:8 Changed 7 months ago by pili

Would this be a good GSoC project?

comment:9 Changed 7 months ago by gaba

Cc: gaba added
Note: See TracTickets for help on using tickets.