commit ecc8c373f8b995afba19dec227545f81f59df876
Author: Pili Guerra <[email protected]>
Date: Tue Feb 4 12:56:17 2020 +0100
Update Tor Weather description
---
content/gsoc/tor-weather/contents.lr | 86 +++++++++++++++---------------------
1 file changed, 36 insertions(+), 50 deletions(-)
diff --git a/content/gsoc/tor-weather/contents.lr
b/content/gsoc/tor-weather/contents.lr
index 01bb416..3023237 100644
--- a/content/gsoc/tor-weather/contents.lr
+++ b/content/gsoc/tor-weather/contents.lr
@@ -15,9 +15,12 @@ color: primary
key: 11
---
languages:
-TBD
+python
+java
---
-mentors: karsten
+mentors:
+GeKo
+karsten
---
difficulty: medium
---
@@ -25,67 +28,50 @@ title: Tor Weather
---
subtitle:
-Tor Weather is the most efficient way to achieve and maintain a healthy Tor
network on the long run.
-
+This project would implement a notification system for relay operators to
alert them when the state of their relay has changed. This is the most
efficient way to achieve and maintain a healthy Tor network on the long run.
---
body:
-Tor Weather was [discontinued on
2016-04-04](https://lists.torproject.org/pipermail/tor-relays/2016-April/009009.html),
however "Tor Weather is still a good idea, it just needs somebody to implement
it."
-
-How Tor Weather looked like:
-âhttps://web.archive.org/web/20141004055709/https://weather.torproject.org/subscribe/
-
-##Â Motivation
-
-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.
+# Problem
-## Expected Effects
+If a relay disappears today, it is unlikely that anyone will notice or even
send an email to the operator.
-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
+The entire Tor network would benefit from a "Tor Weather" service to notify
relay and bridge operators when the state of their relays has changed. This has
a number of benefits, including:
-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.
+- increasing the likelihood that relay operators notice problems and actually
mitigate them.
+- showing relay operators that someone actually cares if their relays go down
or become outdated or have another problems
+- giving relay operators information about best-practices, e.g not running
outdated versions, fixing their DNs, etc...
-##Â Ideas for Notification Types
+Right now, there is very little direct feedback given to relay operators. This
can mean that operators become discouraged and stop running relays.
-_(sorted by importance)_
+# Proposal
-Support subscribing via single relay FP or MyFamily groups (should not need
any subscription change if a relay gets added to the family).
+This project would involve the implementation of an email notification service
that relay operators can subscribe to and choose which notifications they want
to receive about their relay.
-- [ ] 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
+This project already existed and was known as "Tor Weather". It was
unfortunately
[discontinued](https://lists.torproject.org/pipermail/tor-relays/2016-April/009009.html)
due to lack of maintenance and resources to keep the project alive. However,
we think that this is still a great idea and the most efficient way to achieve
and maintain a healthy Tor network on the long run. The resulting service
should conform to our current [styleguide](https://styleguide.torproject.org/).
+This notification service should support subscribing via single relay
fingerprint or MyFamily groups. Additionally, it should not need any
subscription change if a new relay gets added to the family. As this service
would store email addresses of potential tor relay operators, they should be
kept private and safeguarded. However, a passive observer can collect them by
watching outbound email traffic if no TLS is used. As such, this service should
suggest using a dedicated email address for this service.
-*Task:* Write a specification describing the meaning of each checkbox
+Once a basic email notification service is implemented, these are some ideas
for potential notification types that could be implemented within it:
+- Email me when my node is down - Here we should decide 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
+- 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
+- Email me when you detect issues with my relay
+- Email me with suggestions for configuration improvements for my relay
+- Email me when my relay is on the top 20/50/100 relays list
+- Email me with monthly/quarterly status information, e.g what is my position
in the overall relay list, how much traffic did my relay do during the last
month, etc...
+- Email me about new relay requirements
+- Email me about tor relay operator events
-##Â Security and Privacy Implications
+For each notification implemented, there should be a corresponding
specification written to describe the meaning of each notification type.
-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.
+# Resources
-##Â Additional Ideas
+- What Tor Weather looked like:
https://web.archive.org/web/20141004055709/https://weather.torproject.org/subscribe/
+- Tor Weather repo: https://gitweb.torproject.org/weather.git/
-- 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
+For the original ticket and discussion, please see ticket
[#26124](http://bugs.torproject.org/26124)
\ No newline at end of file
_______________________________________________
tor-commits mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
