[tor-project] Anti-censorship team meeting notes, 2023-08-03
Arlo Breault
arlo at torproject.org
Fri Aug 4 17:26:06 UTC 2023
On Fri, Aug 4, 2023, 9:24 a.m. onyinyang <onyinyang at torproject.org> wrote:
> Hey everyone!
>
> Here are our meeting logs:
>
> http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-07-31-15.58.html
http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-08-03-15.58.html
>
> And our meeting pad:
>
> Anti-censorship work meeting pad
> --------------------------------
>
> ------------------------------------------------------------------------------------
> THIS IS A
> PUBLIC PAD
>
> ------------------------------------------------------------------------------------
>
>
> Anti-censorship
> --------------------------------
>
> Next meeting: Thursday, Aug 10 16:00 UTC
> Facilitator: shelikhoo
>
> 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: onyinyang
>
> == 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 139 <-- hackerncoder, irl, joydeep, meskio, emmapeel
> working on it
> * https://pad.riseup.net/p/sponsor139-meeting-pad
>
>
> == Announcements ==
>
> *
>
>
> == Discussion ==
> This week:
> * ptspec status version support
> * to be included in 0.4.8
> * https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/731
> *
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib/-/merge_requests/1
> * goptlib not blocking core tor
>
> * Webtunnel soft release and next phase:
> https://gitlab.torproject.org/tpo/community/team/-/issues/94
> * Feedback collected
> * improving the docs for compiling from the source
> * some ppl asked apache instructions and not just nginx
> * didn't work in china and worked in russia
> * Next steps
> * gus will improve and move the documentation to the
> community portal
> * will talk with applications to include webtunnel in the
> upcoming TB 13 in september
> * we'll organize a call for bridges
>
> * HTTP CONNECT as an alternative to SOCKS for PT interfacing
> * HTTP CONNECT proxy has advantages over SOCKS4/5, one of which
> is abundant room to encode bridge parameters
> * Mentioned in an issue about bridge line length
> *
>
> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/104#note_2918118
> * dcf: server-side SOCKS (needed for client PT) has poor
> support in standard programming language packages, which is why goptlib
> and Proteus implement their own SOCKS server:
> *
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib/-/blob/v1.4.0/socks.go
> *
> https://github.com/unblockable/proteus/tree/v0.1.0/src/net/proto/socks
> * What about MASQUE
> (https://datatracker.ietf.org/wg/masque/about/) more generally (HTTP
> proxying but more general than just HTTP CONNECT, would leave room for
> e.g. datagram-based proxying)?
> * "The primary goal of this working group is to develop
> mechanism(s) that allow configuring and concurrently running multiple
> proxied stream- and datagram-based flows inside an HTTP connection."
>
> == Actions ==
>
> * Next week (August 10th): follow up on Snowflake/Pion
> incompatibility with Android 11+ and SDK >29) when Guardian project
> responds and shelikhoo returns:
> *
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40278
> * might only affect android apps that target android>11, but
> google will start requiring it soon (end of August 2023)
> *
> https://support.google.com/googleplay/android-developer/answer/11926878
> * Issue on pion side, closed as wontfix:
> https://github.com/pion/transport/issues/228
> * we ought to be up to date with dependencies, as renovatebot
> is connected to the snowflake repo
> * meskio will cc Guardian Project on #40278 to see if they have
> any insight
> * shelikhoo will try to reproduce and will try the available
> patches
> * no news 2023-08-03
>
> == 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): away until 2023-08-17
> Last week:
> This week:
> Needs help with:
>
> dcf: 2023-08-03
> Last week:
> - wrote forum post for proxy churn measurements
>
> https://forum.torproject.org/t/advisory-mistakenly-collected-proxy-churn-measurements-on-the-snowflake-broker-have-been-deleted/8544
> and made issue public
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40161
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40162
> - fixed standalone proxy DefaultRelayURL to point back at
> snowflake.torproject.net
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/156
> Next week:
> - review goptlib STATUS TYPE=version
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib/-/merge_requests/1
> - revise encapsulation.ReadData redesign to return an error in
> the case of a short buffer
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/154
> - open issue to have snowflake-client log whenever KCPInErrors
> is nonzero
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40262#note_2886018
> - parent:
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40267
> - open issue to disable /debug endpoint on snowflake broker
> Help with:
>
> meskio: 2023-08-03
> Last week:
> - release and deploy rdsys with telegram bot translations
> - test tor's support for status version (tor!731)
> - add support for goptlib for status version (goptlib!1)
> - review and deploy new circumvention rules for Turkmenistan
> (rdsys-admin!16)
> - update obfs4 docker image to don't expose OrPort (team#129)
> - review lox merge requests (lox-rs!15 !18 !21)
> Next week:
> - organize work for BridgeDB deprecation
>
> Shelikhoo: 2023-07-27
> Last Week:
> - [Merge Request Awaiting] Add SOCKS5 forward proxy support to
> snowflake (snowflake!64) (stalled)
> - [Research] HTTPT Planning
>
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/1
> - logcollector alert system - ongoing
> - Reviewing & comment on merge requests
> - FOCI Keynote and attendence
> Next Week/TODO:
> - logcollector alert system <- immediate todo
>
> onyinyang: 2023-08-03
> Last week(s):
> - Implemented db
> - decided against polodb and went for sled instead
>
> https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/22
> - not sure if reading/writing the lox-context to json
> should still be supported at all or just removed
>
> - Implemented and tested a basic k-invites for open entry
> distribution
>
> https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/merge_requests/20
> - Thought more deeply about how best to sync Lox with rdsys given
> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168
> - the rdsys API is really not designed for a distributor
> like Lox that needs persistence. Even a lastPassed flag will only be
> helpful for `gone` resources if Lox stores all of the resource info from
> rdsys and checks it regularly. This diverges from the original intention
> of rdsys, in which rdsys should be the 'arbiter of truth' for the status
> of resources.
> - The next step is to check the rdsys API and see if the
> get functionality can improve this situation. I think ideally we want a
> list of all resources assigned to Lox and their current statuses that
> can then be checked against something like the `lastPassed` flag each
> time Lox polls rdsys.
> This week:
> - Continue with implementing db and synchronization between
> Lox/rdsys (possibly reliant on some aspects of the former point)
> - Work on adding metrics
> - AFK from August 5 - 21!
> (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?
>
> Itchy Onion: 2023-06-08
> Last week:
> - fixed snowflake pipeline due to outdated Debian image
> - continue working on rdsys#56 implementation. Still need to do the
> following:
> - finish up computing bridge distribution in Kraken
> - does it have to be deterministic?
> - does the disproportion have to be strictly followed
> - finish writing tests
> - refactor code because some functions are getting extremely long
> - what to do with stencil package?
> This week:
> - review MRs
> - continue working on rdsys#56 implementation. Still need to do the
> following:
> - fixed a problem with vanilla bridges not being added properly
> to the database
> - still working on tests
> - adding a migaration patch
> (
> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/56#note_2908572
> )
>
> --
> ---
> onyinyang
>
> GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036
>
> _______________________________________________
> tor-project mailing list
> tor-project at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20230804/0c5eceb5/attachment-0001.htm>
More information about the tor-project
mailing list