Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-02-27T18:20:31Zhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/52Translate GetTor messages2024-02-27T18:20:31ZtraumschuleTranslate GetTor messagesThis is the parent ticket to translate GetTor into more languages, especially for censored areas.This is the parent ticket to translate GetTor into more languages, especially for censored areas.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40021json state-of-censorship should include Snowflake lines2022-03-24T09:54:34ZRoger Dingledinejson state-of-censorship should include Snowflake linesCurrently https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json has no mention of Snowflake. We should fix that! :)Currently https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json has no mention of Snowflake. We should fix that! :)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/22Get more private bridges2023-08-07T11:18:19ZCecylia 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. (meskio)
- [x] Ask organizations to run obfs4 bridges (gus)
- [x] Check with the donated hw we may get (gaba)
_Update on October 12th: Documentation is the only issue missing here._Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40059Change how Snowflake handles client arguments2022-03-02T15:29:57ZCecylia BocovichChange how Snowflake handles client arguments@richard just pointed out on IRC that the way Snowflake's client-side arguments are passed to the executable make them difficult to dynamically change through Tor Browser's preferences. For Snowflake, these are specified through the `Cli...@richard just pointed out on IRC that the way Snowflake's client-side arguments are passed to the executable make them difficult to dynamically change through Tor Browser's preferences. For Snowflake, these are specified through the `ClientTransportPlugin` torrc option in the [`torrc-defaults`](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/5e61e15a2b71412538b3be5e9b62180f4d2686ce/projects/tor-browser/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix) file:
```
## obfs4proxy configuration
ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec ./TorBrowser/Tor/PluggableTransports/obfs4proxy
## snowflake configuration
ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports/snowflake-client -url https://snowflake-broker.torproject.net.global.prod.fastly.net/ -front cdn.sstatic.net -ice stun:stun.l.google.com:19302,stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
```
Bridge lines, on the other hand, are specified in a seperate torrc file. See the [built-in preferences](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/5e61e15a2b71412538b3be5e9b62180f4d2686ce/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js) for obfs4 and snowflake bridges.
Right now the only way to make changes to Snowflake client-side options (which have a huge impact on censorship) is to ship a new verison of Tor Browser or tell users to manually modify their torrc files.
@dcf also mentioned in !50 that we need to reconsider command-line options for Snowflake with the addition of new rendezvous methods. This is a related concern and we should make sure that how we chose to move forward works well with this scenario.
One option would be to instead specify command-line arguments through the pluggable transport specification PT args (as obfs4 does with the `cert` and `iat-mode` arguments). I haven't tried this, so I'm not sure it would work if two different bridge lines have the same fingerprint, but I believe it would allow us to specify multiple Snowflake configurations as separate bridges:
```
Bridge snowflake 192.0.2.3:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.l.google.com:19302
Bridge snowflake 192.0.2.3:2 2B280B23E1107BB62ABFC40DDCC8824814F80A72 ampcache=https://cdn.ampproject.org/ ice=stun:stun.l.google.com:19302
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/49O2.1: Make it easier for humans & harder for censors to get bridges from moat...2024-02-27T18:18:49ZGabagaba@torproject.orgO2.1: Make it easier for humans & harder for censors to get bridges from moat distributor.Moat is a tool used inside Tor Browser for users to request bridges when Tor is censored. Moat uses CAPTCHAs in an attempt to prevent censors from using bots to obtain too many bridge IP addresses. The current CAPTCHA solution is too eas...Moat is a tool used inside Tor Browser for users to request bridges when Tor is censored. Moat uses CAPTCHAs in an attempt to prevent censors from using bots to obtain too many bridge IP addresses. The current CAPTCHA solution is too easy for bots and too difficult for many people, particularly non-English native speakers, to solve. In this Activity, we will implement a different CAPTCHA solution that is harder for bots and easier for humans.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2022-04-01https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/48O2.2: Deploy improved bridge distribution systems.2022-02-28T17:04:10ZGabagaba@torproject.orgO2.2: Deploy improved bridge distribution systems.
- O2.2.1.: Deploy the Salmon bridge distribution system. Salmon, originally proposed in a research paper at PETS’16,1 is an innovative new bridge distribution method designed to make it significantly harder for the GFW to learn about an...
- O2.2.1.: Deploy the Salmon bridge distribution system. Salmon, originally proposed in a research paper at PETS’16,1 is an innovative new bridge distribution method designed to make it significantly harder for the GFW to learn about and block obfs4 bridges. With Salmon, users are assigned a reputation score that goes down when one of their bridges is blocked, and it goes up if their assigned bridges remain unblocked. If a user's reputation score gets too low, the user gets blocked, and if it gets high enough, the user can invite others to the system. In order to deploy Salmon, we need to build a solution to test the reachability of the bridges it distributes. Knowing whether a bridge is blocked or unblocked is critical to the reputation system. In this Activity, we will run our 'bridgestrap' reachability testing tool on a VPS in China to feed reachability information back to Salmon.
- O2.2.2: Deploy next generation bridge distribution system (rdsys). The tool rdsys2 is the replacement of an aging bridge distribution system. rdsys will do something new—use the reachability data collected by the mechanism created in O2.2.1 to make decisions about which bridges to hand to users. This is a critical improvement, as rdsys will have the capacity to hand out bridges that are not blocked in the user’s location. The ability to use reachability data in a feedback loop also means a faster response to blocking. We can eliminate blocked bridges from the pool while cycling in unblocked bridges. In this Activity we will: improve the quality of code and documentation, conduct usability tests, and add comprehensive metrics to rdsys. We need high-quality metrics to learn what works and doesn’t work for users.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/47Sponsor 96 - Objective 2: Improve the bridge distribution systems so that it’...2024-01-08T16:37:06ZGabagaba@torproject.orgSponsor 96 - Objective 2: Improve the bridge distribution systems so that it’s harder for censors to learn and block bridges and easier for users to get them.- O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor.
- O2.2: Deploy improved bridge distribution systems.
- O2.3: React and steer our response to censorship.
Circumventing the Great Firewal...- O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor.
- O2.2: Deploy improved bridge distribution systems.
- O2.3: React and steer our response to censorship.
Circumventing the Great Firewall is a dynamic and interactive process. Throughout this project, we will need to adapt our roadmaps as the censor takes steps in response to our tools. Staying agile means maintaining relationships with user communities and with researchers, and having short feedback loops so we can quickly gather information and act on it. To succeed in the face of this uncertainty about the censor's actions, we will: proactively watch the patterns of bridges and users to notice anomalies; understand the political context to have a sense of when large-scale blocking events are more likely; help DPI researchers like Geneva1 make their tools practical; and maintain awareness of GFW blocking behaviors so we can make robust choices about how to change our protocols.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40056O1.2: Increase the number of Snowflake proxies.2022-07-05T18:08:28ZGabagaba@torproject.orgO1.2: Increase the number of Snowflake proxies.With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thou...With limited ramp up so far, we already have 6,000 volunteers running Snowflakes. Increasing Snowflake operators through more aggressive promotion will allow us to rapidly increase unblocked bridge entry points to the Tor network by thousands.
- O1.2.1: Run a public campaign to encourage Internet users to install the Snowflake extension in Firefox or Chrome and use their web browser to act as bridges for censored people. This campaign will target individuals who care about free access to information but who may have limited capacity to operate a traditional bridge.
- O1.2.2: Scale Tor reachability through mobile Snowflakes. It’s also possible to build the Snowflake into mobile applications. We can rapidly increase the availability and diversity of bridge IP addresses that are not blocked in China by asking the millions of active Orbot users to “help censored users connect to Tor.” Through the Internews DISRUPT program, Guardian Project is designing and implementing “Orbot as Bridge” capability with the use of Snowflake, and as a result of this Activity, any Orbot user will be able to become a Snowflake bridge to Tor when they are not actively using their device. Guardian Project is also implementing as much of this capability as possible in Onion Browser for iOS.1 To do so, Guardian Project will: continue to improve Tor+Snowflake stability & performance on mobile devices and tune mobile-as-Snowflake bridge usability and performance, especially considering connections from the target regions.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2022-12-31https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40003O1.4: Increase the number of active obfs4 bridges.2024-02-27T18:18:52ZGabagaba@torproject.orgO1.4: Increase the number of active obfs4 bridges.Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 bridges running on unblocked IP addresses. We have two strategi...Individuals running more Snowflake proxies is one strategy to increase the number of unblocked bridges to the Tor network. The second step is to increase the number of obfs4 bridges running on unblocked IP addresses. We have two strategies in mind for rapidly increasing these numbers:
- O1.4.1 Increase the number of dynamic bridges run by nonprofit partners. The Tor community has a close relationship with trusted relay operator nonprofits1 that run groups of relays, bridges, and exits. We will ask our relay operator nonprofit partners to set up new bridges, with the specific goal of spinning up new bridges when current ones get blocked, and taking blocked bridges offline. We will offer subsidies to trusted relay nonprofits in order to offset some of their infrastructure costs so that this effort can scale rapidly. We will monitor operation costs after scaling to develop a financial plan for long term sustainability together with these nonprofits.
- O1.4.2: Run a public campaign to encourage new individual operators to establish bridges. This campaign will target individuals and nonprofits who are part of the Internet freedom community, like free software advocates, relay associations, technical collectives, and hosting companies. In a previous DRL project titled Empowering Communities in the Global South to Bypass Censorship, we ran a bridge campaign2 and added approximately 100 obfs4 bridges to the network, and we know this strategy is effective in growing the capacity of bridge bandwidth resources.
- O1.4.3: Monitor bridge health. We will build continuous communication with bridge operators, sharing updates with them so they can update bridge configurations so they continue to work in target countries as new blocking attempts are deployed by CCP.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/16Sponsor 96 - Objective 4: Surge by deploying region-specific and varied outre...2023-12-20T05:45:10ZGabagaba@torproject.orgSponsor 96 - Objective 4: Surge by deploying region-specific and varied outreach, and distribution localized efforts.- O4.1: Localize all UI modified in this project.
- O4.2 Create and publish user documentation.
- O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps.
- O4.4: Build region-specific outreach, distribution, and use...- O4.1: Localize all UI modified in this project.
- O4.2 Create and publish user documentation.
- O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps.
- O4.4: Build region-specific outreach, distribution, and user support.
- O4.5: Conduct end-user feedback collection and usability research.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2023-12-21https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/15Sponsor 96 - Objective 3: Update a diverse set of proven open source circumve...2024-02-27T18:12:37ZGabagaba@torproject.orgSponsor 96 - Objective 3: Update a diverse set of proven open source circumvention applications so they are compatible with new bridges and censorship resistance/detection techniques.The Tor Project and its partners in this project have developed a set of applications that are proven to be useful for human rights defenders and their organizations, journalists, whistleblowers, and activists living under censorship and...The Tor Project and its partners in this project have developed a set of applications that are proven to be useful for human rights defenders and their organizations, journalists, whistleblowers, and activists living under censorship and surveillance in China and other places around the world. The goal of this objective is to enhance these applications with our new bridges and censorship resistance/detection techniques. We will also execute a push to bring these apps to the mobile experience, as China, Hong Kong, and Tibet are mobile-first cultures
We have focused on mobile so heavily because most of our target users use mobile devices because they are less expensive and easier to acquire than desktops. Mobile devices are not only phones--this also includes all devices that run on Android, like tablets and televisions, and our project is designed to run across platforms whenever possible. We acknowledge that there can be challenges to focusing on mobile devices, because the censors are also focusing on phones. In some regions law enforcement requires certain apps be installed on every phone. When we build our tools, we are considering this threat environment and thinking about how to get around this kind of detection. All of this work will benefit desktop circumvention as well.
- O3.1: Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android).
- O3.2: Integrate Snowflake into Tor Browser stable.
- O3.3: Improve automatic censorship detection in OnionShare desktop.
- O3.4: Integrate Tor into CalyxOS.
- O3.5: Integrate Tor+Snowflake/obfs4 capabilities into mobile applications.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40026Sponsor 96 - Objective 2: Improve the bridge distribution systems so that it’...2021-07-20T18:59:06ZGabagaba@torproject.orgSponsor 96 - Objective 2: Improve the bridge distribution systems so that it’s harder for censors to learn and block bridges and easier for users to get them.- O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor.
- O2.2: Deploy improved bridge distribution systems.
- O2.3: React and steer our response to censorship.- O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor.
- O2.2: Deploy improved bridge distribution systems.
- O2.3: React and steer our response to censorship.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/14Sponsor 96 - Objective 1: Implement new pluggable transports and more bridges...2023-07-31T11:05:52ZGabagaba@torproject.orgSponsor 96 - Objective 1: Implement new pluggable transports and more bridges that are harder for censors to block to the Tor network.* [O1.1: Prepare Snowflake to handle a surge of operators and users](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40066).
* [O1.2: Increase the number of Snowflake bridges](https://gitlab.torp...* [O1.1: Prepare Snowflake to handle a surge of operators and users](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40066).
* [O1.2: Increase the number of Snowflake bridges](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40056).
* O1.2.1: Run a public campaign to encourage Internet users to install the Snowflake extension
* O1.2.2: Scale Tor reachability through mobile Snowflakes.
* [O1.3: Implement bridges with pluggable transport HTTPT support](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/7).
* O1.4: Increase the number of active [obfs4](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/40003) and [HTTPT](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/8) bridges.
* [O1.4.1: Increase the number of dynamic bridges run by nonprofit partners](https://gitlab.torproject.org/tpo/community/outreach/-/issues/40009).
* [O1.4.2: Run a public campaign to encourage new individual operators to establish bridges](https://gitlab.torproject.org/tpo/community/outreach/-/issues/40010).
* [O1.4.3: Monitor bridge health](https://gitlab.torproject.org/tpo/community/relays/-/issues/21)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet2023-08-01https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40055Standalone proxy reconnects in a tight loop when server refuses connection2022-10-11T19:44:19ZDavid Fifielddcf@torproject.orgStandalone proxy reconnects in a tight loop when server refuses connectionRun the proxy and let it connect to a broker port that refuses connections. After the probetest (about 30 s), it starts trying to poll the broker in a tight loop. We should probably wait at least `pollInterval` between connection attempt...Run the proxy and let it connect to a broker port that refuses connections. After the probetest (about 30 s), it starts trying to poll the broker in a tight loop. We should probably wait at least `pollInterval` between connection attempts in case of error.
```
snowflake/proxy$ ./proxy -broker http://localhost:9999/ 2>&1 | head -n 50
2021/07/19 18:00:04 starting
2021/07/19 18:00:04 WebRTC: Created offer
2021/07/19 18:00:04 WebRTC: Set local description
2021/07/19 18:00:04 Offer: {...}
2021/07/19 18:00:35 error polling probe: http2: timeout awaiting response headers
2021/07/19 18:00:35 NAT type: unknown
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
2021/07/19 18:00:35 Error reading broker response: unexpected end of JSON input
2021/07/19 18:00:35 body:
2021/07/19 18:00:35 bad offer from broker
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
2021/07/19 18:00:35 Error reading broker response: unexpected end of JSON input
2021/07/19 18:00:35 body:
2021/07/19 18:00:35 bad offer from broker
2021/07/19 18:00:35 error polling broker: dial tcp [scrubbed]: connect: connection refused
...
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40025Make available our censorship snapshot over a domain-fronted URL2022-03-25T10:35:40ZPhilipp Winterphw@torproject.orgMake available our censorship snapshot over a domain-fronted URLOver at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use th...Over at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use this snapshot to help the user figure out what circumvention method works. The question is: how does Tor Browser get this snapshot? It's not a good idea to hard-code it into Tor Browser because it will take a long time to update it. It's probably better for Tor Browser to fetch the snapshot each time it starts.
To guarantee that Tor Browser can always get the snapshot, even in the face of censorship, we should serve it over a domain-fronted endpoint, like we do for moat. There are several ways in which we could serve the snapshot:
* Polyanthum, the host that runs BridgeDB and rdsys, runs an Apache reverse proxy. We could serve the snapshot directly over Apache, which is probably the simplest solution.
* We could also teach rdsys how to serve the snapshot. Technically, the snapshot is a resource and rdsys is our resource distribution system.
Whatever solution we go with, we should make sure that we can easily and quickly update the snapshot if we learn of a new censorship event.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/43add more providers to gettor updater2022-06-23T17:14:15Zmeskiomeskio@torproject.orgadd more providers to gettor updaterThe new gettor updater only uses github as provider. We should have at least the same ones we had in the old gettor:
* [x] github
* [x] gitlab
* [x] internet archive
* [x] google driveThe new gettor updater only uses github as provider. We should have at least the same ones we had in the old gettor:
* [x] github
* [x] gitlab
* [x] internet archive
* [x] google driveSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/41gettor should automatically include bridges in its answer2022-04-07T16:08:31ZRoger Dingledinegettor should automatically include bridges in its answerIf somebody gettors from their gmail address, we should go to bridgedb and fetch the bridges they would have gotten, and include them in the text we mail back.
To finish this ticket we'll need to reenable dkim checking on gettor mails (...If somebody gettors from their gmail address, we should go to bridgedb and fetch the bridges they would have gotten, and include them in the text we mail back.
To finish this ticket we'll need to reenable dkim checking on gettor mails (which is part of legacy/trac#3381), but we'll also need to come up with some sort of secure way to ask bridgedb for its answer.
I expect that second step to be messy, so marking this ticket 'minor' priority.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/36Build a bridge censorship measurement system for Salmon2023-03-24T16:02:19ZPhilipp Winterphw@torproject.orgBuild a bridge censorship measurement system for SalmonSalmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestr...Salmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
1. We could set up [bridgestrap](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) instances in censored networks and design a control channel between our central rdsys instance and the various bridgestrap instances. [wolpertinger](https://gitlab.torproject.org/tpo/anti-censorship/wolpertinger) was originally designed for that and we may be able to reuse some ideas and code. See tpo/anti-censorship/censorship-analysis#34258 for more details.
1. We can outsource the problem to OONI. That was the original plan but OONI probes are run by untrusted strangers, some of which could be censors that try to find and block bridges. OONI, at least in its current form, is therefore not a good choice.
1. We could incorporate passively-gathered data like the countries from which bridges have recently seen clients.
Option 1) strikes me as a good way forward because we already have a lot of the necessary code in place. Essentially, we still need a low-bandwidth, low-latency, censorship-resistant communication channel between bridgestrap instances in various countries and rdsys. If we go down that route, a few more questions emerge:
* Should the bridgestrap instances periodically poll for new bridges to test? Or should rdsys push these bridges to bridgestrap?
* What should the censorship-resistant communication channel look like? A domain-fronted API like moat may be good enough.
* How should rdsys communicate with these bridgestrap instances? Should it implement a new distributor like wolpertinger? Or should this functionality live in the backend? For what it's worth, rdsys's [bridge testing mechanism](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/master/doc/resource-testing.md) lives in the backend.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/35Deploy the Lox bridge distribution mechanism2023-03-24T16:00:46ZPhilipp Winterphw@torproject.orgDeploy the Lox bridge distribution mechanismThis is a meta issue to track our development and deployment of Lox. Let's close this issue once all child issues are taken care of, and Salmon is running in production.This is a meta issue to track our development and deployment of Lox. Let's close this issue once all child issues are taken care of, and Salmon is running in production.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/34Make available our censorship snapshot over a domain-fronted URL2021-10-20T12:13:04ZPhilipp Winterphw@torproject.orgMake available our censorship snapshot over a domain-fronted URLOver at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use th...Over at tpo/community/outreach#28531, we're working on a [censorship snapshot](https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/) that summarises where and how Tor is blocked. The idea is that Tor Browser will use this snapshot to help the user figure out what circumvention method works. The question is: how does Tor Browser get this snapshot? It's not a good idea to hard-code it into Tor Browser because it will take a long time to update it. It's probably better for Tor Browser to fetch the snapshot each time it starts.
To guarantee that Tor Browser can always get the snapshot, even in the face of censorship, we should serve it over a domain-fronted endpoint, like we do for moat. There are several ways in which we could serve the snapshot:
* Polyanthum, the host that runs BridgeDB and rdsys, runs an Apache reverse proxy. We could serve the snapshot directly over Apache, which is probably the simplest solution.
* We could also teach rdsys how to serve the snapshot. Technically, the snapshot is a resource and rdsys is our resource distribution system.
Whatever solution we go with, we should make sure that we can easily and quickly update the snapshot if we learn of a new censorship event.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet