[tor-project] Anti-censorship team meeting notes, 2023-10-12

Hey everyone!

Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-10-12-15.59.html

And our meeting pad:

Anti-censorship work meeting pad

···

--------------------------------
------------------------------------------------------------------------------------
THIS IS A PUBLIC PAD
------------------------------------------------------------------------------------

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

Next meeting: Thursday, Oct 19 16:00 UTC
Facilitator: onyinyang

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?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
             \* 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_name%5B%5D=Sponsor%20150

== Announcements ==

 \* A poll to set a date for a 'Future of PTs' voice conversation
     \* https://www.systemli.org/poll/#/poll/YRRF8K19Bq/evaluation?encryptionKey=e1f9KPaHH6z7I6uYGNQVlegHvMGB3aHJaEufGQl7
     \* Times in UTC

== Discussion ==

 \* \(Network Health\) 'Running' flag for counting bridges and network size https://gitlab.torproject.org/tpo/network-health/team/-/issues/318
     \* metrics are going to start using bridgestrap instead of the running flag to know if bridge is working
     \* we need bridgestrap to publish results every hour
     \* https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/39

(Oct 12)
* Armored Bridge line Spec
Research about designing an armored bridge line sharing URL format (#126) · Issues · The Tor Project / Anti-censorship / Team · GitLab
* the spec is ready to review
* we'll discuss it next week

 \* snowflake broker restart\(deployment\) needed, and deletion of ip\-count\-mask key

Restart broker without proxy churn measurements (#40295) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
* shelikhoo will tag a snowflake version and deploy it

== 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): 2023-10-12
Last week:
- followed up on performing Snowflake tests in OONI without Tor
- torsf: improvements over initial proof of concept · Issue #1686 · ooni/probe · GitHub
- started some larger-scale shadow experiments
- various MR reviews
This week:
- deploy lox distributor (waiting on TPA)
- follow up on conjure reliability issues
- visualize and write up some snowflake shadow simulation results
Needs help with:

dcf: 2023-10-12
Last week:
- continued to document changes in snowflake bridge usage after the fastly domain front issue - snowflake-02 mysteriously and suddenly returned to former bandwidth levels (not yet former user levels) on 2023-10-04.
https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/000320.html


- investigated and reported a pluggable transports user counting bug that exists since tor 0.4.8.4.

- did client-side experiments to compare the availability of proxies for snowflake-01 and snowflake-02 [anti-censorship-team] Comparing broker answer and connection times across snowflake-01 and snowflake-02
- opened an issue to update documentation (bridge line args versus command line options) in snowflake client README Client README recommends command-line options rather than bridge line arguments (#40294) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
- opened an issue to restart the broker after disabling proxy churn metrics Restart broker without proxy churn measurements (#40295) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
Next week:
- revise encapsulation.ReadData redesign to return an error in the case of a short buffer Have encapsulation.ReadData read into a provided buffer (!154) · 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
Before EOY 2023:
- move snowflake-02 to new VM
Help with:

meskio: 2023-10-12
Last week:
- review sponsor 30 audit issues to be ready to publish
- review webtunnel bridgeline args fixes (webtunnel!19)
- mostly AFK
Next week:
- test the whatsapp bot (rdsys#147)

Shelikhoo: 2023-10-12
Last Week:
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (continue)
- Write Tor Spec for Armored URL(continue) Research about designing an armored bridge line sharing URL format (#126) · Issues · The Tor Project / Anti-censorship / Team · GitLab
- Refine argument error processing in WebTunnel server Refine argument error processing in WebTunnel server (!19) · Merge requests · The Tor Project / Anti-censorship / Pluggable Transports / WebTunnel · GitLab
- Renovate is Using Unexpected Golang Version During Dependency Update Renovate is Using Unexpected Golang Version During Dependency Update (#9) · Issues · The Tor Project / TPA / Renovate Cron · GitLab
Next Week/TODO:
- Write Tor Spec for Armored URL (continue)
- [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (continue): proceed to rebase
- Merge request reviews

onyinyang: 2023-10-12
Last week(s):
- Made MRs to upstream zkp libs:
- fixed bug(? hopefully this can be reviewed) in the zkp crate
- made MRs to both dalek-cryptography and zkcrypto and will maintain lox-zkp
This week:
- Continue with metrics
- Add functionality for a MAX_DAILY_BRIDGES (the number of bridges that can be distributed each day)
- Start work on telegram distributor bot for Lox

     \(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?