[tor-project] Anti-censorship team meeting notes, 2024-01-11

Shelikhoo · January 11, 2024, 4:45pm

Hey everyone!

Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-01-11-15.57.html

And our meeting pad: cohosh

Anti-censorship work meeting pad

···

--------------------------------
Anti-censorship
--------------------------------

Next meeting: Thursday, January 18 16:00 UTC
Facilitator:

Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
(channel is logged while meetings are in progress)

This week's Facilitator: shelikhoo

== Goal of this meeting ==

Weekly check-in about the status of anti-censorship work at Tor.
Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community.

== Links to Useful documents ==
* Our anti-censorship roadmap:
* Roadmap:Development · Boards · Anti-censorship · GitLab
* The anti-censorship team's wiki page:
* Home · Wiki · The Tor Project / Anti-censorship / Team · GitLab
* Past meeting notes can be found at:
* The tor-project Archives
* Tickets that need reviews: from sponsors, we are working on:
* All needs review tickets:
* Merge requests · Anti-censorship · GitLab
* Sponsor 96 <-- meskio, shell, onyinyang, cohosh
* Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet · The Tor Project · GitLab
* Sponsor 150 <-- meskio working on it
* Issues · Anti-censorship · GitLab

== Announcements ==

 \* Since December 2023, getting TLS certificates for subdomains of torproject\.net \(e\.g\. snowflake\-broker\.torproject\.net\) requires asking the sysadmin team to create a CAA record in DNS to authorize a specific account\.
     \* https://gitlab.torproject.org/tpo/tpa/team/-/issues/41462
     \* https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/tls?version_id=41c7dd0c1eb7ea41a7c92b1876a38549749d70bd#certificate-authority-authorization-caa

== Discussion ==

 \* DTLS anti\-fingerprinting library similar to uTLS
     \* Useful for snowflake: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014
     \* Sean DuBois \(from pion\) has been interested in this and may have ideas on what this library could look like

== Actions ==

== Interesting links ==

 \* https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2023-december-update

== Reading group ==
* We will discuss "" on
*
* Questions to ask and goals to have:
* What aspects of the paper are questionable?
* Are there immediate actions we can take based on this work?
* Are there long-term actions we can take based on this work?
* Is there future work that we want to call out in hopes that others will pick it up?

== Updates ==
Name:
This week:
- What you worked on this week.
Next week:
- What you are planning to work on next week.
Help with:
- Something you need help with.

cecylia (cohosh): 2024-01-11
Past weeks:
- Lox + Tor Browser integration
- Lox integration (#116) · Issues · The Tor Project / Anti-censorship / Team · GitLab
- worked on Lox distributor bug fixes and testing
- spun up a few temporary Lox bridges for testing
- integration testing of Snowflake with Shadow
- Use shadow for integration testing in gitlab CI (#40288) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- proxy command-line option to specify probe server URL
- Add proxy commandline option for probe server URL (!232) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- SetNet fix for probetest
- Use SetNet setting in probetest to ignore net.Interfaces error (!233) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- probetest command-line option to specify STUN URL
- Add probetest commandline option for STUN URL (!237) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- opened shadow issue to deal with missing setsockopt support for snowflake
- Snowflake simulation fails to dial OR port · Issue #3278 · shadow/shadow · GitHub
- unit testing feedback on SQS rendezvous MR
- Draft: Implement SQS Rendezvous Method (!214) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
This week:
- Lox + Tor Browser integration
- figure out what we need to get the snowflake server running in shadow again
- rebase and try out manifest v3 patch
- Conjure bridge maintenance
Needs help with:

meskio: 2023-12-21
Last week:
- grant writing
Next week:

Shelikhoo: 2024-01-11
Last Week:
- Work on snowflake performance improvement (WIP): Files · dev-udp-performance-rebased-exp · shelikhoo / Snowflake · GitLab
Draft: Unreliable+unordered WebRTC data channel transport for Snowflake (!219) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- HTTPS distributors in rdsys: Implement HTTPS distributor with comparable feature set to bridgedb implementation (#191) · Issues · The Tor Project / Anti-censorship / rdsys · GitLab
- Merge request reviews
Next Week/TODO:

onyinyang: 2023-01-11
Last week(s):
- Finished Telegram bot dev
- Continue to support Lox wasm stubs as needed
- Holiday!

 This week:
     \- Bug fixing and other things that come up as lox integration is rolled out
     \- document API for lox client/server requests
     \- Other Lox bug fixes/improvements
     \- attempt hyper upgrade again

(long term things were discussed at the meeting!): Riseup Pad
- brainstorming grouping strategies for Lox
buckets (of bridges) and gathering context on how types of bridges are
distributed/use in practice
Question: What makes a bridge usable for a
given user, and how can we encode that to best ensure we're getting the
most appropriate resources to people?
1. Are there some obvious grouping
strategies that we can already consider?
e.g., by PT, by bandwidth (lower
bandwidth bridges sacrificed to open-invitation buckets?), by locale (to
be matched with a requesting user's geoip or something?)
2. Does it make sense to group 3
bridges/bucket, so trusted users have access to 3 bridges (and untrusted
users have access to 1)? More? Less?