The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-07-18T20:33:30Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12957Translation instruction about accesskey should be improved.2022-07-18T20:33:30ZTracTranslation instruction about accesskey should be improved.Here is an example:
Key: %sJ%sust give me bridges!
Occurrences: lib/bridgedb/templates/options.html:38
Resource: BridgeDB - bridgedb.pot
Developer note: TRANSLATORS: Please make sure the '%s' surrounding single letters at the be...Here is an example:
Key: %sJ%sust give me bridges!
Occurrences: lib/bridgedb/templates/options.html:38
Resource: BridgeDB - bridgedb.pot
Developer note: TRANSLATORS: Please make sure the '%s' surrounding single letters at the beginning of words are present in your final translation. Thanks! (These are used to insert HTML5 underlining tags, to mark accesskeys for disabled users.)
Two issues about the note:
1. For double-byte languages, e.g. Chinese/Japanese, there is no letter at the beginning of word.
2. For other languages, there might be two translated strings have the same "%sJ%s" in the same page.
My suggestion:
For issue 1, add "%sJ%s" at the end of sentence.
For issue 2, let's say, all acesskeys should not be changed when the strings are localized. If the first letters in English string and the translated string are different, then add "%sJ%s" at the end of sentence. When they happen to be the same letter, the instruction in developer note should be followed.
**Trac**:
**Username**: JasonSponsor 30 - Objective 2.4meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40499"ORConn connect failure cache" interferes with "Optimistically retrying bridges"2022-02-23T20:23:28ZRoger Dingledine"ORConn connect failure cache" interferes with "Optimistically retrying bridges"Tor has an "ORConn connect failure cache", which remembers connection failures to relays, and refuses to connect to those relays during the minute after the failure. We grew this submodule in #24767 (commit f29d1583, went into Tor 0.3.3....Tor has an "ORConn connect failure cache", which remembers connection failures to relays, and refuses to connect to those relays during the minute after the failure. We grew this submodule in #24767 (commit f29d1583, went into Tor 0.3.3.4-alpha) when we noticed that when a popular relay goes down, each EXTEND cell that asks to extend to it results in a new TCP connection attempt, and in the time until clients stop thinking the relay is up, other relays can generate many thousands of connection attempts.
It turns out that our ORConn connect failure cache also caches failures, and blocks reattempts, for when clients attempt to connect to bridges. That is, if you try to connect to your bridge and you fail, and then you try again within a minute, Tor will helpfully refuse to even try, and just mark that connection as a failure (causing you to mark the bridge as down again too).
This is actually potentially a useful feature still. For example, when your bridges are genuinely unreachable, Tor's descriptor fetch retry schedule makes a new connection attempt every 3 seconds or so for the first 30 seconds, and makes something like 15 attempts in the first minute. That's kind of a silly retry rate, and this failure cache prevents clients from actually producing network traffic based on these overeager retries.
But there is one edge case where it is a clear lose: if you go offline, try to connect to your bridge and fail and mark it down and mark yourself offline, and then you come back online soon after and receive a socks request, Tor in circuit_get_open_circ_or_launch() will log about "Optimistically trying known bridges again" and then it will mark all your bridges as maybe up again, to let you try connecting again right then. But if your retry happens within a minute of your failure, the failure cache will kick in, and fail your new attempt, and you'll mark that bridge down and need to wait for that minute to end, and possibly also a new socks request to come in, before you can get unstuck.Sponsor 30 - Objective 2.4Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40001Investigate why some users aren't connecting to our private bridges2022-02-15T13:56:40ZGusInvestigate why some users aren't connecting to our private bridgesIn the last months I've been working on building relationship with relay operators that could run private obfs4 bridges. After getting their bridge address, I provided these private bridges to users in some countries with filtered/censor...In the last months I've been working on building relationship with relay operators that could run private obfs4 bridges. After getting their bridge address, I provided these private bridges to users in some countries with filtered/censored internet (mostly by email/Frontdesk). But after some months, some relay operators told me that didn't see any user connected and they were concerned if that was the best way to use their resources and contribute to the network. The operators ended up switching to a private bridge distributed over HTTPS/Moat. Last time I talked with them, they seemed to be happy with the number of users connected to their bridge.
I also provided my own private bridge to a group of people that we did a bridge workshop and I saw some traffic for a while (some days after the workshop) and then it stopped. So, I guess we need to keep promoting the bridge until is shared more widely in groups.
Lesson learned: In order to have private bridges maintained by the community, we need to match the bridge operator expectation and also add more time to build our own distribution networks on those countries.
Tasks:
* [x] Reach out to users on frontdesk and ask them if everything is ok, and if they tried to connect to the bridge.
* [ ] Contact nonprofits that are working in Global South and ask them if they want a) workshop: learn how to setup private bridge; b) have some private bridges to use.
* [x] We have some user interviews scheduled to the end of this month, and I hope we can get more insights about usability issues that these users are facing.Sponsor 30 - Objective 2.4GusGus2021-02-28https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40030update geoip db2022-02-14T18:16:28Zmeskiomeskio@torproject.orgupdate geoip dbBridgeDB uses maxminddb to get a mapping between IPs and countries, but this DB is not updated anymore. We should use the tor-geoipdb, which will be kept updated.
BridgeDB implements it's own [parser for the maxminddb](https://gitlab.to...BridgeDB uses maxminddb to get a mapping between IPs and countries, but this DB is not updated anymore. We should use the tor-geoipdb, which will be kept updated.
BridgeDB implements it's own [parser for the maxminddb](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main/bridgedb/geo.py), we'll need to update it to the tor-geoipdb format.
For some context on the tor move away of maxminddb: https://gitlab.torproject.org/tpo/core/tor/-/issues/40224Sponsor 30 - Objective 2.455abhilash55abhilashhttps://gitlab.torproject.org/tpo/community/relays/-/issues/22Bridge operators - Number of bridges, network size, and community2022-01-27T01:48:27ZGusBridge operators - Number of bridges, network size, and communityI'm opening this ticket to discuss the current number of Tor bridges and what's or should be the reference number, so we can plan and prioritize actions.
I'm counting the average number of bridges per month instead of looking daily. Th...I'm opening this ticket to discuss the current number of Tor bridges and what's or should be the reference number, so we can plan and prioritize actions.
I'm counting the average number of bridges per month instead of looking daily. The reason is that sometimes people are just 'playing around' or testing how to set up a bridge, and counting that number won't be very helpful.
### Average number of Tor bridges by month (2019 - 2021)
| Month | 2019 | 2020 | 2021 |
| ------ | ------ | ------ | ------ |
| Jan | 915 | 1328 | 1562 |
| Feb | 949 | 1326 | 1563 |
| Mar | 973 | 1345 | 1543 |
| Apr | 985 | 1316 | 1535 |
| May | 1031 | 1259 | 1498 |
| Jun | 1027 | 1340 | 1463 |
| Jul | 1049 | 1450 | 1454 |
| Ago | 1077 | 1554 | |
| Sep | 1155 | 1608 | |
| Oct | 1229 | 1619 | |
| Nov | 1244 | 1634 | |
| Dec | 1286 | 1568 | |
**Source:** [Tor Metrics January 2019 - July 2021](https://metrics.torproject.org/networksize.html?start=2019-01-01&end=2021-07-27)
### Notes
1. In August 2019, we had a Tor Bridge campaign [Run Tor Bridges to Defend the Open Internet](https://blog.torproject.org/run-tor-bridges-defend-open-internet). Here's a summary: https://gitlab.torproject.org/tpo/community/outreach/-/issues/30777#note_2560560 and retrospective https://gitlab.torproject.org/legacy/trac/-/issues/33007.
2. Between September and November 2020, we've reached a peak in the number of bridges.
3. As of December 2020, the number of online bridges started to decrease. In July 2021, we've returned to the same number of bridges as in July 2020.
I think we should discuss:
A. Bridge Operator Retention. In the retrospective it was said that some volunteers were sad because didn't see many users. Maybe we could announce that we're going to select 10 bridge operators to send a Tor swag. That way we reward relay operators who are already part of our community.
B. Number of bridges. How many more bridges do we need/want? Or should we focus on promoting Snowflake add-on?
C. Next Bridge campaign. Should we do a campaign this year?Sponsor 30 - Objective 2.4GusGushttps://gitlab.torproject.org/tpo/community/outreach/-/issues/31877Promote workshops on how to set up a bridge at relay operator meetups2021-12-16T17:13:49ZPhilipp Winterphw@torproject.orgPromote workshops on how to set up a bridge at relay operator meetupsWe should point folks to our [bridge setup guides](https://community.torproject.org/relay/setup/bridge/) during relay operator meetups.We should point folks to our [bridge setup guides](https://community.torproject.org/relay/setup/bridge/) during relay operator meetups.Sponsor 30 - Objective 2.4GusGushttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40010Get more private bridges2021-08-03T16:34:46ZCecylia BocovichGet more private bridgesWe maintain a list of private bridges that we distribute to NGOs and individuals in places that block most of our other distribution methods. BridgeDB sets aside some bridges for private distribution in the "unallocated" or "reserved" po...We maintain a list of private bridges that we distribute to NGOs and individuals in places that block most of our other distribution methods. BridgeDB sets aside some bridges for private distribution in the "unallocated" or "reserved" pool.
At the end of March we are losing some private bridges that volunteers run so we need a few actions to get more private (stable if possible) bridges:
- [ ] Create and document a pipeline for distributing "unallocated" bridges as private bridges. We should document a pipeline for taking bridges the reserved this pool and getting them into the hands of users. (cohosh)
- [ ] Ask organizations to run obfs4 bridges (gus)
- [ ] Check with the donated hw we may get (gaba)Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40013Lost translations on the last release2021-07-16T10:14:43Zmeskiomeskio@torproject.orgLost translations on the last release`bridgedb.test.test_https_server.HowtoResourceTests.test_HowtoResource_render_GET_lang_ru` is [failing in the main branch](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/jobs/20874). It did start failing after we [updated t...`bridgedb.test.test_https_server.HowtoResourceTests.test_HowtoResource_render_GET_lang_ru` is [failing in the main branch](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/jobs/20874). It did start failing after we [updated the translated strings](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/commit/ff2cb23bacc6630122b4b753999347285c285613). It looks like the [rusian translation got deleted](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/commit/ff2cb23bacc6630122b4b753999347285c285613#d22d6f103948abadb3babee394cc2fcde50b7cbe).Sponsor 30 - Objective 2.4meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31281O2.4 - Boost security by increasing the number of bridges run by volunteers a...2021-03-11T17:48:30ZGabagaba@torproject.orgO2.4 - Boost security by increasing the number of bridges run by volunteers and collective entities through improvements to onboarding and better communications.* [x] A1 - Improve documentation on how to set up a bridge server and different pluggable transport bridge servers.
* [x] A2 - Create scripts and configuration code for setting up a bridge on cloud providers to make it easier for operato...* [x] A1 - Improve documentation on how to set up a bridge server and different pluggable transport bridge servers.
* [x] A2 - Create scripts and configuration code for setting up a bridge on cloud providers to make it easier for operators to launch a new bridge.
* [x] A3 - Promote workshops on how to set up a bridge at relay operator meetups.
* [x] A4 - Improve documentation of bridgeDB--the code behind selecting and distributing bridges.
* [x] A5 - Increase stability and resilience of bridge authority and bridgeDB by exploring and implementing decentralizations of those services.
[Milestone](https://gitlab.torproject.org/groups/tpo/-/milestones/6).Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/16Document rdsys's architecture and design2020-11-22T02:55:55ZPhilipp Winterphw@torproject.orgDocument rdsys's architecture and designLet's document rdsys's architecture and design. The documentation has the following purposes:
* Help prospective developers familiarise themselves with rdsys.
* Explain to bridge operators, users, and researchers how bridges are managed....Let's document rdsys's architecture and design. The documentation has the following purposes:
* Help prospective developers familiarise themselves with rdsys.
* Explain to bridge operators, users, and researchers how bridges are managed.
The documentation should go into README.md, a more extensive document in the doc/ directory, and a blog post. Here's a bit of documentation to get us started:
---
## Introduction
* BridgeDB needs an overhaul.
- Code base is complicated and convoluted; difficult to make big changes.
- Antiquated and rigid architecture.
* Been reimplementing the service in Golang.
### Goals
* Zero-latency architecture
* abstract, lightweight, resilient, and extensible design
## Code abstractions
How is the code organised?
* "Clean architecture"
- Code centers around domain logic.
* Rdsys distributes resources to users.
- Resource can be a bridge, proxy, Snowflake, or even Tor Browser links.
## System architecture
What components are there and how do they talk to each other?
<!-- insert architecture diagram -->
### Registration mechanism
* Rdsys supports resources that are not coupled to a tor process. These
resources (e.g. Snowflakes, HTTPT proxies, etc.) can register themselves.
### Microservices
* Backend plus several distributor processes.
* Distributors use an HTTP streaming API to learn about resource updates.
### Distributors
* Will build Salmon for rdsys.
### Feedback loop with OONI
* Hand out bridges to OONI for testing; incorporate results into rdsys. Salmon
actually relies on these results.
### Bridge testing with bridgestrap
* Upon learning about new resources, rdsys tests them via bridgestrap.Sponsor 30 - Objective 2.4Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31878Make BridgeDB and bridge authority more resilient2020-11-20T18:46:03ZPhilipp Winterphw@torproject.orgMake BridgeDB and bridge authority more resilientWe should explore options to decentralise BridgeDB and/or our bridge authority.We should explore options to decentralise BridgeDB and/or our bridge authority.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31876Overhaul BridgeDB's documentation and specification2020-10-29T18:39:08ZPhilipp Winterphw@torproject.orgOverhaul BridgeDB's documentation and specificationBridgeDB's documentation is slightly outdated and its [specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) is severely outdated. It's time to update both.BridgeDB's documentation is slightly outdated and its [specification](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) is severely outdated. It's time to update both.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/community/support/-/issues/28526Document how NGOs can run private obfs4 bridges, and get some doing it2020-09-03T17:26:34ZRoger DingledineDocument how NGOs can run private obfs4 bridges, and get some doing itOne of our eventual goals is to get bridgedb back on its feet, and using bridge distribution strategies that China can't defeat, but in the mean time we should document one approach that should still work: setting up your Tor Browser wit...One of our eventual goals is to get bridgedb back on its feet, and using bridge distribution strategies that China can't defeat, but in the mean time we should document one approach that should still work: setting up your Tor Browser with a private (not publicized) tor bridge.
In particular, we know many NGOs that would be happy to run unpublished obfs4 bridges for their people, and give them private bridge addresses when they visit China.
There are several steps to following through with this idea.
Round one (minimum viable approach):
(1) Document for NGOs how to easily run a few private obfs4 bridges. I've seen some guides floating around but nothing both simple and obviously official.
(2) Document for NGOs how they should get these bridge addresses to their users, and how the users should add them to Tor Browser. On Android it seems that Orbot hooks the "bridge://" url, so sending bridge addresses via signal, email, etc should work: the user clicks on the bridge address, which launches Orbot which adds that bridge to its configuration. Having docs for actual users, with screenshots and stuff, would be the clear next step. On desktop the interface choices are messier: see legacy/trac#28015.
(3) Walk a few NGOs through the process from beginning to end, so we can confirm for ourselves that it works as intended, and so we can have a more direct connection to actual users to get feedback on all angles of the user experience.
Round two (once we like round one):
(4) Document for NGOs how to run a series of obfs4 bridges. This could start with one bridge address per computer, but the longer term answer is to have a single Tor client binding to many bridge addresses, maybe with help from the ISP to point these many bridge addresses to that Tor.
(5) Understand if private bridges actually work in China. Apparently Lantern uses obfs4 and they don't get blocked by DPI, so that's a good start, but I've also heard stories of DPI-based throttling. In step 3 above we'll get some anecdotal answers, but here we should design and deploy some recurring experiments from computers inside China that assess (a) connectivity, (b) whether it can bootstrap, and (c) throughput, through a private bridge.
(6) We should invent and document some best practices for where NGOs ought to run their bridges, and how many bridges they need per user. At the extreme bad end of the spectrum, they would run one bridge and give it to all of the people attending a given training -- and in that case, apart from the obvious "what if one of the users is bad and gets the address blocked" worry, discovering some of the users could lead to discovering other related users. At the other end of the spectrum is one bridge (on its own separate ISP) per user. What are some acceptable solutions in between?Sponsor 30 - Objective 2.4GusGus