tor-commits February 2020

tor-commits@lists.torproject.org

22 participants
1454 discussions

[community/master] Update Tor Weather description
by pili＠torproject.org 04 Feb '20

04 Feb '20

commit ecc8c373f8b995afba19dec227545f81f59df876 Author: Pili Guerra <pili(a)piliguerra.com> 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/00…, 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/… 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/s… +- 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

1 0

[community/master] Minor display fixes
by pili＠torproject.org 04 Feb '20

04 Feb '20

commit c5053398fdd93b7d4819f7bdf6ddd352957c165c Author: Pili Guerra <pili(a)piliguerra.com> Date: Thu Jan 30 16:07:01 2020 +0100 Minor display fixes --- content/gsoc/contents.lr | 2 +- templates/macros/projects.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/gsoc/contents.lr b/content/gsoc/contents.lr index 25d1562..a74dc57 100644 --- a/content/gsoc/contents.lr +++ b/content/gsoc/contents.lr @@ -10,7 +10,7 @@ html: gsoc.html --- color: primary --- -subtitle: Some projects ideas for GSoC. +subtitle: Some project ideas for GSoC. --- cta: Get coding --- diff --git a/templates/macros/projects.html b/templates/macros/projects.html index d4da228..bbda578 100644 --- a/templates/macros/projects.html +++ b/templates/macros/projects.html @@ -10,7 +10,7 @@ </div> <div> <div class="card-body"> - {{ item.summary }} + {{ item.subtitle }} <a href="{{ item.path|url }}">{{ _('Read more.') }}</a> </div> </div>

1 0

[community/master] Fix style and order issues
by pili＠torproject.org 04 Feb '20

04 Feb '20

commit 0e0fbe73f9045e1eb862258a72ab27f1811d17b6 Author: Pili Guerra <pili(a)piliguerra.com> Date: Tue Feb 4 11:01:01 2020 +0100 Fix style and order issues --- content/gsoc/cloudflare-captcha-monitoring/contents.lr | 2 +- content/gsoc/gettor-distribution/contents.lr | 2 +- content/gsoc/onion-toolbox/contents.lr | 2 +- content/gsoc/ooni-explorer-advanced-search/contents.lr | 2 +- content/gsoc/ooni-probe-experiments/contents.lr | 2 +- content/gsoc/privacy-aware-geo-lookup/contents.lr | 6 ++++-- content/gsoc/privacy-friendly-web/contents.lr | 2 +- content/gsoc/salmon-bridge-distribution/contents.lr | 4 ++-- content/gsoc/snowflake-android-proxy/contents.lr | 3 ++- content/gsoc/tor-relay-ipv6-support/contents.lr | 2 +- content/gsoc/tor-weather/contents.lr | 2 +- 11 files changed, 16 insertions(+), 13 deletions(-) diff --git a/content/gsoc/cloudflare-captcha-monitoring/contents.lr b/content/gsoc/cloudflare-captcha-monitoring/contents.lr index 2263ecc..c5daeb4 100644 --- a/content/gsoc/cloudflare-captcha-monitoring/contents.lr +++ b/content/gsoc/cloudflare-captcha-monitoring/contents.lr @@ -17,7 +17,7 @@ key: 1 languages: javascript --- -mentors: arma, gk +mentors: GeKo, arma --- difficulty: medium --- diff --git a/content/gsoc/gettor-distribution/contents.lr b/content/gsoc/gettor-distribution/contents.lr index d0b7030..19213f2 100644 --- a/content/gsoc/gettor-distribution/contents.lr +++ b/content/gsoc/gettor-distribution/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 2 --- languages: python --- diff --git a/content/gsoc/onion-toolbox/contents.lr b/content/gsoc/onion-toolbox/contents.lr index 7968f31..ed8b5e4 100644 --- a/content/gsoc/onion-toolbox/contents.lr +++ b/content/gsoc/onion-toolbox/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 3 --- languages: Python diff --git a/content/gsoc/ooni-explorer-advanced-search/contents.lr b/content/gsoc/ooni-explorer-advanced-search/contents.lr index bcb3cd4..99b9484 100644 --- a/content/gsoc/ooni-explorer-advanced-search/contents.lr +++ b/content/gsoc/ooni-explorer-advanced-search/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 4 --- languages: React --- diff --git a/content/gsoc/ooni-probe-experiments/contents.lr b/content/gsoc/ooni-probe-experiments/contents.lr index 45dc216..8f18dcc 100644 --- a/content/gsoc/ooni-probe-experiments/contents.lr +++ b/content/gsoc/ooni-probe-experiments/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 5 --- languages: Golang --- diff --git a/content/gsoc/privacy-aware-geo-lookup/contents.lr b/content/gsoc/privacy-aware-geo-lookup/contents.lr index 4fd5451..d0ba616 100644 --- a/content/gsoc/privacy-aware-geo-lookup/contents.lr +++ b/content/gsoc/privacy-aware-geo-lookup/contents.lr @@ -12,9 +12,11 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 6 --- -languages: Golang, Java +languages: +Golang +Java --- org: OONI --- diff --git a/content/gsoc/privacy-friendly-web/contents.lr b/content/gsoc/privacy-friendly-web/contents.lr index fb32b0f..c56e209 100644 --- a/content/gsoc/privacy-friendly-web/contents.lr +++ b/content/gsoc/privacy-friendly-web/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 7 --- languages: javascript diff --git a/content/gsoc/salmon-bridge-distribution/contents.lr b/content/gsoc/salmon-bridge-distribution/contents.lr index 4952c99..11855dc 100644 --- a/content/gsoc/salmon-bridge-distribution/contents.lr +++ b/content/gsoc/salmon-bridge-distribution/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 8 --- languages: --- @@ -22,7 +22,7 @@ mentors: --- difficulty: --- -title: +title: Implementing Salmon as a bridge distribution mechanism --- subtitle: diff --git a/content/gsoc/snowflake-android-proxy/contents.lr b/content/gsoc/snowflake-android-proxy/contents.lr index f99b301..96f802b 100644 --- a/content/gsoc/snowflake-android-proxy/contents.lr +++ b/content/gsoc/snowflake-android-proxy/contents.lr @@ -12,9 +12,10 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 9 --- languages: +Android --- org: Tor --- diff --git a/content/gsoc/tor-relay-ipv6-support/contents.lr b/content/gsoc/tor-relay-ipv6-support/contents.lr index 1300b87..4aff974 100644 --- a/content/gsoc/tor-relay-ipv6-support/contents.lr +++ b/content/gsoc/tor-relay-ipv6-support/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 1 +key: 10 --- languages: C diff --git a/content/gsoc/tor-weather/contents.lr b/content/gsoc/tor-weather/contents.lr index 0c69dec..01bb416 100644 --- a/content/gsoc/tor-weather/contents.lr +++ b/content/gsoc/tor-weather/contents.lr @@ -12,7 +12,7 @@ section_id: gsoc --- color: primary --- -key: 2 +key: 11 --- languages: TBD

1 0

[community/master] Rewrote and reviewed cloudflare captcha monitoring project
by pili＠torproject.org 04 Feb '20

04 Feb '20

commit fdb8ba63730ccbf9c1debfbae46f78030d11b7f8 Author: Pili Guerra <pili(a)piliguerra.com> Date: Tue Feb 4 11:29:13 2020 +0100 Rewrote and reviewed cloudflare captcha monitoring project --- .../gsoc/cloudflare-captcha-monitoring/contents.lr | 41 +++++++++++++++------- 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/content/gsoc/cloudflare-captcha-monitoring/contents.lr b/content/gsoc/cloudflare-captcha-monitoring/contents.lr index c5daeb4..332ca2a 100644 --- a/content/gsoc/cloudflare-captcha-monitoring/contents.lr +++ b/content/gsoc/cloudflare-captcha-monitoring/contents.lr @@ -25,26 +25,43 @@ title: Cloudflare Captcha Monitoring --- subtitle: -We should track the rate that cloudflare gives captchas to Tor users over time. +This project should implement a mechanism to track the rate that Cloudflare fronted webpages return captchas to Tor users over time. --- body: -My suggested way of doing that tracking is to sign up a very simple static webpage to be fronted by cloudflare, and then fetch it via Tor over time, and record and graph the rates of getting a captcha vs getting the real page. +# Problem -The reason for the "simple static page" is to make it really easy to distinguish whether we're getting hit with a captcha. The "distinguishing one dynamic web page from another" challenge makes exitmap tricky in the general case, but we can remove that variable here. +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. -One catch is that Cloudflare currently gives alt-svc headers in response to fetches from Tor addresses. So that means we need a web client that can follow alt-srv headers -- maybe we need a full Selenium like client? +# Proposal -Once we get the infrastructure set up, we would be smart to run a second one which is just wget or curl or lynx or something, i.e. which doesn't behave like Tor Browser, in order to be able to track the difference between how Cloudflare responds to Tor Browser vs other browsers. +For this project we would like to track in practice how often Cloudflare fronted webpages return captchas to Tor clients. -I imagine that Cloudflare should be internally tracking how they're handling Tor requests, but having a public tracker (a) gives the data to everybody, and (b) helps Cloudflare have a second opinion in case their internal data diverges from the public version. +Our proposed approach consists of: -The Berkeley ICSI group did research that included this sort of check: -https://www.freehaven.net/anonbib/#differential-ndss2016 -https://www.freehaven.net/anonbib/#exit-blocking2017 -but what I have in mind here is essentially a simpler subset of this research, skipping the complicated part of "how do you tell what kind of response you got" and with an emphasis on automation and consistency. +1. Setting up a very simple static webpage to be fronted by Cloudflare +2. Write an application which small 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: one is the fraction of exit relays that are getting hit with captchas, and the other is the chance that a Tor client, choosing an exit relay in the normal weighted faction, will get hit by a captcha. +There are two interesting metrics to track over time: -Then there are other interesting patterns to look for, e.g. "are certain IP addresses punished consistently and others never punished, or is whether you get a captcha much more probabilistic and transient?" And does that pattern change 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

1 0

[community/master] Add some more projects
by pili＠torproject.org 04 Feb '20

04 Feb '20

commit 3b8d7d9c8c9e97145972678666fe124b5b1e97d8 Author: Pili Guerra <pili(a)piliguerra.com> Date: Thu Jan 30 16:08:11 2020 +0100 Add some more projects --- content/gsoc/gettor-distribution/contents.lr | 35 +++++++++++++++ .../gsoc/ooni-explorer-advanced-search/contents.lr | 51 ++++++++++++++++++++++ content/gsoc/ooni-probe-experiments/contents.lr | 41 +++++++++++++++++ content/gsoc/privacy-aware-geo-lookup/contents.lr | 43 ++++++++++++++++++ .../gsoc/salmon-bridge-distribution/contents.lr | 37 ++++++++++++++++ content/gsoc/snowflake-android-proxy/contents.lr | 38 ++++++++++++++++ 6 files changed, 245 insertions(+) diff --git a/content/gsoc/gettor-distribution/contents.lr b/content/gsoc/gettor-distribution/contents.lr new file mode 100644 index 0000000..d0b7030 --- /dev/null +++ b/content/gsoc/gettor-distribution/contents.lr @@ -0,0 +1,35 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: python +--- +org: Tor +--- +mentors: cohos, hiro +--- +difficulty: +--- +title: Implement a new distribution methods for GetTor +--- +subtitle: + +This project would implement a feature to distribute Tor Browser downloads through Telegram or Facebook messenger. + +--- +body: + + +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. GetTor 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 these binaries. This project would implement a feature to distribute Tor Browser downloads through Telegram or Facebook messenger. \ No newline at end of file diff --git a/content/gsoc/ooni-explorer-advanced-search/contents.lr b/content/gsoc/ooni-explorer-advanced-search/contents.lr new file mode 100644 index 0000000..bcb3cd4 --- /dev/null +++ b/content/gsoc/ooni-explorer-advanced-search/contents.lr @@ -0,0 +1,51 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: React +--- +org: OONI +--- +mentors: Federico Ceratto, Arturo Filastò +--- +difficulty: Medium +--- +title: OONI Explorer Advanced Search +--- +subtitle: + +This project is about enriching the OONI Explorer search functionality with the ability to visualize an analysis of metadata pertaining to filtered measurements. + +--- +body: + +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 + +- *Prerequisites:* API call to be implemented by Federico +- *Links/Resource:* https://github.com/ooni/explorer + diff --git a/content/gsoc/ooni-probe-experiments/contents.lr b/content/gsoc/ooni-probe-experiments/contents.lr new file mode 100644 index 0000000..45dc216 --- /dev/null +++ b/content/gsoc/ooni-probe-experiments/contents.lr @@ -0,0 +1,41 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: Golang +--- +org: OONI +--- +mentors: Simone Basso, Arturo Filastò +--- +difficulty: low-high +--- +title: OONI Probe network experiments +--- +subtitle: + +As part of this project you would be working on researching and developing new OONI Probe network experiments. + +--- +body: + +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. + +For some inspiration on some ideas for new experiments, see: https://github.com/ooni/probe-engine/issues?q=is%3Aopen+is%3Aissue+label%3A… + +Prerequisites: Knowledge of network programming +Links/Resources: https://github.com/ooni/probe-engine \ No newline at end of file diff --git a/content/gsoc/privacy-aware-geo-lookup/contents.lr b/content/gsoc/privacy-aware-geo-lookup/contents.lr new file mode 100644 index 0000000..4fd5451 --- /dev/null +++ b/content/gsoc/privacy-aware-geo-lookup/contents.lr @@ -0,0 +1,43 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: Golang, Java +--- +org: OONI +--- +mentors: Simone Basso, Arturo Filastò +--- +difficulty: Medium +--- +title: OONI Probe network experiments +--- +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: + +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. + +See: https://github.com/ooni/probe-engine/issues/249 + +Prerequisites: familiarity with Android development and aptitude for research +Links/Resource: https://github.com/ooni/probe-engine/issues/249 \ No newline at end of file diff --git a/content/gsoc/salmon-bridge-distribution/contents.lr b/content/gsoc/salmon-bridge-distribution/contents.lr new file mode 100644 index 0000000..4952c99 --- /dev/null +++ b/content/gsoc/salmon-bridge-distribution/contents.lr @@ -0,0 +1,37 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: +--- +org: Tor +--- +mentors: +--- +difficulty: +--- +title: +--- +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: + +Short description: Many users rely on bridges, or anti-censorship proxies, to connect to the Tor network. We need a way of distributing bridge information to users so that they are able to connect. However, when censors learn this information the bridges quickly become blocked and can no longer be used. 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. + +For more information on Salmon, see the related paper and source code. + diff --git a/content/gsoc/snowflake-android-proxy/contents.lr b/content/gsoc/snowflake-android-proxy/contents.lr new file mode 100644 index 0000000..f99b301 --- /dev/null +++ b/content/gsoc/snowflake-android-proxy/contents.lr @@ -0,0 +1,38 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: +--- +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: + +Snowflake 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. + +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. + +Skills Needed: Development experience on Android. \ No newline at end of file

1 0

[tpo/master] Update Sponsor
by antonela＠torproject.org 04 Feb '20

04 Feb '20

commit ca550219095b35363fe6ce37facddc1e72abb42a Author: Antonela <hola(a)antonela.me> Date: Tue Feb 4 11:02:23 2020 +0100 Update Sponsor Close https://trac.torproject.org/projects/tor/ticket/33142 --- .../sponsors/Georgetown_logotype_S_blueRGB.png | Bin 10906 -> 31850 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/assets/static/images/sponsors/Georgetown_logotype_S_blueRGB.png b/assets/static/images/sponsors/Georgetown_logotype_S_blueRGB.png index 88b735c..a2fba65 100644 Binary files a/assets/static/images/sponsors/Georgetown_logotype_S_blueRGB.png and b/assets/static/images/sponsors/Georgetown_logotype_S_blueRGB.png differ

1 0

[tor/master] address: Fix comments in address.h
by teor＠torproject.org 04 Feb '20

04 Feb '20

commit ff52051754283d725efbcac819f9d71c90857a96 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 14:36:04 2020 +1000 address: Fix comments in address.h And improve inline function spacing, and function declaration spacing. Comment-only change. --- src/lib/net/address.h | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/src/lib/net/address.h b/src/lib/net/address.h index f04f31944..815fb0228 100644 --- a/src/lib/net/address.h +++ b/src/lib/net/address.h @@ -62,6 +62,7 @@ typedef uint8_t maskbits_t; struct in_addr; + /** Holds an IPv4 or IPv6 address. (Uses less memory than struct * sockaddr_storage.) */ typedef struct tor_addr_t @@ -133,6 +134,7 @@ tor_addr_to_in6_assert(const tor_addr_t *a) * Requires that x is actually an IPv6 address. */ #define tor_addr_to_in6_addr16(x) S6_ADDR16(*tor_addr_to_in6_assert(x)) + /** Given an IPv6 address x, yield it as an array of uint32_t. * * Requires that x is actually an IPv6 address. @@ -146,6 +148,7 @@ tor_addr_to_ipv4n(const tor_addr_t *a) { return a->family == AF_INET ? a->addr.in_addr.s_addr : 0; } + /** Return an IPv4 address in host order for a, or 0 if * a is not an IPv4 address. */ static inline uint32_t @@ -153,10 +156,11 @@ tor_addr_to_ipv4h(const tor_addr_t *a) { return ntohl(tor_addr_to_ipv4n(a)); } + /** Given an IPv6 address, return its mapped IPv4 address in host order, or * 0 if a is not an IPv6 address. * - * (Does not check whether the address is really a mapped address */ + * (Does not check whether the address is really a mapped address.) */ static inline uint32_t tor_addr_to_mapped_ipv4h(const tor_addr_t *a) { @@ -165,14 +169,13 @@ tor_addr_to_mapped_ipv4h(const tor_addr_t *a) // Work around an incorrect NULL pointer dereference warning in // "clang --analyze" due to limited analysis depth addr32 = tor_addr_to_in6_addr32(a); - // To improve performance, wrap this assertion in: - // #if !defined(__clang_analyzer__) || PARANOIA tor_assert(addr32); return ntohl(addr32[3]); } else { return 0; } } + /** Return the address family of a. Possible values are: * AF_INET6, AF_INET, AF_UNSPEC. */ static inline sa_family_t @@ -180,6 +183,7 @@ tor_addr_family(const tor_addr_t *a) { return a->family; } + /** Return an in_addr* equivalent to a, or NULL if a is not * an IPv4 address. */ static inline const struct in_addr * @@ -187,6 +191,7 @@ tor_addr_to_in(const tor_addr_t *a) { return a->family == AF_INET ? &a->addr.in_addr : NULL; } + /** Return true iff a is an IPv4 address equal to the host-ordered * address in u. */ static inline int @@ -209,19 +214,23 @@ char *tor_addr_to_str_dup(const tor_addr_t *addr) ATTR_MALLOC; /** Wrapper function of fmt_addr_impl(). It does not decorate IPv6 * addresses. */ #define fmt_addr(a) fmt_addr_impl((a), 0) + /** Wrapper function of fmt_addr_impl(). It decorates IPv6 * addresses. */ #define fmt_and_decorate_addr(a) fmt_addr_impl((a), 1) + const char *fmt_addr_impl(const tor_addr_t *addr, int decorate); const char *fmt_addrport(const tor_addr_t *addr, uint16_t port); const char * fmt_addr32(uint32_t addr); MOCK_DECL(int,get_interface_address6,(int severity, sa_family_t family, tor_addr_t *addr)); + struct smartlist_t; -void interface_address6_list_free_(struct smartlist_t * addrs);// XXXX +void interface_address6_list_free_(struct smartlist_t * addrs); #define interface_address6_list_free(addrs) \ FREE_AND_NULL(struct smartlist_t, interface_address6_list_free_, (addrs)) + MOCK_DECL(struct smartlist_t *,get_interface_address6_list,(int severity, sa_family_t family, int include_internal)); @@ -246,6 +255,7 @@ int tor_addr_compare_masked(const tor_addr_t *addr1, const tor_addr_t *addr2, uint64_t tor_addr_hash(const tor_addr_t *addr); struct sipkey; uint64_t tor_addr_keyed_hash(const struct sipkey *key, const tor_addr_t *addr); + int tor_addr_is_v4(const tor_addr_t *addr); int tor_addr_is_internal_(const tor_addr_t *ip, int for_listening, const char *filename, int lineno); @@ -276,11 +286,13 @@ int tor_addr_parse_PTR_name(tor_addr_t *result, const char *address, int tor_addr_parse_mask_ports(const char *s, unsigned flags, tor_addr_t *addr_out, maskbits_t *mask_out, uint16_t *port_min_out, uint16_t *port_max_out); + const char * tor_addr_to_str(char *dest, const tor_addr_t *addr, size_t len, int decorate); int tor_addr_parse(tor_addr_t *addr, const char *src); void tor_addr_copy(tor_addr_t *dest, const tor_addr_t *src); void tor_addr_copy_tight(tor_addr_t *dest, const tor_addr_t *src); + void tor_addr_from_ipv4n(tor_addr_t *dest, uint32_t v4addr); /** Set dest to the IPv4 address encoded in v4addr in host * order. */ @@ -291,6 +303,7 @@ void tor_addr_from_ipv6_bytes(tor_addr_t *dest, const char *bytes); #define tor_addr_from_in(dest, in) \ tor_addr_from_ipv4n((dest), (in)->s_addr); void tor_addr_from_in6(tor_addr_t *dest, const struct in6_addr *in6); + int tor_addr_is_null(const tor_addr_t *addr); int tor_addr_is_loopback(const tor_addr_t *addr); @@ -299,6 +312,7 @@ int tor_addr_is_valid_ipv4n(uint32_t v4n_addr, int for_listening); #define tor_addr_is_valid_ipv4h(v4h_addr, for_listening) \ tor_addr_is_valid_ipv4n(htonl(v4h_addr), (for_listening)) int tor_port_is_valid(uint16_t port, int for_listening); + /* Are addr and port both valid? */ #define tor_addr_port_is_valid(addr, port, for_listening) \ (tor_addr_is_valid((addr), (for_listening)) && \ @@ -329,9 +343,11 @@ int parse_port_range(const char *port, uint16_t *port_min_out, uint16_t *port_max_out); int addr_mask_get_bits(uint32_t mask); char *tor_dup_ip(uint32_t addr) ATTR_MALLOC; + MOCK_DECL(int,get_interface_address,(int severity, uint32_t *addr)); #define interface_address_list_free(lst)\ interface_address6_list_free(lst) + /** Return a smartlist of the IPv4 addresses of all interfaces on the server. * Excludes loopback and multicast addresses. Only includes internal addresses * if include_internal is true. (Note that a relay behind NAT may use an

1 0

[tor/master] go in to fix one typo, end up fixing more
by arma＠torproject.org 04 Feb '20

04 Feb '20

commit 90bb4872b82435b2750859a35937a748c2917c31 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Feb 3 23:21:58 2020 -0500 go in to fix one typo, end up fixing more --- doc/HACKING/HelpfulTools.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md index 866b32128..ae892c34a 100644 --- a/doc/HACKING/HelpfulTools.md +++ b/doc/HACKING/HelpfulTools.md @@ -251,16 +251,16 @@ Now you can run Tor with profiling enabled, and use the pprof utility to look at performance! See the gperftools manual for more info, but basically: 2. Run `env CPUPROFILE=/tmp/profile src/app/tor -f <path/torrc>`. The profile file - is not written to until Tor finishes execuction. + is not written to until Tor finishes execution. -3. Run `pprof src/app/tor /tm/profile` to start the REPL. +3. Run `pprof src/app/tor /tmp/profile` to start the REPL. Generating and analyzing a callgraph ------------------------------------ 0. Build Tor on linux or mac, ideally with -O0 or -fno-inline. -1. Clone 'https://gitweb.torproject.org/user/nickm/calltool.git/' . +1. Clone 'https://git.torproject.org/user/nickm/calltool.git/' . Follow the README in that repository. Note that currently the callgraph generator can't detect calls that pass @@ -396,7 +396,7 @@ source code. Here's how to use it: 6. See the Doxygen manual for more information; this summary just scratches the surface. -Style and best-pratices checking +Style and best-practices checking -------------------------------- We use scripts to check for various problems in the formatting and style

1 0

[translation/communitytpo-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-contentspot
by translation＠torproject.org 03 Feb '20

03 Feb '20

commit 928ea018fd964b864ff42388e3da8d58756a13fe Author: Translation commit bot <translation(a)torproject.org> Date: Mon Feb 3 21:45:27 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-conten… --- contents+de.po | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/contents+de.po b/contents+de.po index 791cdc858e..af04af00e2 100644 --- a/contents+de.po +++ b/contents+de.po @@ -618,11 +618,13 @@ msgid "" "Note: That is only about 1 day worth of traffic on a 10 Mbit/s (Mbps) " "connection." msgstr "" +"Anmerkung: Das ist nur etwa 1 Tagesverkehr auf einer 10 Mbit/s " +"(Mbps)-Verbindung." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "More (>2 TB/month) is better and recommended." -msgstr "" +msgstr "Mehr (>2 TB/Monat) ist besser und empfehlenswert." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -630,6 +632,8 @@ msgid "" "**Ideally a relay runs on an unmetered plan** or includes 2 TB/month or " "more." msgstr "" +"**Idealerweise läuft ein Relay nach einem unbegrenzten Plan** oder " +"beinhaltet 2 TB/Monat oder mehr." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -637,6 +641,9 @@ msgid "" "If you have a metered plan you might want to configure tor to only use a " "given amount of [bandwidth or monthly traffic](/relay/setup/post-install/)." msgstr "" +"Wenn du einen gebührenpflichtigen Plan hast, solltest du Tor so " +"konfigurieren, dass es nur eine bestimmte Menge an [Bandbreite oder " +"monatlichen Datenverkehr](/relay/setup/post-install/) verwendet." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -649,6 +656,8 @@ msgid "" "Every relay needs a public IPv4 address - either directly on the host " "(preferred) or via NAT and port forwarding." msgstr "" +"Jedes Relay benötigt eine öffentliche IPv4-Adresse - entweder direkt auf dem" +" Host (bevorzugt) oder über NAT und Anschluss-Weiterleitung." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -656,6 +665,8 @@ msgid "" "The IPv4 address is not required to be static but static IP addresses are " "preferred." msgstr "" +"Die IPv4-Adresse muss nicht statisch sein, aber statische IP-Adressen werden" +" bevorzugt." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -665,6 +676,10 @@ msgid "" " relay or bridge there since it takes time to distribute the new list of " "relay IPs to clients - which happens only once every hour)." msgstr "" +"Deine IPv4-Adresse sollte mindestens 3 Stunden lang unverändert bleiben " +"(wenn sie sich regelmäßig öfter ändert, macht es wenig Sinn, dort ein Relay " +"oder eine Brücke zu betreiben, da es Zeit braucht, die neue Liste der Relay-" +"IPs an die Clients zu verteilen - was nur einmal pro Stunde geschieht)." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -672,6 +687,8 @@ msgid "" "Additional IPv6 connectivity is great and recommended/encouraged but not a " "requirement." msgstr "" +"Zusätzliche IPv6-Konnektivität ist großartig und wird empfohlen bzw. " +"angeregt, ist aber keine Voraussetzung." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -679,17 +696,23 @@ msgid "" "There should be no problem at all with this requirement (all commercially " "available servers come with at least one IPv4 address)." msgstr "" +"Mit dieser Voraussetzung dürfte es überhaupt kein Problem geben (alle " +"kommerziell verfügbaren Server haben mindestens eine IPv4-Adresse)." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "Note: You can only run two Tor relays per public IPv4 address." msgstr "" +"Hinweis: Du kannst nur zwei Tor-Relays pro öffentlicher IPv4-Adresse " +"betreiben." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "" "If you want to run more than two relays you will need more IPv4 addresses." msgstr "" +"Wenn du mehr als zwei Relays betreiben willst, brauchst du mehr " +"IPv4-Adressen." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -701,18 +724,23 @@ msgstr "# Speicher Anforderungen" msgid "" "* A <40 Mbit/s non-exit relay should have at least 512 MB of RAM available." msgstr "" +"* Ein <40 Mbit/s Non-Exit-Relay sollte mindestens 512 MB RAM zur Verfügung " +"haben." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "" "* A non-exit relay faster than 40 Mbit/s should have at least 1 GB of RAM." msgstr "" +"* Ein Non-Exit-Relay, das schneller als 40 Mbit/s ist, sollte mindestens 1 " +"GB RAM haben." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "" "* On an exit relay we recommend at least 1.5 GB of RAM per tor instance." msgstr "" +"* Bei einem Exit-Relay empfehlen wir mindestens 1,5 GB RAM pro Tor-Instanz." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -722,7 +750,7 @@ msgstr "# Festplatten Speicher" #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "Tor does not need much disk storage." -msgstr "" +msgstr "Tor benötigt nicht viel Festplattenspeicher." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -730,6 +758,8 @@ msgid "" "A typical Tor relay needs less than 200 MB for Tor related data (in addition" " to the operating system itself)." msgstr "" +"Ein typisches Tor-Relay benötigt weniger als 200 MB für Tor-bezogene Daten " +"(zusätzlich zum Betriebssystem selbst)." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -739,7 +769,7 @@ msgstr "# CPU" #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "* Any modern CPU should be fine." -msgstr "" +msgstr "* Jede moderne CPU sollte funktionieren." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body)

1 0

[translation/communitytpo-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-contentspot
by translation＠torproject.org 03 Feb '20

03 Feb '20

commit 795cd5261df10be671fb905dd4b001da240b0c02 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Feb 3 21:15:26 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-conten… --- contents+de.po | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/contents+de.po b/contents+de.po index 380021e9b3..791cdc858e 100644 --- a/contents+de.po +++ b/contents+de.po @@ -585,6 +585,9 @@ msgid "" "If you have less than 10 Mbit/s but at least 1 Mbit/s we recommend you run a" " [bridge with obfs4 support](relay/setup/bridge)." msgstr "" +"Wenn du weniger als 10 Mbit/s, aber mindestens 1 Mbit/s hast, empfehlen wir " +"dir, eine [Brücke mit obfs4-Unterstützung] (relay/setup/bridge) zu " +"betreiben." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -592,11 +595,13 @@ msgid "" "If you do not know your bandwidth you can use http://beta.speedtest.net to " "measure it." msgstr "" +"Wenn du deine Bandbreite nicht kennst, kannst du sie mit " +"http://beta.speedtest.net messen." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) msgid "# Monthly Outbound Traffic" -msgstr "" +msgstr "# Monatlicher ausgehender Verkehr" #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body) @@ -604,6 +609,8 @@ msgid "" "It is required that a Tor relay be allowed to use a minimum of 100 GByte of " "outbound traffic (and the same amount of incoming traffic) per month." msgstr "" +"Es ist erforderlich, dass ein Tor-Relay mindestens 100 GByte ausgehenden " +"Verkehr (und die gleiche Menge eingehenden Verkehrs) pro Monat nutzen darf." #: https//community.torproject.org/relay/relays-requirements/ #: (content/relay-operations/relays-requirements/contents+en.lrpage.body)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits February 2020