... | ... | @@ -27,41 +27,64 @@ For asynchronous communication, we use our [anti-censorship-team](https://lis |
|
|
|
|
|
## Priorities for 2022
|
|
|
|
|
|
- make Tor accessible in China
|
|
|
- detect and categorize attempts to censor Tor
|
|
|
- improve the design and reliability of our software
|
|
|
- release our data and software for use by the broader anti-censorship community
|
|
|
- improve the performance of Snowflake so that Tor bootstraps reliably on a mobile phone in China
|
|
|
- deploy TapDance and Conjure as high collateral damage PT
|
|
|
- commit to a design for a reputation-based bridge distribution system
|
|
|
- streamline our private bridge setup and distribution process
|
|
|
- deploy probes in areas that are likely to censor Tor and collect pack captures and probe results for storage and analysis
|
|
|
- provide OONI with suggestions for improving the accuracy of OONI's Tor tests
|
|
|
- summarize the details of Tor blocking events with data from our probes and volunteers
|
|
|
- add more user metrics based monitoring and alert rules using prometheus
|
|
|
- deploy rdsys ad the new backend of bridgedb
|
|
|
- ensure that key infrastructure can survive machine outages and restarts
|
|
|
- remove hacky shims necessary for moat
|
|
|
- future improve the snowflake library api to allow easy integration of snowflake with other tools
|
|
|
- sanitize, publish and archive the results of our Tor reachability probes
|
|
|
- complete our documentation for each of our tools so that other organizations can run their own anti-censorship infrastructure
|
|
|
|
|
|
## Roadmap
|
|
|
[Priorities for previous years](previous-priorities)
|
|
|
|
|
|
### Q1
|
|
|
## Roadmap
|
|
|
|
|
|
* s30 O2.3.1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1.
|
|
|
* s30 conjure (2 months) - cecylia starting in March
|
|
|
* server side : the university
|
|
|
* start talking again with eric and his team
|
|
|
* define server side for them to setup bridge (documentation)
|
|
|
* client side : around 2 weeks
|
|
|
* write a conjure client based on their specification (tor pt part with their client side library)
|
|
|
* staging/testing
|
|
|
* deployment
|
|
|
* add it to alpha version of TB
|
|
|
* metrics (discuss with people that maintain conjure bridge)
|
|
|
* how many clients are connected
|
|
|
## Q3
|
|
|
|
|
|
* sponsor 30
|
|
|
* O2.3.1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1.
|
|
|
* conjure (2 months) (cecylia) <-- maintenance in Q3.
|
|
|
* https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards?label_name[]=Sponsor%2030
|
|
|
|
|
|
* sponsor 96
|
|
|
* O1.1.1 Prepare the Snowflake system for a surge in operators and users. <-- deployed snowflake broker in Q2.
|
|
|
* next in Q3:
|
|
|
* proxies need to be updated to next version.
|
|
|
* setup new bridges.
|
|
|
* O1.3: Implement bridges with pluggable transport HTTPT support. <--Q3 (Shell)
|
|
|
* O1.4: Increase the number of active obfs4 and HTTPT bridges.
|
|
|
* O1.4.3: Monitor bridge health. <-- Meskio with Gus
|
|
|
* obfsproxy security issues - meskio Q3
|
|
|
* O2.2: Deploy improved bridge distribution systems.
|
|
|
* Salmon based design: Roger on Q3.
|
|
|
* rdsys DB for bridges (meskio) Q3
|
|
|
* O2.3: React and steer our response to censorship. (Shell) - Q3
|
|
|
* vantage points in specific places
|
|
|
* O4.1: Localize all UI modified in this project. (meskio) Q3
|
|
|
* Q3 Localize gettor.
|
|
|
* Q3 Bot Telegram.
|
|
|
* O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps
|
|
|
* support onionsprout deployment - It was deployed in Q2
|
|
|
* get gettor into rdsys - implemented in Q2. Deployment in Q3.
|
|
|
* https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards?label_name[]=Sponsor%2096
|
|
|
|
|
|
* sponsor 28 (itchyonion) & extension (shel)
|
|
|
* probetest centralized log collection (shell) Q3
|
|
|
|
|
|
* s96 O1.1.1 Prepare the Snowflake system for a surge in operators and users. <-- scale in Q1/Q2 2022 <-- shell
|
|
|
* s96 O1.2: Increase the number of Snowflake bridges.
|
|
|
* s96 O1.2.2: Scale Tor reachability through mobile Snowflakes. <-- support to GP
|
|
|
* s96 O1.4: Increase the number of active obfs4 and HTTPT bridges.
|
|
|
* s96 O1.4.3: Monitor bridge health. <-- Meskio/Shel with Gus
|
|
|
* s96 O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor. <-- Q1
|
|
|
* s96 O2.2: Deploy improved bridge distribution systems.
|
|
|
* s96 O2.2.2: Deploy next generation bridge distribution system (rdsys) <-- meskio -
|
|
|
* s96 O2.3: React and steer our response to censorship. <-- shel
|
|
|
* s96 O3.1: Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android). <-- meskio
|
|
|
|
|
|
* sponsor 28 & extension: we will have the new developer full time into this project.
|
|
|
* sponsor 28 - Improve the performance of Snowflake for users in Asia (cecylia)
|
|
|
|
|
|
## Q2
|
|
|
|
|
|
|
|
|
* sponsor 30 O2.3.1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1. - Implement and deploy conjure - Cecylia
|
|
|
* sponsor 96 O1.1.1 Prepare the Snowflake system for a surge in operators and users. - shel
|
|
|
* sponsor 96 O1.2: Increase the number of Snowflake bridges. - shel
|
... | ... | @@ -79,44 +102,35 @@ For asynchronous communication, we use our [anti-censorship-team](https://lis |
|
|
* sponsor 928 probetest centralized log collection (shel)
|
|
|
* sponsor 125 dynamic bridges
|
|
|
|
|
|
## Q3, Q4
|
|
|
|
|
|
* s96 O1.1.1 Prepare the Snowflake system for a surge in operators and users. <-- scale in Q1/Q2 2022 (shell)
|
|
|
### Q1
|
|
|
|
|
|
* s30 O2.3.1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1.
|
|
|
* s30 conjure (2 months) - cecylia starting in March
|
|
|
* server side : the university
|
|
|
* start talking again with eric and his team
|
|
|
* define server side for them to setup bridge (documentation)
|
|
|
* client side : around 2 weeks
|
|
|
* write a conjure client based on their specification (tor pt part with their client side library)
|
|
|
* staging/testing
|
|
|
* deployment
|
|
|
* add it to alpha version of TB
|
|
|
* metrics (discuss with people that maintain conjure bridge)
|
|
|
* how many clients are connected
|
|
|
|
|
|
* s96 O1.1.1 Prepare the Snowflake system for a surge in operators and users. <-- scale in Q1/Q2 2022 <-- shell
|
|
|
* s96 O1.2: Increase the number of Snowflake bridges.
|
|
|
* s96 O1.2.2: Scale Tor reachability through mobile Snowflakes. <-- support to GP
|
|
|
* s96 O1.3: Implement bridges with pluggable transport HTTPT support. <-- Q2/Q3 (Shell)
|
|
|
* s96 O1.4: Increase the number of active obfs4 and HTTPT bridges.
|
|
|
* s96 O1.4.3: Monitor bridge health. <-- Meskio/Shel with Gus
|
|
|
* s96 O2.1: Make it easier for humans & harder for censors to get bridges from moat distributor. <-- Q1
|
|
|
* s96 O2.2: Deploy improved bridge distribution systems.
|
|
|
* s96 O2.2.1.: Deploy the Salmon bridge distribution system. <-- Start as soon as possible (Meskio & Shell - support from Cecylia)
|
|
|
* s96 O2.3: React and steer our response to censorship. (Shel)
|
|
|
* s96 O4.3: Modify GetTor so that it can distribute Tor Browser via messaging apps <--- we are late - any time during 2022 (meskio)
|
|
|
* s96 O3.1 plan for deprecation of bridgedb (Q4)
|
|
|
* s96 O2.2.2: Deploy next generation bridge distribution system (rdsys) <-- meskio -
|
|
|
* s96 O2.3: React and steer our response to censorship. <-- shel
|
|
|
* s96 O3.1: Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android). <-- meskio
|
|
|
|
|
|
* sponsor 28 & extension: we will have the new developer full time into this project.
|
|
|
|
|
|
## OKRs for Q1 and Q2 2022
|
|
|
|
|
|
- make Tor accessible in China
|
|
|
- detect and categorize attempts to censor Tor
|
|
|
- improve the design and reliability of our software
|
|
|
- release our data and software for use by the broader anti-censorship community
|
|
|
- improve the performance of Snowflake so that Tor bootstraps reliably on a mobile phone in China
|
|
|
- deploy TapDance and Conjure as high collateral damage PT
|
|
|
- commit to a design for a reputation-based bridge distribution system
|
|
|
- streamline our private bridge setup and distribution process
|
|
|
- deploy probes in areas that are likely to censor Tor and collect pack captures and probe results for storage and analysis
|
|
|
- provide OONI with suggestions for improving the accuracy of OONI's Tor tests
|
|
|
- summarize the details of Tor blocking events with data from our probes and volunteers
|
|
|
- add more user metrics based monitoring and alert rules using prometheus
|
|
|
- deploy rdsys ad the new backend of bridgedb
|
|
|
- ensure that key infrastructure can survive machine outages and restarts
|
|
|
- remove hacky shims necessary for moat
|
|
|
- future improve the snowflake library api to allow easy integration of snowflake with other tools
|
|
|
- sanitize, publish and archive the results of our Tor reachability probes
|
|
|
- complete our documentation for each of our tools so that other organizations can run their own anti-censorship infrastructure
|
|
|
|
|
|
[Priorities for previous years](previous-priorities)
|
|
|
* sponsor 28 - Improve the performance of Snowflake for users in Asia (cecylia)
|
|
|
|
|
|
You can follow up what we are working on in this [kanban board](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/groups/tpo/anti-censorship/-/boards).
|
|
|
|
... | ... | |