Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-10-31-16.00.html
And our meeting pad:
Anti-censorship work meeting pad
···
--------------------------------
Anti-censorship
--------------------------------
Next meeting: Thursday, October 07 16:00 UTC
Facilitator: onyinyang
^^^(See Facilitator Queue at tail)
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 projects, we are working on:
* All needs review tickets:
* Merge requests · Anti-censorship · GitLab
* Project 158 <-- meskio working on it
* Issues · Anti-censorship · GitLab
== Announcements ==
\* eclips\.is \(Snowflake broker hosting\) is switching to a partially paid model \(it has heretofore been free for users\)
\* https://lists.torproject.org/pipermail/anti-censorship-team/2024-October/000362.html
== Discussion ==
\* Snowflake broker transition still pending\.
\* Adding a snowflake transport to lyrebird
\* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/63
\* Squash PTs into Lyrebird: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40015
\* TODOs: add proxy support and event logging
\* We decide is a good idea to integrate the snowflake client into lyrebird
\* we are not removing the snowflake client from the snowflake proyect for now, we'll keep both until it becomes a burden\.
\* only the snowflake client will be integrated in lyrebird, not the server
\* pion/webrtc v4 release is out
\* it has support to integrate with covert\-dtls
\* on the beta testing there were some issues, we'll need to check if it works with the release or it needs work
\* split broker into components
\* there is an old MR with a WIP version of this change
\* we are still interested on it
\* cohosh will check with arlo if he can continue that work or we'll close it for now
(Oct 31 New:)
== 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-10-31
Last week:
- finished adding snowflake transport to lyrebird (lyrebird!63)
- updating Ask Tor domain front for Orbot
- added a follow up for snowflake proxy support in lyrebird (lyrebird!64)
- discussed Lox integration with Tor Browser, and removing wasm dependency
This week:
- finish snowflake dependency upgrades that were causing problems
- take a look at snowflake web and webext translations and best practices
- make changes to Lox encrypted bridge table
- Simplify BridgeLine struct and make it variable length (!147) · Merge requests · The Tor Project / Anti-censorship / lox · GitLab
Needs help with:
dcf: 2024-10-31
Last week:
- made more comments on snowflake webextension Manifest V3 run-when-closed fix: bring back "Run when browser is closed" (!83) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake WebExtension · GitLab
- commented on patch for multiple SnowflakeConn.Close Perform SnowflakeConn.Close() logic only once (!425) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
Next week:
- comment on updates to unreliable snowflake transport Draft: Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (!315) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- open issue to have snowflake-client log whenever KCPInErrors is nonzero Deploy snowflake-server for QueuePacketConn buffer reuse fix (#40260) (#40262) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- parent: Improve bug discovery process (#40267) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- open issue to disable /debug endpoint on snowflake broker
Help with:
- tell me when to restart the brokers for Upgrade snowflake broker machine from Debian 10 (#40349) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
meskio: 2024-10-24
Last week:
- bring back QR coes for email bridges (rdsys#244)
- add QR codes to Telegram distributor (rdsys#243)
- debug gettor telegram issues (onionsproutsbot#63)
Next week:
- update snowflake proxy debian package
Shelikhoo: 2024-10-31
Last Week:
- [Next Action Pending] snowflake broker update/reinstall(cont.):
- [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( Draft: Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (!315) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab ) improvements
- [Awaiting Input] Review CI: fix `latest` container image tag. CI: fix `latest` container image tag. (!408) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- Prepare State of the Onion script/slide
- Merge request reviews
Next Week/TODO:
- Merge request reviews
- Prepare State of the Onion script/slide
- Work on finishing snowflake container release(and fix the comments)
- Work on Parpare DeploymentTool for Publishing Parpare DeploymentTool for Publishing (#9) · Issues · The Tor Project / Anti-censorship / Connectivity Measurement / logcollector-admin · GitLab
onyinyang: 2024-10-31
Last week(s):
- MR for troll-patrol integration for Lox bridge blockage detection
- Add Troll Patrol to Lox (!263) · Merge requests · The Tor Project / Anti-censorship / lox · GitLab
- improved on the graceful exit and blockage detection elements from last week
- work is ongoing from vecna so will update this further when that's in a more complete state
- discussed plans for dropping lox-wasm with browser team
- test distributor implementation
Next week:
- Finish up test distributor implementation and deploy test distributor
- update lox protocols to return duplicate responses for an already seen request
- add issuer improvements to lox protocols
- Work on outstanding milestone issues:
in particular: Increase the acceptable time for bridgeline failure (#69) · Issues · The Tor Project / Anti-censorship / lox · GitLab
- key rotation automation
Later:
pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096):
\- add pref to handle timing for pubkey checks in Tor browser
\- add trusted invitation logic to tor browser integration:
- improve metrics collection/think about how to show Lox is working/valuable
- sketch out Lox blog post/usage notes for forum
\(long term things were discussed at the meeting\!\):
\- 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?
theodorsm: 2024-10-24
Last weeks:
- Adjusting to post-student life
- Testing out beta releases of pion dtls and webrtc
Next weeks:
- Update Snowflake to use latest pion upstream releases
- Test Snowflake fork with covert-dtls
- Condensing thesis into paper
Help with:
- Feedback on thesis
Facilitator Queue:
onyinyang meskio shelikhoo
1. First available staff in the Facilitator Queue will be the facilitator for the meeting
2. After facilitating the meeting, the facilitator will be moved to the tail of the queue