[tor-project] Anti-censorship team meeting notes, 2023-09-21
Shelikhoo
shelikhoo at torproject.org
Thu Sep 21 17:00:46 UTC 2023
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?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 ==
== 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/000314.html
*
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/snowflake/-/issues/40068#note_2767823
* 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/snowflake/-/jobs/370910
* # github.com/xtaci/kcp-go/v5
*
/go/pkg/mod/github.com/xtaci/kcp-go/v5 at 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/691fc2febef3dd927dca7815b207fb4dad19b58f
* 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-costs/diff?version_id=4a6fa36c5bfc350fa01a5fe774b297f6fcddb51c
- 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/000314.html
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/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
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/webtunnel/-/merge_requests/17)
(Done pass the client IP to tor for country usage stadistics,
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/25)
- Release new version of
snowflake(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/174)
- Update CI targets to test Android from Golang 1.21
(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/181)
- 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/lox-library/src/proto/blockage_migration.rs?ref_type=heads#L29
- 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20230921/b8dbb362/attachment.sig>
More information about the tor-project
mailing list