Report for Sponsor 28 for Q4 2022

@itchyonion @arma We need to gather all the work we can report for sponsor 28 for the period October to December 2022. We will send it to Micah on the week of January 10th.

changed due date to January 13, 2023

added Next Sponsor 28 - FINISHED labels

assigned to @itchyonion

@itchyonion @arma did you see this issue?

For my part:

• RACE work:
  • Traced and resolved the issue(not enough proxies) causing snowflake to fail under heavy load tests
  • Further improved snowflake performance for integration tests
  • Routinue maintainance work (upgrading API, etc)
• Tor work:
  • Improved parsing of Snowflake config file
  • Fixed incorrect documentation about Snowflake capabilities
  • Various logging improvements (always display NAT type, consistent logging vebosity, etc)

added Doing label and removed Next label

Here are some more Q4 activities worth including:

(A) Improved bridge handling, toward being able to support something like Salmon:

• More design work on the 'subscription model' automatic bridge replacement ideas.

  • #42
  • censorship-analysis#40035
  • tpo/operations/team#6 (closed)

• Starting to identify practical utility functions for assessing bridge strategies:

  • tpo/network-health/metrics/relay-search#40019

(B) Much tuning and investigating and debugging and interacting to understand and support the use of Snowflake in Iran.

• We worked on scaling:

  • tpo/anti-censorship/pluggable-transports/snowflake#40207 (closed)

• We worked on better resistance to DPI and blocking, e.g. by updating and turning on utls-imitate to make the domain fronting connection more robust:

  • #96 (closed)
  • tpo/anti-censorship/pluggable-transports/snowflake#40217 (closed)

• We worked on understanding the Snowflake and obfs4 growth and blocking trends in Q4, focusing on Iran, Russia, and China:

  • #92 (closed)
  • https://gitlab.torproject.org/ahf/onion-tex/-/tree/main/src/pandoc/arma-internet-freedom-2022

• We deployed a second Snowflake back-end server, hosted at Michigan, for redundancy and for scalability:

  • tpo/anti-censorship/pluggable-transports/snowflake#28651 (closed)
  • tpo/anti-censorship/pluggable-transports/snowflake#40122 (closed)

  In the short term, this now means that every Snowflake user will contact the broker separately for each of these bridges, leading to double client load compared to before. We will need to make some changes inside Tor or Tor Browser before we add more Snowflake back-end servers:

  • tpo/core/tor#40578 (comment 2849105)

(C) We did an overhaul of our internal email infrastructure, with the goal of having our emails accepted more consistently by third-party mailservers. One benefit here is that BridgeDB emails to gmail should be arriving successfully again.

(D) Motivated by discussions with two-six about the best way to add new signaling channels to Tor Browser, we began internal brainstorming about new workflows: "Unify (access to) the Tor Browser signaling channels":

• #111

Thanks @itchyonion and @arma ! We will send all this to the report.

closed

removed Doing label