commit 01813c580866f1903dec19adff37c520cb2a0963
Author: Pili Guerra <p...@piliguerra.com>
Date: Fri Feb 28 21:25:22 2020 +0100
Add project ideas
---
.../cloudflare-captcha-monitoring/contents.lr | 70 +++++++++++++++++++
.../project-ideas/gettor-distribution/contents.lr | 50 +++++++++++++
content/project-ideas/onion-toolbox/contents.lr | 67 ++++++++++++++++++
.../ooni-explorer-advanced-search/contents.lr | 61 ++++++++++++++++
.../ooni-probe-experiments/contents.lr | 61 ++++++++++++++++
.../privacy-aware-geo-lookup/contents.lr | 56 +++++++++++++++
.../project-ideas/privacy-friendly-web/contents.lr | 59 ++++++++++++++++
.../salmon-bridge-distribution/contents.lr | 48 +++++++++++++
.../snowflake-android-proxy/contents.lr | 47 +++++++++++++
content/project-ideas/tor-keygen/contents.lr | 49 +++++++++++++
.../tor-relay-ipv6-support/contents.lr | 81 ++++++++++++++++++++++
content/project-ideas/tor-weather/contents.lr | 77 ++++++++++++++++++++
12 files changed, 726 insertions(+)
diff --git a/content/project-ideas/cloudflare-captcha-monitoring/contents.lr
b/content/project-ideas/cloudflare-captcha-monitoring/contents.lr
new file mode 100644
index 0000000..c311934
--- /dev/null
+++ b/content/project-ideas/cloudflare-captcha-monitoring/contents.lr
@@ -0,0 +1,70 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 1
+---
+languages:
+python
+javascript
+---
+mentors:
+GeKo
+arma
+---
+difficulty: medium
+---
+title: Cloudflare CAPTCHA Monitoring
+---
+subtitle:
+
+This project should implement a mechanism to track the rate that Cloudflare
fronted webpages return CAPTCHAs to Tor users over time.
+
+---
+body:
+
+# Problem
+
+A large number of Tor users report getting hit by infinite CAPTCHA loops when
visiting webpages fronted by Cloudflare. This makes them feel punished for
using Tor to protect their privacy and prevents them from legitimately
accessing websites.
+
+# Proposal
+
+For this project we would like to track in practice how often Cloudflare
fronted webpages return CAPTCHAs to Tor clients.
+
+Our proposed approach consists of:
+
+1. Setting up a very simple static webpage to be fronted by Cloudflare
+2. Write a web client to periodically fetch this static webpage via Tor and
record how often a CAPTCHA is returned
+3. Record and graph CAPTCHA vs real page rates
+4. Using the pre-existing architecture, run a second client that does not
fetch this webpage via Tor. This will allow us to contrast and compare how
Cloudflare responds to Tor Browser vs other browsers.
+5. Track and publish these details publicly
+
+There are two interesting metrics to track over time:
+
+- the fraction of exit relays that are getting hit with CAPTCHAs, and
+- the chance that a Tor client, choosing an exit relay in the normal weighted
faction, will get hit by a CAPTCHA.
+
+Then there are other interesting patterns to look for:
+
+- Are certain IP addresses punished consistently and others never punished?
+- Is whether you get a CAPTCHA much more probabilistic and transient?
+- Does that pattern change over time?
+
+# Resources
+
+There is pre-existing research by the Berkeley ICSI group which includes these
sorts of checks:
+
+- https://www.freehaven.net/anonbib/#differential-ndss2016
+- https://www.freehaven.net/anonbib/#exit-blocking2017
+
+For the original ticket and discussion, please see ticket
[#33010](http://bugs.torproject.org/33010)
\ No newline at end of file
diff --git a/content/project-ideas/gettor-distribution/contents.lr
b/content/project-ideas/gettor-distribution/contents.lr
new file mode 100644
index 0000000..797a2ff
--- /dev/null
+++ b/content/project-ideas/gettor-distribution/contents.lr
@@ -0,0 +1,50 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 2
+---
+languages:
+python
+ansible
+---
+org: Tor
+---
+mentors:
+cohosh
+hiro
+---
+difficulty:
+---
+title: Implement new distribution methods for GetTor
+---
+subtitle:
+
+This project should implement a feature to distribute Tor Browser downloads
through Telegram or Facebook messenger.
+
+---
+body:
+
+# Problem
+
+Tor Browser ships with a few different anti-censorship tools to allow people
free and open access to Internet content. However, some places censor Tor
Browser downloads, making it difficult for users to install it in the first
place.
+
+#Â Proposal
+
+[GetTor](https://gettor.torproject.org/) is a system for distributing Tor
Browser using alternative methods such as email or Twitter to send users
authenticated links to Tor Browser binaries.
+
+We are looking to expand the ways in which GetTor distributes Tor Browser
binaries to make it easier for people to download and install Tor Browser. This
project would consist in implementing a feature in GetTor to distribute Tor
Browser downloads through Telegram and/or Facebook messenger.
+
+# Resources
+
+- GetTor repo on github: https://github.com/torproject/gettor
\ No newline at end of file
diff --git a/content/project-ideas/onion-toolbox/contents.lr
b/content/project-ideas/onion-toolbox/contents.lr
new file mode 100644
index 0000000..1d52e87
--- /dev/null
+++ b/content/project-ideas/onion-toolbox/contents.lr
@@ -0,0 +1,67 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 3
+---
+languages:
+Python
+Docker
+PythonQt5
+---
+mentors:
+hiro
+asn
+---
+difficulty: medium
+---
+title: Onion Tool Box
+---
+subtitle:
+
+Myonion is a developer tool box, providing a command line interface and a GUI
to configure and deploy existing services via .onion. The idea behind myonion
is to make onion services accessible to developers that might be interested to
innovate in the privacy space, building applications that are designed for
privacy and security.
+---
+body:
+
+#Â Problem
+
+It is not necessarily difficult to use onion services, but it might be tricky
to configure a web service to be offered via .onion so that it doesnât leak
sensitive information.
+
+There are detailed
[guides](https://riseup.net/en/security/network-security/tor/onionservices-best-practices)
available for users that would like to offer a web application via .onion and
some tools have been developed to help service operators: discover known
misconfiguration or [vulnerabilities](https://onionscan.org/) or deploy an
[onion site](https://github.com/alecmuffett/eotk).
+
+Involving a wider developer community can help creating a better image of Tor
and onion services, replacing the âdark netâ narrative with the secure and
private web one.
+
+Onion services can also be relevant to all those people interested in the
âzero-trustâ strategy. The concept behind zero-trust is to adopt strategies
and tools to help prevent data breaches by eliminating the concept of trust
from an organizationâs network architecture, with the principle of never
trust, always verify.
+
+Ultimately myonion is about creating a better experience for onion services
developers and operators and therefore fostering a more legitimate onion
service ecosystem.
+
+#Â Proposal
+
+Myonion is a developer tool box, providing a command line interface and a GUI
to configure and deploy existing services via .onion. A minimal prototype for
myonion already [exists](https://github.com/hiromipaw/myonion).
+
+Someone that may want to run an onion service can use the myonion wrapper app
to start a .onion from their computer and sharea static website or a web
application.
+
+Myonion can also be used to deploy the resulting configured app to a defined
set of cloud providers.
+
+Myonion provides a way to build and deploy onion ready applications, allowing
developers to build and test web applications and easily share them with
others, bundling the code and configuration in a lightweight, portable Docker
container application that runs the same everywhere.
+
+The experience for developers will be similar to using other industry
solutions, like the [Docker desktop
app](https://www.docker.com/products/docker-desktop).
+
+Developers using myonion are provided with pre-defined and customizable
application templates, with corresponding configuration and a test set,
eliminating error-prone manual setup and known onion service configuration
mistakes.
+
+The resulting application is therefore deployable via a set of endpoint
management tools to known providers. Providing a way to deploy onion services
at scale.
+
+# Resources
+
+- Myonion repo on github: https://github.com/hiromipaw/myonion
+
diff --git a/content/project-ideas/ooni-explorer-advanced-search/contents.lr
b/content/project-ideas/ooni-explorer-advanced-search/contents.lr
new file mode 100644
index 0000000..be381fd
--- /dev/null
+++ b/content/project-ideas/ooni-explorer-advanced-search/contents.lr
@@ -0,0 +1,61 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 4
+---
+languages: React
+---
+org: OONI
+---
+mentors:
+Federico Ceratto
+Arturo Filastò
+---
+difficulty: Medium
+---
+title: OONI Explorer Advanced Search
+---
+subtitle:
+
+OONI Explorer is an open data resource on internet censorship around the
world. This project is about enriching the OONI Explorer search functionality
with the ability to visualize an analysis of metadata pertaining to filtered
measurements.
+---
+body:
+
+# Background
+
+OONI Explorer is an open data resource on internet censorship around the
world. This project is about enriching the OONI Explorer search functionality
with the ability to visualize an analysis of metadata pertaining to filtered
measurements.
+
+# Proposal
+
+This project is about enriching the OONI Explorer search functionality with
the ability to visualize an analysis of metadata pertaining to filtered
measurements.
+
+This would involve adding the ability to filter on multiple axis: country,
ASN, time range, anomaly, confirmed, failure, domain or input, citizenlab
category code.
+
+The results would then be presented in an aggregate form, such as showing:
+
+- The total measurement count
+- The anomaly vs total ratio
+- Confirmed vs total
+- Failure vs total
+
+These results could then be presented as a table or some other charts, such as
a heatmat.
+
+Some other more detailed, drill-down views could also be implemented.
+
+A potential applicant should also have some prior design experience
+
+# Resources
+
+- OONI Explorer repo on github: https://github.com/ooni/explorer
+
diff --git a/content/project-ideas/ooni-probe-experiments/contents.lr
b/content/project-ideas/ooni-probe-experiments/contents.lr
new file mode 100644
index 0000000..1eb568e
--- /dev/null
+++ b/content/project-ideas/ooni-probe-experiments/contents.lr
@@ -0,0 +1,61 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 5
+---
+languages: Golang
+---
+org: OONI
+---
+mentors:
+Simone Basso
+Arturo Filastò
+---
+difficulty: low-high
+---
+title: OONI Probe network experiments
+---
+subtitle:
+
+OONI Probe is a free software project that aims to uncover internet censorship
around the world. As part of this project you would be working on researching
and developing new OONI Probe network experiments.
+
+---
+body:
+
+# Background
+
+The Open Observatory of Network Interference (OONI) is a free software project
which aims to empower decentralized efforts in increasing transparency of
internet censorship around the world.
+
+We develop free and open source software, called OONI Probe, that users can
run to measure:
+
+- Blocking of websites;
+- Blocking of instant messaging apps (WhatsApp, Facebook Messenger and
Telegram);
+- Blocking of censorship circumvention tools (such as Tor);
+- Presence of systems (middleboxes) in your network that might be responsible
for censorship and/or surveillance;
+- Speed and performance of your network.
+
+By running OONI Probe, users can collect data that can potentially serve as
evidence of internet censorship since it shows how, when, where, and by whom it
is implemented.
+
+# Proposal
+
+*Prerequisites:* Knowledge of network programming
+
+As part of this project you would be working on researching and developing new
OONI Probe network experiments. These experiments would be integrated inside of
probe-engine and could eventually make their way into the OONI Probe desktop
client.
+
+The GSoC project is only about researching and implementing a working test in
probe-engine, not the UI and client integration of the test.
+
+# Resources
+
+- OONI Probe repo on github: https://github.com/ooni/probe-engine
+- [Ideas for new
experiments](https://github.com/ooni/probe-engine/issues?q=is%3Aopen+is%3Aissue+label%3A%22new+experiment%22)
\ No newline at end of file
diff --git a/content/project-ideas/privacy-aware-geo-lookup/contents.lr
b/content/project-ideas/privacy-aware-geo-lookup/contents.lr
new file mode 100644
index 0000000..e170747
--- /dev/null
+++ b/content/project-ideas/privacy-aware-geo-lookup/contents.lr
@@ -0,0 +1,56 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 6
+---
+languages:
+Golang
+Java
+Android
+---
+org: OONI
+---
+mentors:
+Simone Basso
+Arturo Filastò
+---
+difficulty: Medium
+---
+title: Privacy aware geo lookup
+---
+subtitle:
+
+The idea for this project is to research a way to do a GPS based location
lookup which resolves the location of the user to a granularity which is useful
for qualifying measurements, but that doesnât compromise users safety and
privacy.
+
+---
+body:
+
+# Problem
+
+When looking at OONI Probe measurements we often face a challenge in properly
understanding what country (or more granular location) they are telling us
things about.
+
+Often times the location information (since it's based on geoip) is
inaccurate, because the underlying GeoIP database we used was old.
+
+On the other hand we also have a responsibility to protect user privacy to the
extent that it's possible and therefore we don't collect IPs or store location
information that is more granular than country level.
+
+# Proposal
+*Prerequisites:* familiarity with Android development and aptitude for research
+
+The idea for this project is to research a way to do a GPS based location
lookup which resolves the location of the user to a granularity which is useful
for qualifying measurements, but that doesnât compromise users safety and
privacy.
+
+# Resources
+
+- OONI Probe engine repo on github: https://github.com/ooni/probe-engine
+
+For the original ticket and discussion, please see ticket
[249](https://github.com/ooni/probe-engine/issues/249)
\ No newline at end of file
diff --git a/content/project-ideas/privacy-friendly-web/contents.lr
b/content/project-ideas/privacy-friendly-web/contents.lr
new file mode 100644
index 0000000..7ab642b
--- /dev/null
+++ b/content/project-ideas/privacy-friendly-web/contents.lr
@@ -0,0 +1,59 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 7
+---
+languages:
+javascript
+CSS
+HTML
+Python
+---
+mentors:
+hiro
+---
+difficulty: medium
+---
+title: Privacy Friendly Web
+---
+subtitle:
+
+The scope of this project is creating a open-source community-driven browsable
list of patterns and release a css/js framework that web developers can extend
and use in their work.
+---
+body:
+
+# Problem
+
+Security concerned web users take conscious steps to limit the amount of data
they share with the websites visited and third party services.
+
+There are a number of security enhancing tools available. Some come in the
form of browser extensions and javascript blockers, others are full fledged web
browsers designed with providing extra security to their users.
+
+One of these is the Tor Browser. The Tor Browser was designed to provide
privacy while surfing the web and defend users against both network and local
forensic adversaries. There are two main categories of requirements that have
been considered: Security Requirements, and Privacy Requirements.
+
+Security Requirements are the minimum properties in order for a browser to be
able to support Tor and similar privacy proxies safely. Privacy requirements
are primarily concerned with reducing linkability: the ability for a user's
activity on one site to be linked with their activity on another site without
their knowledge or explicit consent.
+
+# Proposal
+
+Websites can work seamlessly with the Tor Browser and other privacy enhancing
browsers and tools if they adopt a series of respectful and ethical patterns.
+
+The Tor Browser is in fact, based on Mozilla's Extended Support Release (ESR)
Firefox branch. We have a series of patches against this browser to enhance
privacy and security. Browser behavior is additionally augmented through the
Torbutton extension, and we also change a number of Firefox preferences from
their defaults.
+
+The Tor Project has developed over the years a set of web development
guidelines that allow websites to work with security enhanced browsers without
causing any or minimal functionality destruption to their users. These
guidelines have been shaped in an internal styleguide that has been adopted
across all torproject.org websites.
+
+We are now formalizing these web development patterns and some security
concerns that need to be considered when developing websites for users surfing
the web with security enhanced browsers and tools. The scope of this project is
creating a open-source community-driven browsable list of patterns and release
a css/js framework that web developers can extend and use in their work.
+
+# Resources
+
+- Tor Project [styleguide](https://styleguide.torproject.org/)
+- Styleguide repo on github: https://github.com/torproject/styleguide
diff --git a/content/project-ideas/salmon-bridge-distribution/contents.lr
b/content/project-ideas/salmon-bridge-distribution/contents.lr
new file mode 100644
index 0000000..8ec5614
--- /dev/null
+++ b/content/project-ideas/salmon-bridge-distribution/contents.lr
@@ -0,0 +1,48 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 8
+---
+languages:
+---
+org: Tor
+---
+mentors:
+cohosh
+ahf
+---
+difficulty:
+---
+title: Implementing Salmon as a bridge distribution mechanism
+---
+subtitle:
+
+This project entails implementing Salmon, a bridge distribution mechanism that
partitions and distributes bridges using reputation to give well-behaved users
access to "better" bridges and add a penalty when their bridges get censored.
+
+---
+body:
+
+# Problem
+
+Bridges are Tor relays that are not publicly listed and therefore allow access
to the Tor network in places where access to the public Tor relays, and
therefore access to the Tor network, is blocked. Many users rely on bridges, or
anti-censorship proxies, to connect to the Tor network. However, when censors
learn this information, the bridges quickly become blocked and can no longer be
used. We need a way of distributing bridge information to users so that they
are able to connect without these bridges being discovered by the censors.
+
+# Proposal
+
+Our goal is to distribute bridges to users in censored regions when they need
them, while also limiting the amount of bridge information that is leaked to
censors. This project entails implementing Salmon, a bridge distribution
mechanism that partitions and distributes bridges using reputation to give
well-behaved users access to "better" bridges and add a penalty when their
bridges get censored.
+
+# Resources
+
+- Original Paper: [Salmon: Robust Proxy Distribution for
+Censorship
Circumvention](https://petsymposium.org/2016/files/papers/Salmon__Robust_Proxy_Distribution_for_Censorship_Circumvention.pdf)
+- Salmon Project on github: https://github.com/SalmonProject
\ No newline at end of file
diff --git a/content/project-ideas/snowflake-android-proxy/contents.lr
b/content/project-ideas/snowflake-android-proxy/contents.lr
new file mode 100644
index 0000000..f922efb
--- /dev/null
+++ b/content/project-ideas/snowflake-android-proxy/contents.lr
@@ -0,0 +1,47 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 9
+---
+languages:
+Android
+---
+org: Tor
+---
+mentors:
+cohosh
+---
+difficulty:
+---
+title: Snowflake proxy on Android
+---
+subtitle:
+
+This project entails implementing a Snowflake proxy app that will run on
Android and relay a user's Tor traffic to the Tor network in the background.
+
+---
+body:
+
+# Background
+
+[Snowflake](https://snowflake.torproject.org/) is a circumvention system in
which volunteers can run proxies to help users connect to the Tor network.
Users make WebRTC connections to the proxies, who then relay this data to a
Snowflake bridge and then on to the Tor network. The advantage of using WebRTC
is that Snowflake proxies can frequently change IP address or operate behind a
NAT. At the moment, we have implemented the Snowflake proxy code as a web
extension or a web badge, but we have not yet implemented a proxy that will run
smoothly on Android.
+
+# Proposal
+
+This project entails implementing a Snowflake proxy app that will run on
Android and relay a user's Tor traffic to the Tor network in the background.
There is an implementation component as well as an exploration and testing
component while we figure out how to achieve good performance from a background
application without using too much of the volunteer proxy's data or resources.
+
+# Resources
+
+- [Snowflake](https://snowflake.torproject.org/)
+- Snowflake repo:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/
\ No newline at end of file
diff --git a/content/project-ideas/tor-keygen/contents.lr
b/content/project-ideas/tor-keygen/contents.lr
new file mode 100644
index 0000000..f32192f
--- /dev/null
+++ b/content/project-ideas/tor-keygen/contents.lr
@@ -0,0 +1,49 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 12
+---
+languages:
+C
+Python
+Golang
+Rust
+---
+mentors:
+asn
+dgoulet
+---
+difficulty: medium/hard
+---
+title: tor-keygen
+---
+subtitle:
+
+The scope of this project is to write an application that generates
cryptographic keys for Tor relays, dirauths and onion services.
+---
+body:
+
+# Problem
+
+
+# Proposal
+
+Prerequisites: Understanding of Tor protocol and tor codebase
+
+# Resources
+
+- https://trac.torproject.org/projects/tor/ticket/18098
+- https://trac.torproject.org/projects/tor/ticket/14389
+-
https://github.com/torproject/tor/blob/e34d963c4453ceac7ff378ce0044d10461980c8e/src/app/main/main.c#L1282
+- Original tor-keygen repo on github: https://github.com/haxxpop/torkeygen
\ No newline at end of file
diff --git a/content/project-ideas/tor-relay-ipv6-support/contents.lr
b/content/project-ideas/tor-relay-ipv6-support/contents.lr
new file mode 100644
index 0000000..86518a2
--- /dev/null
+++ b/content/project-ideas/tor-relay-ipv6-support/contents.lr
@@ -0,0 +1,81 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 10
+---
+languages:
+C
+---
+mentors:
+teor
+ahf (to be confirmed)
+---
+difficulty: Medium
+---
+title: Improve Tor Relay IPv6 Support
+---
+subtitle:
+
+Tor helps people stay safe on the internet, by keeping their internet use
secure and anonymous. More Tor clients are running on IPv6-only or dual-stack
networks. But only 20% of Torâs available relay bandwidth supports IPv6. We
want to automate relay IPv6 address discovery and reachability checks, so that
it is easier for relay operators to run IPv6 relays.
+
+---
+body:
+
+The Tor Project will be improving tor relay IPv6 support in 2020.
+
+Students may choose to focus on:
+ * designing and implementing tor relay IPv6 features,
+ * tor relay IPv6 testing, or
+ * diagnosing and fixing bugs in tor's IPv6 code.
+
+## Prerequisites
+
+* Network configuration skills
+* Basic understanding of IPv4 and IPv6
+
+Recommended:
+
+* Experience testing network software
+* Experience running Internet-connected servers
+
+## Programming skills needed:
+
+* C coding
+* Building Unix-based (Linux, *BSD, macOS) software
+
+Recommended:
+
+* Experience with Unix network programming
+* Python coding (for testing)
+* Access to a server with public IPv4 and IPv6 addresses (to run a test relay)
+
+## Links/Resources
+
+### Technical Proposals
+
+Tor Relay IPv6 Reachability
+https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
+
+Tor Relay Automatic IPv6 Address Discovery
+https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt
+
+### Relay Operator Guides
+
+Tor Relay Guide: IPv6
+https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#IPv6
+
+### Roadmaps
+
+Tor IPv6 Roadmap
+https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features
diff --git a/content/project-ideas/tor-weather/contents.lr
b/content/project-ideas/tor-weather/contents.lr
new file mode 100644
index 0000000..3023237
--- /dev/null
+++ b/content/project-ideas/tor-weather/contents.lr
@@ -0,0 +1,77 @@
+_model: project
+---
+_template: layout.html
+---
+html: two-columns-page.html
+---
+active: True
+---
+section: GSoC
+---
+section_id: gsoc
+---
+color: primary
+---
+key: 11
+---
+languages:
+python
+java
+---
+mentors:
+GeKo
+karsten
+---
+difficulty: medium
+---
+title: Tor Weather
+---
+subtitle:
+
+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:
+
+# Problem
+
+If a relay disappears today, it is unlikely that anyone will notice or even
send an email to the operator.
+
+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:
+
+- 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...
+
+Right now, there is very little direct feedback given to relay operators. This
can mean that operators become discouraged and stop running relays.
+
+# Proposal
+
+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.
+
+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.
+
+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
+
+For each notification implemented, there should be a corresponding
specification written to describe the meaning of each notification type.
+
+# Resources
+
+- 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/
+
+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
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
