- tor-project - lists.torproject.org

User Support Report for April 2026
by ebanam 13 May '26

13 May '26

Hello everyone, This is the report from user support team for the month of April 2026. You can access the previous report (March 2026) here: https://lists.torproject.org/mailman3/hyperkitty/list/tor-project@lists.tor… Note: (↑), (↓) and (-) are indicating if the number of tickets we received for these topics have been increasing, decreasing or have been the same from the previous month respectively. - Summary of updates from user support - General user support - Farsi-speaking user support - Russian-speaking user support - Frontdesk (email user support channel) - Telegram, WhatsApp and Signal user support channels - Highlights from the Tor Forum - Highlights from Google Play Store # Summary of updates from user support ## General user support * 455 tickets in total (↓31 as compared to March) * 284 tickets on Email * 143 tickets on Telegram * 28 tickets on Signal * Updated instructions for Tor users in China, encouraging them to obtain WebTunnel bridges from @GetBridgesBot on Telegram or from our Bridges website (bridges.torproject.org) * In April, although the support channel over WhatsApp being accessible, we did not receive any messages through it. Users can reach our support team via a text message to our WhatsApp number: +447421000612. This service is only available for text messages; videos or calls are not supported. ## Farsi-speaking user support * 100 tickets in total (↑67 as compared to March) * 48 tickets on Email * 52 tickets on Telegram * In April, as per reports from users in Iran, users regained access to some Google-powered services like Gmail and Google Drive. As a result of which, we also saw a significant increase in tickets coming through Email. Nonetheless, internet restrictions remain very severe. * We have continued to encourage users to try dnstt bridges with Tor, especially Orbot. Latest releases of Orbot, on Android as well as iOS, ship with built-in support for dnstt bridges. Instructions to use [dnstt bridges with Orbot][] is available on the Tor Forum in both English and Farsi. Finding a DNS resolver that will work with dnstt for users in Iran remains a major challenge. We have been monitoring relevant forums and social media threads to find DNS resolvers that were reportedly still reachable from inside Iran and shared the modified dnstt bridge addresses with users. Feedback has been mostly negative with users still unable to connect to Tor because finding an unblocked DNS resolver for dnstt has been hard and other Tor PTs aren't working. [dnstt bridges with Orbot]: https://forum.torproject.org/t/connecting-to-tor-from-iran-using-dnstt-with… ## Russian-speaking user support * 615 tickets in total (↓94 as compared to March) * 194 tickets on Email * 414 tickets on Telegram (↓104 March, ↓311 February) * 7 tickets on Signal * The visible decline in the number of tickets from Russia we received over Telegram is due to Telegram being blocked in April in Russia: https://explorer.ooni.org/findings/96225549500. # Frontdesk (email user support channel) * 502(↑) RT tickets created * 526(↑) RT tickets resolved Tickets by topics and numbers: 1. 194(↓) tickets: circumventing censorship in Russian speaking countries. 2. 173(↑) tickets: instructions to circumvent censorship for Chinese speaking users. 3. 60(↓) tickets: help with troubleshooting existing Tor Browser install on Desktop (Windows, macOS and Linux). 4. 49(↑) tickets: circumventing censorship with Tor in Farsi. 5. 12(↓) tickets: help with troubleshooting Tor VPN beta. 6. 7(↓) tickets: reports of fake apps on iOS AppStore masquerading as official Tor Browser. 7. 4(↓) tickets: report of websites blocking Tor connections or not performing well in Tor Browser. 8. 3(↑) tickets: reports of anti-virus software blocking Tor Browser from running on Windows. 9. 2(-) tickets: can't use Tor VPN when Private DNS is configured on Android's Network settings. 10. 2(↑) tickets: instructions to get started with Tor Browser desktop post-install. 11. 2(-) tickets: help with troubleshooting Tor Browser for Android. 12. 2(-) tickets: help with setting up Snowflake proxy. 13. 2(↑) tickets: questions about whether it's possible to retrieve browsing history across browsing sessions on Tor Browser. 14. 2(↑) tickets: instructions to install Tor Browser on Linux. 15. 2(↑) tickets: name string of the [pluggable transports directory gets truncated][] on Tor Browser for Desktop, resulting in failure to use pluggable transports. 16. 1(↓) ticket: instructions on how to get Tor Browser binaries from GetTor. 17. 1(↓) ticket: query about Tor Browser support for Windows 8.1 (legacy operating system). 18. 1(↑) ticket: instructions to configure the 'exit' location on Tor VPN. 19. 1(↓) ticket: questions about which Tor app to install on iOS (i.e. Onion Browser or Orbot). 20. 1(↑) ticket: instructions to verify Tor Browser's GPG signature. 21. 1(↑) ticket: instructions to change app appearance of Tor VPN. 22. 1(↑) ticket: [ExoneraTor bug][]. 23. 1(↑) ticket: instructions to setup a onion service on a ipv6-only host. 24. 1(↑) ticket: instructions to update Tor Browser on Desktop. 25. 1(↑) ticket: report of ['Uptime' label][] on Tor metrics is misleading. 26. 1(↑) ticket: question whether it is safe to install Tor Browser Nightly. (It is not recommended to install nightly versions of Tor Browser apart from testing.) 27. 1(↑) ticket: Tor Browser (i.e. Firefox) [security features][] warning on Ubuntu Linux. [pluggable transports directory gets truncated]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/work_items/449… [ExoneraTor Bug]: https://gitlab.torproject.org/tpo/web/tpo/-/work_items/520 ['Uptime' label]: https://gitlab.torproject.org/tpo/network-health/metrics/website/-/work_ite… [security features]: https://support.mozilla.org/en-US/kb/linux-security-warning # Telegram, WhatsApp and Signal user support channels * 644(↓) tickets resolved Breakdown: * 609(↓) tickets on Telegram * 35(↑) tickets on Signal * 0(↓) tickets on WhatsApp Tickets by topics and numbers: 1. 421(↓) tickets: circumventing censorship in Russian speaking countries. 2. 44(↑) tickets: help with troubleshooting Tor VPN beta. 3. 31(↓) tickets: help with troubleshooting existing Tor Browser install on Desktop (Windows, macOS and Linux). 4. 36(↑) tickets: instructions to circumvent censorship for Chinese speaking users. 5. 52(↑) tickets: circumventing censorship with Tor in Farsi. 6. 29(↑) tickets: instructions to fetch bridges from Bridge distributors on Telegram or Email and use them with Tor Browser and Tor VPN beta. 7. 20(↑) tickets: instructions to use [dnstt bridges with Orbot][]. 8. 14(↓) tickets: questions about which Tor app to install on iOS (i.e. Onion Browser or Orbot). 9. 14(↓) tickets: help with using bridges with Tor VPN Beta. 10. 10(↓) tickets: helping users on iOS, using Onion Browser or Orbot, to use censorship circumvention methods. 11. 10(↑) tickets: help with troubleshooting existing Tor Browser install on Android. 12. 9(↓) tickets: instructions on how to get Tor Browser binaries from GetTor. 13. 9(↑) tickets: instructions to use WebTunnel bridges with Tor Browser. 14. 4(-) tickets: help with using bridges with Tails. 15. 4(↑) tickets: query about Tor Browser support [legacy operating systems][]. 16. 3(↑) tickets: help with configuring bridges to use with little-t tor (the network daemon). 17. 2(↑) tickets: reports of fake apps on iOS AppStore masquerading as official Tor Browser. 18. 2(↑) tickets: help with installing Tor Browser on Desktop on Linux. 19. 1(↓) ticket: questions about onion services and how to access them. 20. 1(↓) ticket: report of websites blocking Tor connections or not performing well in Tor Browser. 21. 1(↑) ticket: name string of the pluggable transports directory gets truncated on Tor Browser for Desktop, resulting in failure to use pluggable transports. [dnstt bridges with Orbot]: https://forum.torproject.org/t/connecting-to-tor-from-iran-using-dnstt-with… [legacy operating systems]: https://support.torproject.org/tor-browser/security/legacy-os/ # Highlights from the Tor Forum * Instructions to [connect to Telegram][] using Tor's SOCKS proxy from Russia. * Connecting to Tor from Iran using [dnstt with Orbot]. * Call for Testers: [Snowflake Volunteer][], an Android app to help others circumvent censorship. [connect to Telegram]: https://forum.torproject.org/t/telegram-tor-how-to-bypass-russian-block-on-… [dnstt with Orbot]: https://forum.torproject.org/t/connecting-to-tor-from-iran-using-dnstt-with… [Snowflake volunteer]: https://forum.torproject.org/t/call-for-testers-snowflake-volunteer-an-andr… # Highlights from Google Play Store ## Tor Browser for Android * Tor Browser for Android (TBA) had a Google Play rating of 4.426 stars in April, which is the same as compared to in March. * Tor Browser for Android (TBA) got 508 (↓73) new reviews. The total count of reviews for the app stands at 68,794. * For Tor Browser, the most common issue mentioned on reviews was the censorship against Tor in countries like Russia, China, Iran. ## Tor Browser for Android Alpha * Tor Browser for Android Alpha app had a rating of 4.128(↓0.003) in April which is lower compared to March. * In March, Tor Browser for Android Alpha got 12 (↓9) new reviews. The total count of reviews for the app stands at 8,785. ## Tor VPN Beta * Tor VPN beta number of unique daily users is around 68,000 at the end of April. * The top 5 countries by the number of installations being (in descending order): Russia, India, the United States, Turkmenistan, and Iran. Thanks! -- ebanam

1 0

Anti-censorship team meeting notes, 2026-05-07
by onyinyang 07 May '26

07 May '26

Hey everyone! Here are our meeting logs: https://meetbot.debian.net/tor-meeting/2026/tor-meeting.2026-05-07-16.00.ht… And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, May 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: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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Projects the TPI anti-censorship team is working on: * Project 201: Signaling channels * milestone for may https://gitlab.torproject.org/groups/tpo/-/milestones/83 * board https://gitlab.torproject.org/groups/tpo/-/boards/2675?label_name[]=Project… == Announcements == * == Discussion == * Project 201: Status and plan for next week and any blocker?. --gaba * Activity 1.1: Review existing implementations, research literature, and internal documentation. * https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/189 * Activity 2.1: Research possible fingerprint diversification system implementations * Activity 3.4: Implement AMP Cache in Rust. 3.4.1 prototype of ampcache in rust. * https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/190 * Activity 3.6: Implement SQS in Rust. 3.6.1 prototype sqs in rust. * https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/191 * Activity 4.1: Evaluate nine promising signaling channels for use in library * https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/192 * UAT licensing * https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/178#not… * Preference for MIT license, just checking that it does not affect credit for authorship? == Actions == * == Interesting links == * https://github.com/masterking32/MasterHttpRelayVPN * tunnel through https://script.google.com/, currently one of the things used in Iran == 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? * Next in the Reading Group Queue: * == 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): 2026-05-07 Last week: - deployed broker fix to prevent proxies from reporting negative client counts - started audit of UAT (anti-censorshipteam#178) - started documentation of signalling channel use and implementations (anti-censorship/team#189) - fixed up browser implementation of poll interval timeouts (snowflake-webext!100) Next week: - continue signaling channel documentation - continue to review PT spec implementation in UAT - make proxy-bridge reachability checks robust to bridge outages (snowflake#40504) - more work on letting broker inform proxies how often to poll - revise and deploy proxy support - follow up about running shadow simulations for snowflake performance - revisit conjure integration with lyrebird - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2026-05-07 Last week: - made a merge request to report an error binding to the metrics port in the snowflake proxy https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - reviewed merge request for snowflake proxy self-reported client counts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on issue about meek-server trusting Meek-IP and X-Forwarded-For HTTP headers https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek… - reported broken snowflake-stats metrics tarballs for April 2026 https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/iss… Next week: Help with: meskio: 2026-05-07 Last week: - look at the X-Forwarded-For issue in meek (meek#40006) - Evaluate signaling channels for use in library (team#192) - project reports - grant planning work Next week: - investigate ideas for signaling channels (team#192) Shelikhoo: 2026-05-07 Last Week: - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) testing environment setup/research - Merge request Reviews - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - WebTunnel Censorship Research - Vantage point maintaince - Research on Signaling Channel: TLS fingerprint diversification/imitation Next (working) Week/TODO: - Merge request reviews - [Deployment]Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) Building custom Tor Browser with patch applied - Vantage point maintaince - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - WebTunnel Censorship Research - Research on Signaling Channel: TLS fingerprint diversification/imitation onyinyang: 2026-05-07 Last week(s): -Continued implementing detection algorithm based on connecting ips in rdsys - Started working on implementing Project 201: - AMPCache Library in Rust Next week: - Sonctinue working on Project 201 -AMPCache Rustlang Library - SQS Rustlang Library - Continue tasks for project #170 (Postponed for May) Switch back to some of these: As time allows: - Continue work on rdsys#196 - Continue Investigating rdsys#248 i.e., why dysfunctional webtunnel bridges are being distributed - Troubleshooting conjure not connecting in China - waiting for more information from conjure authors/maintainers - Lox still seems to be filling up the disk on the rdsys-test server despite changes made to delete old entries, look into what's going wrong Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - review Tor browser Lox integration https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… - add TTL cache to lox MR for duplicate responses: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305 - Work on outstanding milestone issues: - 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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - 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: 2026-04-23 Last weeks: - Report bug in collector-rs for the network health team - Researching possible DTLS block in Russia - Implementing DTLS 1.3 in pion Next weeks: - Implementing DTLS 1.3 in pion Help with: - Facilitator Queue: onyinyang cohosh 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 -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

GitLab rate limiting deployed
by Antoine Beaupré 06 May '26

06 May '26

Today, we have deployed a mechanism to fight the flood of attacks against our GitLab server. It currently consists of a simple check for cookie and JavaScript in your web browser, but could be expanded to cover more complex checks. For now, if you see a "429 Rate Limited" error page, don't worry, it's normal: as long as your browser supports JavaScript and cookies, the page should reload within five seconds and let you go ahead. You will see the page when opening the page the first time in a new browser, which includes a fresh Tor Browser session, a "Private Window", or a disposable browser profile. If you operate a bot or script that scrapes GitLab, you might hit the rate limiter as well. We've added exemptions for servers managed by TPA and certain user agents, so we currently assume this will have minimal impact on our community. If this still creates problems for you, feel free to file a new issue with TPA at: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new If you cannot reach GitLab, you can contact us in `#tor-admin` on `irc.oftc.net` or `#tor-admin:matrix.org` or through email at torproject-admin(a)torproject.org. You read more about this decision in ADR-108: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/0108-gitlab-cooki… Note that this only affects the gitlab.torproject.org site, not GitLab pages, the container registry or other GitLab components for now. But similar mechanisms might have to be implemented on those other services as well if abuse spreads over. Thanks and have a nice day, a. -- Antoine Beaupré torproject.org system administration

1 0

Anti-censorship team meeting notes, 2026-04-30
by Shelikhoo 04 May '26

04 May '26

Hey everyone! Here are our meeting logs: https://meetbot.debian.net/tor-meeting/2026/tor-meeting.2026-04-30-16.00.h And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, May 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: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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… == Announcements == * == Discussion == * Network Health is working on an anomaly detection system (P183) * https://censorbib.nymity.ch/pdf/Wright2018a.pdf * https://gitlab.torproject.org/tpo/network-health/tor_anomalies * https://pad.riseup.net/p/project183_anomalies == Actions == * == Interesting links == * https://github.com/masterking32/MasterHttpRelayVPN * tunnel through https://script.google.com/, currently one of the things used in Iran == 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? * Next in the Reading Group Queue: * == 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): 2026-04-30 Last week: - implemented NextPoll field for Go proxies (snowflake!709) - implemented NextPoll field for web proxies (snowflake-webext!99) - broker deployment of bloco proxy type and NextPoll feature - prevent negative self-reported client counts in proxy polls (snowflake#40538) Next week: - finish implementing proxy use of NextPoll field - review code for QUIC-based transport - make proxy-bridge reachability checks robust to bridge outages (snowflake#40504) - more work on letting broker inform proxies how often to poll - have proxies honour the NextPoll message - follow up about running shadow simulations for snowflake performance - revisit conjure integration with lyrebird - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2026-04-16 Last week: Next week: - comment on dynamic poll rate adjustment https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2026-04-30 Last week: - build a demo package of snowflake with goreleaser (snowflake#40409 tpa/team#42591) - project reports - grant planning work Next week: - distribute orbot over telegram bot (onionsproutsbot#74) Shelikhoo: 2026-04-30 Last Week: - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) testing environment setup/research - Merge request Reviews - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - WebTunnel Censorship Research - Vantage point maintaince Next (working) Week/TODO: - Merge request reviews - [Deployment]Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) Building custom Tor Browser with patch applied - Vantage point maintaince - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - WebTunnel Censorship Research onyinyang: 2026-04-30 Last week(s): -Continued implementing detection algorithm based on connecting ips in rdsys Next week: - Continue tasks for project #170 Switch back to some of these: As time allows: - Continue work on rdsys#196 - Continue Investigating rdsys#248 i.e., why dysfunctional webtunnel bridges are being distributed - Troubleshooting conjure not connecting in China - waiting for more information from conjure authors/maintainers - Lox still seems to be filling up the disk on the rdsys-test server despite changes made to delete old entries, look into what's going wrong Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - review Tor browser Lox integration https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… - add TTL cache to lox MR for duplicate responses: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305 - Work on outstanding milestone issues: - 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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - 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: 2026-04-23 Last weeks: - Report bug in collector-rs for the network health team - Researching possible DTLS block in Russia - Implementing DTLS 1.3 in pion Next weeks: - Implementing DTLS 1.3 in pion Help with: - Facilitator Queue: onyinyang cohosh 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

1 0

Chinese research grant 2023YFB3106700, "Research on Generalized Security Theory for Dark Web Suppression"
by David Fifield 29 Apr '26

29 Apr '26

The National Key R&D Program (国家重点研发计划) is a major national-level research funding program in China since 2016. https://zh.wikipedia.org/wiki/%E5%9B%BD%E5%AE%B6%E9%87%8D%E7%82%B9%E7%A0%94… https://www.eeas.europa.eu/sites/default/files/1.pdf#page=59 The National Key R&D Program, and specific grant numbers thereof, are frequently acknowledged in research papers. But finding information beyond the grant numbers is difficult. There's no central public source of grant metadata such as the title, the name of the principal investigator, the start and end dates, and the funding amount. MERICS has published at least one report with aggregate statistics about Key R&D projects (https://merics.org/en/report/controlling-innovation-chain#2-research-projec…) but apparently the sources of data they used are no longer available. But sometimes information about grants gets out through other sources. An example is grant number 2023YFB3106700, which appears in the CV of a researcher named Cao Jie with start and end dates that the English title "Research on Generalized Security Theory for Dark Web Suppression". https://jiejaycao.github.io/CV_Jie.pdf https://web.archive.org/web/20260421165501/https://jiejaycao.github.io/CV_J… https://github.com/JieJayCao/JieJayCao.github.io/blob/b9c4ff3f8e2d4cbe5253b… > Research on Generalized Security Theory for Dark Web Suppression > Nov. 2013 – Dec. 2024 > Researcher, National Key R&D Program of China (Key Special Program), Grant No. 2023YFB3106700 We can do a web search to find research publications that have been funded by this "dark web suppression" grant. I found 6 published papers and 1 preprint: "TorHunter: A Lightweight Method for Efficient Identification of Obfuscated Tor Traffic Through Unsupervised Pre-training". Yuwei Xu, Xu Zhengxin, Cao Jie, Wang Rongrong, Yuan Yali, Cheng Guang. International Conference on Information and Communications Security, 2024. https://link.springer.com/chapter/10.1007/978-981-97-8801-9_1 https://dblp.org/rec/conf/icics/XuXCWYC24 "FullView: Using Bidirectional Group Sequences to Achieve Accurate Encrypted Traffic Classification". Xu Yuwei, Liang Zhiyuan, Xu Zhengxin, Song Kehui, Xiang Qiao, Cheng Guang. Security and Privacy in Communication Networks, 2024. https://link.springer.com/chapter/10.1007/978-3-031-94448-2_11 https://dblp.org/rec/conf/securecomm/0001LXSX024 "OnionPeeler: A Novel Input-Enriched Website Fingerprinting Attack on Tor Onion Services". Xu Zhengxin, Cao Jie, Hou Yujie, Xu Yuwei, Cheng Guang. Security and Privacy in Communication Networks, 2024. https://link.springer.com/chapter/10.1007/978-3-031-94455-0_11 https://dblp.org/rec/conf/securecomm/Xu0H0024.html "GateKeeper: An UltraLite malicious traffic identification method with dual-aspect optimization strategies on IoT gateways". Cao Jie, Xu Yuwei, Yu Enze, Xiang Qiao, Song Kehui, He Liang, Cheng Guang. Computer Networks, 2024. https://www.sciencedirect.com/science/article/abs/pii/S1389128624003888 https://dblp.org/rec/journals/cn/CaoXYXSHC24 "Attack smarter: Attention-driven fine-grained webpage fingerprinting attacks". Yuan Yali, Zou Weiyi, Cheng Guang. Computers & Security, 2025. https://www.sciencedirect.com/science/article/abs/pii/S0167404825003323 https://dblp.org/rec/journals/compsec/YuanZC25 https://arxiv.org/abs/2506.20082 "M3S-UPD: Efficient Multi-Stage Self-Supervised Learning for Fine-Grained Encrypted Traffic Classification with Unknown Pattern Discovery". Yuan Yali, Huang Yu, Zeng Xingjian, Mei Hantao, Cheng Guang. 2025. https://arxiv.org/abs/2505.21462v1 "METRA: Robust Encrypted Traffic Detection Against Adversarial Attacks via Multi-Task Learning and Label Denoising". Wang Yaohui, Sun Degang, Wan Wei, Zhao Jing, Du Guanyao, Long Chun International Conference on Acoustics, Speech and Signal Processing, 2026. https://cmsworkshops.com/ICASSP2026/view_paper.php?PaperNum=5312 https://english.cnic.cas.cn/rsearch/rp/202603/t20260323_1153131.html https://cnic.cas.cn/gzdt/202603/t20260313_8159227.html If I had to guess, I would say that the principal investigator of grant 2023YFB3106700 is probably professor 程光 (Cheng Guang) of Southeast University. https://cyber.seu.edu.cn/_s303/cg1/list.psp This is certainly not the only Chinese grant that funds Tor / dark web / onion service / encrypted traffic classification research. I'm highlighting it just because I found a title for it, which is rare.

4 7

Snowflake relays
by Q Misell 27 Apr '26

27 Apr '26

Hi all, Whilst working on a project the thought crossed my mind that it would be useful to me (the exact reasons as to why aren't relevant here) for a web browser to be able to run a Tor client entirely in the browser, that is using a wasm build of Arti or my own Torrosion library. Obviously, a browser can't just go start making random outbound TCP connections, for good reasons. But what a browser can do is make outbound WebRTC and WebSocket connections, which brought me to Snowflake. At least in most situations, I would have no need for the whole WebRTC infrastructure of Snowflake, as the browser is not *usually* restricted from making a WebSocket connection. So, naturally I looked at the Snowflake source code to see how one would implement that, to discover some things I'm a little confused by. Firstly, the Tor node that the broker hands out seems to be a) hard coded and b) just the one (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Secondly, the number of active relays offering WebSocket connections are a grand total of 4 (https://metrics.torproject.org/rs.html#search/transport:snowflake?fields=tr…) Therefore, my question to those more knowledgeable is: why is this situation considered acceptable? Why is such relay centralisation fine? Is it even fine? Mit freundlichen Grüßen, Q Misell (sie/ihr - she/her) 🌲 Please consider the environment before using AI to process this email. -- Max-Planck Institut für Informatik Fon +49 681 9325 3547 Forschungsgruppe Internet Architecture (INET) Campus E1.4 514, 66123 Saarbrücken

2 1

Anti-censorship team meeting notes, 2026-04-23
by meskio 23 Apr '26

23 Apr '26

Hi everyone, Here is our meeting log: https://meetbot.debian.net/tor-meeting/2026/tor-meeting.2026-04-23-16.00.ht… And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Apr 30 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:meskio == 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… == Announcements == * == Discussion == * How to Integrate UAT with Tor * https://gitlab.torproject.org/41_un/uat * looking at what will be the next steps to get it included in TB * cohosh will review the code * Network Health is working on an anomaly detection system (P183) * https://censorbib.nymity.ch/pdf/Wright2018a.pdf * https://gitlab.torproject.org/tpo/network-health/tor_anomalies * will discuss next week (Apr 30) == Actions == * == Interesting links == * pion/webrtc with boringssl: https://github.com/zshang-oai/webrtc-boringssl * might be an alternative for proxies if snowflake gets censored by DTLS fingerprinting * boringssl is used by chrome == 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? * Next in the Reading Group Queue: * == 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): 2026-04-23 Last week: - updated when EventOnCurrentNATTypeDetermined is dispatched (snowflake!706) - tried to deploy broker but caught a nil pointer deref bug (snowflake!708) - continued work on evaluating enumeration attacks on snowflake Next week: - keep following up with fingerprinting in Russia - make proxy-bridge reachability checks robust to bridge outages (snowflake#40504) - more work on letting broker inform proxies how often to poll - have proxies honour the NextPoll message - follow up about running shadow simulations for snowflake performance - revisit conjure integration with lyrebird - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2026-04-16 Last week: Next week: - comment on dynamic poll rate adjustment https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2026-04-23 Last week: - release rdsys with https language selector and scrubbed assignemnts (rdsys#300) - publish assignments log in https://rdsys-backend.torproject.org/assignments (tpa/team#42599) - remove whatasapp code from rdsys as it is not been used - explore including PTs in deb.torproject.org (tpa/team#42591) - project reports - grant planning work Next week: - Shelikhoo: 2026-04-23 Last Week: - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) testing environment setup/research - Merge request Reviews - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - Writing Socks5 UDP proxy for nat type simuation Next (working) Week/TODO: - Merge request reviews - [Deployment]Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) Building custom Tor Browser with patch applied - Vantage point maintaince - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - Writing Socks5 UDP proxy for nat type simuation\ - WebTunnel Censorship Research onyinyang: 2026-04-23 Last week(s): - Started implementing detection algorithm based on connecting ips in rdsys Next week: - Continue tasks for project #170 Switch back to some of these: As time allows: - Continue work on rdsys#196 - Continue Investigating rdsys#248 i.e., why dysfunctional webtunnel bridges are being distributed - Troubleshooting conjure not connecting in China - waiting for more information from conjure authors/maintainers - Lox still seems to be filling up the disk on the rdsys-test server despite changes made to delete old entries, look into what's going wrong Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - review Tor browser Lox integration https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… - add TTL cache to lox MR for duplicate responses: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305 - Work on outstanding milestone issues: - 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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - 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: 2026-04-23 Last weeks: - Report bug in collector-rs for the network health team - Researching possible DTLS block in Russia - Implementing DTLS 1.3 in pion Next weeks: - Implementing DTLS 1.3 in pion Help with: - Facilitator Queue: onyinyang cohosh shelikhoo meskio 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 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

disrupted service: GitLab CI containers failures
by Antoine Beaupré 20 Apr '26

20 Apr '26

Hi, The GitLab Container Registry is refusing requests to GitLab CI pipelines between projects. This started on Friday, when the GitLab 18.11 upgrade was deployed. We are hoping for a quick fix from upstream, but in the meantime, we need your help! Normal GitLab operation should be unaffected. GitLab CI still works, it just fails with images from our own registry when accessed from personal projects. We've found a workaround that requires you to report the failures to us. In [tpo/tpa/team#42595], we ask that you write a new comment with the following information: - source project: failing project (e.g. `group/failing_project`) - registry project: project it is trying to pull from (e.g. `tpo/tpa/base-images`) - example failed job: URL of the failed job [tpo/tpa/team#42595]: https://gitlab.torproject.org/tpo/tpa/team/-/work_items/42595 For example, this was our first report: > - source project: Diziet/arti > - registry project: tpo/tpa/base-images > - example failed job: https://gitlab.torproject.org/Diziet/arti/-/jobs/1485144 You might be able to fix this yourself. If you have access to the "registry project" above, you can manually add the source project to the CI/CD job token allowlist of the registry project", by following: 1. Settings 1. CI/CD 1. Job token permissions 1. add the "source project" to the allowlist You MUST keep track of that exception and remove it once this incident is resolved! Thank you for your attention! -- Antoine Beaupré torproject.org system administration

1 0

gitlab 18.10 upgrade removes "issues"
by Antoine Beaupré 20 Apr '26

20 Apr '26

Hi, Today, we upgraded gitlab.torproject.org to 18.10! Among a couple of interesting new things[1], GitLab introduced a *significant* change in the way "issues" are presented and organized. It was introduced as "the work items list and saved views"[2]. It's an interesting feature! It allows you to see epics alongside issues and create saved searches of your issues, pretty neat. Except. They essentially *removed* the entire "issues" UX. You know how I keep bugging people to "file an issue"? That "new issue" button is gone. Heck, the "issues" button itself is gone. In its place, there is a "work items" button, and *there* you can find your good old issues (and, now, also epics). But, crucially, there's no "Closed" tab anymore, so you can't easily go into closed issues with one click: you need to go through the search form and a couple of clicks to find closed issues. So after consultation (well, really, it was sheer panic) with my colleagues, I found a way to revert this. So you won't yet see this view. If you really want to experiment with it, replace the "issues" string with "work_items" in URLs, that still works. I have filed a comment (like dozens of other GitLab users) objecting to the change, alongside with the instructions for other GitLab administrators to revert this change.[3] It is my hope that the feature can be improved to some maturity (at *least* keep a "closed" tab and a "new issue" button?!) and that eventually we'll be able to switch the feature back on. I can see the point of having a common view for issues and epics, even though it's not a problem I have personally struggled with in GitLab. But at this point, we can't just do that switch. Let me know if there's any other concern here! a. [1] details in https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/ [2] https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/#introdu… [3] https://gitlab.com/gitlab-org/gitlab/-/work_items/590689#note_3175428478 -- Antoine Beaupré torproject.org system administration

5 8

Anti-censorship team meeting notes, 2026-04-16
by Cecylia Bocovich 17 Apr '26

17 Apr '26

Hi everyone, Here is our meeting log: https://meetbot.debian.net/tor-meeting/2026/tor-meeting.2026-04-16-16.00.ht… And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, Apr 16 16:00 UTC Facilitator:meskio ^^^(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: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 projects, we are working on: All needs review tickets: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… == Announcements == == Discussion == Draft short paper about using fountain codes for rendezvous, comments welcome https://repo.or.cz/erasure-code-rendezvous.git/blob_plain/5b4b5d1cc188cdc12… https://repo.or.cz/erasure-code-rendezvous.git/tree/5b4b5d1cc188cdc12adf1f4… Recent snowflake proxy updates for DTLS fingerprinting (randomizemimic by default) https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… We haven't reached out to operators yet cohosh offers to send a tor-relays email The snowflake default bridge lines in Tor Browser were updated with a new set of STUN servers == 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? Next in the Reading Group Queue: == 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): 2026-04-16 Last week: - added bloco to KnownProxyTypes for broker metrics (snowflake#40534) - implemented a way to manually update poll intervals without restart (snowflake!701) - responded to IPtProxy issue to expose GetCurrentNATType for the snowflake proxy (snowflake#40536) - https://github.com/tladesignz/IPtProxy/issues/86 - worked on proxy fairness proposal writeup Next week: - keep following up with fingerprinting in Russia - make proxy-bridge reachability checks robust to bridge outages (snowflake#40504) - more work on letting broker inform proxies how often to poll - have proxies honour the NextPoll message - follow up about running shadow simulations for snowflake performance - revisit conjure integration with lyrebird - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2026-04-16 Last week: Next week: - comment on dynamic poll rate adjustment https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2026-03-26 Last week: - split translation strings in the telegram distributor to make it easier to translate (rdsys#299) - stop sharing windows7 TB in Telegram gettor, as there is no releases anymore (onionsproutsbot#77) - assignments log scrambled on our side (rdsys!638) - grant work Next week: - give it a try to gorelease to produce debian packages Shelikhoo: 2026-04-16 Last Week: - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) testing environment setup/research - Merge request Reviews - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - Writing Socks5 UDP proxy for nat type simuation - [Done] Update Snowflake STUN servers at Tor browser ( https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… ) Next (working) Week/TODO: - Merge request reviews - [Deployment]Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) Building custom Tor Browser with patch applied - Vantage point maintaince - [Research] proxy pool overload and potential blocking in Iran ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - [Research] Add three NAT type buckets to the snowflake broker ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) - Writing Socks5 UDP proxy for nat type simuation onyinyang: 2026-04-09 Last week(s): - Started background work for project #170 Next week: - Start on tasks for project #170 Switch back to some of these: As time allows: - Continue work on rdsys#196 - Continue Investigating rdsys#248 i.e., why dysfunctional webtunnel bridges are being distributed - Troubleshooting conjure not connecting in China - waiting for more information from conjure authors/maintainers - Lox still seems to be filling up the disk on the rdsys-test server despite changes made to delete old entries, look into what's going wrong Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - review Tor browser Lox integration https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… - add TTL cache to lox MR for duplicate responses: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305 - Work on outstanding milestone issues: - 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: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - 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: 2026-04-16 Last weeks: - MR fixing silent errors of fingerprint parse failure in covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Researching possible DTLS blocking in Russia - Implementing DTLS 1.3 in pion Next weeks: - Implementing DTLS 1.3 in pion Help with: - Facilitator Queue: meskio onyinyang cohosh 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

1 0