Hey everyone!
Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-01-18-15.57.html
And our meeting pad:
Anti-censorship work meeting pad -------------------------------- Anti-censorship --------------------------------
Next meeting: Thursday, January 25 16:00 UTC Facilitator: cohosh
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:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from sponsors, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?sc... * Sponsor 96 <-- meskio, shell, onyinyang, cohosh * https://gitlab.torproject.org/groups/tpo/-/milestones/24 * Sponsor 150 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_nam...
== Announcements ==
*
== Discussion ==
* DTLS anti-fingerprinting library similar to uTLS * Useful for snowflake: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... * Sean DuBois (from pion) has been interested in this and may have ideas on what this library could look like * SQS rendezvous deployment * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... * almost ready for final merge, any objections to doing so? * can announce the new rendezvous method on forum and bbs as before with ampcache * will have a look at possible attack by flooding the service to generate significant bill * AWS may or may not support setting billing limits. Can at least set billing alerts. * Possibly use prepaid card with limited funds. * Future plan is to componentize the broker and make rendezvous methods more modular, not part of the SQS work though * https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfla... * Also encrypt rendezvous messages separately from the rendezvous channel, https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfla... * Our docker containers are out of date for snowflake and obfs4 * Have a version of tor that soon will be EOL * shelikhoo will update them from https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge and https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy
== Actions ==
== Interesting links ==
*
== 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-18 Last week: - Lox + Tor Browser integration - Found a fix for snowflake shadow simulations - https://github.com/shadow/shadow/pull/3279 - Contributed to discussion on missing shadow feature policy - https://github.com/shadow/shadow/issues/3280 This week: - Review of final SQS rendezvous changes - Lox + Tor Browser integration - rebase and try out manifest v3 patch - Conjure bridge maintenance Needs help with:
dcf: 2024-01-18 Last week: - started to review draft MR for unreliable data channels, merged cosmetic changes to main https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... - posted summary of snowflake bridge users in 2023 https://forum.torproject.org/t/snowflake-bridge-metrics-2023-year-in-review/... Next week: - review draft MR for unreliable data channels https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... - open issue to disable /debug endpoint on snowflake broker - move snowflake-02 to new VM Help with:
meskio: 2023-12-21 Last week: - grant writing Next week:
Shelikhoo: 2024-01-18 Last Week: - HTTPS distributors in rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/191 - Merge request reviews Next Week/TODO: - HTTPS distributors in rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/191 - update container image for snowflake-proxy and obfs4-proxy
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
theodorsm: 2023-01-11 Last weeks: - Currently in the start phase of writing my master thesis (to be finished late june 2024) in communication technology on reducing distinguishability of DTLS. The goal is to implement a validated DTLS anti-fingerprinting library similar to uTLS (useful for Snowflake). Next weeks: - Talk with Sean DuBois about contributing to adding anti-fingerprinting capabilities to the pion library Help with: - Find recent data set of captured DTLS traffic
(long term things were discussed at the meeting!): https://pad.riseup.net/p/tor-ac-community-azaleas-room-keep - 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?