Hey everyone!

Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-21-15.57.html

And our meeting pad:

Anti-censorship work meeting pad -------------------------------- ------------------------------------------------------------------------------------                                                         THIS IS A PUBLIC PAD ------------------------------------------------------------------------------------

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

Next meeting: Thursday, Sep 28 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?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 ==

* deprecation of CAPTCHA moat         * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/173         * captchas seem to be easy for censors to solve, and hard for some users to solve         * prefer the circumvention settings API instead, it's not great but it seems to work better (distributes different subsets of bridges each day, you cannot enumerate them all in one day)         * meskio has been ontifying downstream users about the planned deprecation         * ggus: since we are planning to turn this off, before we do, could we experiment with different/harder captchas and see if bridges continue being blocked. (The hypothesis being that the captcha API is the primary way that they discover bridges.)         * A proposal to phase out captchas in bridgedb from 2021: https://lists.torproject.org/pipermail/tor-dev/2021-July/014602.html             * Replies suggested doing an experiment with captcha removal for 50% of bridges, that way they don't all get burned if it doesn't work                 * https://lists.torproject.org/pipermail/tor-dev/2021-July/014603.html                 * https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html         * agreement on removing the in-house captcha         * meskio will create an issue to explore captcha experiments             * https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176     * snowflake domain front resolving to a mix of fastly and cloudflare since 2023-09-20         * https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/0...         * https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42120         * options for remediation:             * change the domain front to one that still always resolves to fastly                 * not a lot of good options, also we don't have good knowledge of which are already censored https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...             * locally pin the IP address of the front domain we are using now                 * or resolve a different (fastly) name, but keep using the same front that we use now                 * creates an inconsistency between DNS and TLS             * we can change the front domain for circumvention settings users, which does not require waiting for a TB/orbot/etc. release         * change the domain to foursquare.com         * guardian project / orbot? meskio says orbot is already using circumvention settings. But circumvention settings might be ignored for built-in bridges.         * dcf will make a forum post and contact guardian project             * community team will try to get testing of fourquare.com in the next week         * meskio will make the change in Tor Browser and circumvention settings     * Remove Go 1.20 support? kcp library seems to crash compiler:         * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...             * # github.com/xtaci/kcp-go/v5             * /go/pkg/mod/github.com/xtaci/kcp-go/v5@v5.6.3/timedsched.go:19:6: internal compiler error: panic: interface conversion: interface is nil, not ir.Node             * Please file a bug report including a short program that triggers the error.             * https://go.dev/issue/new             * note: module requires Go 1.21         * https://github.com/xtaci/kcp-go/blob/v5.6.3/timedsched.go#L19         * Go compiler issue: https://github.com/golang/go/issues/61074             * Has to do with new compiler builtin "clear" in go1.21 https://tip.golang.org/doc/go1.21#language             * ...which kcp-go started using 10 days ago https://github.com/xtaci/kcp-go/commit/691fc2febef3dd927dca7815b207fb4dad19b...         * shelikhoo will go ahead and remove go1.20 support

== Actions ==

== Interesting links ==

* https://www.bamsoftware.com/papers/fep-flaws/#sec:obfs4         * writeup of Elligator distinguishers that have affected obfs4proxy

== 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-09-21     Last week:         - dealt with dependency updates for snowflake and lox         - discussed rdsys resource endpoints         - opened an issue to create a lox user on rdsys-frontend-01             - https://gitlab.torproject.org/tpo/tpa/team/-/issues/41330         - wrote some next steps for conjure work             - https://gitlab.torproject.org/tpo/operations/proposals/-/issues/51     This week:         - finish deploying lox distributor         - follow up on conjure reliability issues         - visualize and write up some snowflake shadow simulation results     Needs help with:

dcf: 2023-09-21     Last week:         - snowflake CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-cos...         - noticed a problem with the fastly domain front and coordinated with cohosh to analyze it https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/0...     Next week:         - revise encapsulation.ReadData redesign to return an error in the case of a short buffer 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     Before EOY 2023:         - move snowflake-02 to new VM     Help with:

meskio: 2023-09-21    Last week:      - make fake descriptors for rdsys (rdsys#171)      - document rdsys development process (rdsys#131)      - use the right content-type in moat (rdsys#175)      - add token authentication to onbasca requests (rdsys#174)    Next week:         - add a DB for bridges to rdsys (rdsys#56)

Shelikhoo: 2023-09-21    Last Week:         - [Merge Request Awaiting] Add SOCKS5 forward proxy support to snowflake (snowflake!64) (stalled)         - Add Remote Network Address Mapping in HTTP Upgrade Transport (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtu...) (Done pass the client IP to tor for country usage stadistics, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtu...)         - Release new version of snowflake(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...)         - Update CI targets to test Android from Golang 1.21 (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...)         - Merge request reviews    Next Week/TODO:      - Write Tor Spec for Armored URL         - Merge request reviews

onyinyang: 2023-09-21     Last week(s):         - Continued updating dependencies, including:             - found issues with zkp library and am working on determining how to best handle those going forward, fixes are required to keep other dalek-cryptography libraries up to date: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/51             - additionally, there is a bug in the zkp crate that is noted in the blockage migration protocol so we might try to fix it: https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/blob/main/crates/...         - Attempted changes to rdsys API at the /resources endpoint to meet the needs of Lox         - Started on adding metrics     This week:         - Hopefully sort out the dependencies issue         - Finish up changes to the API         - continue with metrics

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