- tor-project - lists.torproject.org

Anti-censorship team meeting notes, 2025-07-24
by onyinyang 24 Jul '25

24 Jul '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-07-24-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, July 31 16:00 UTC Facilitator: shelikhoo ^^^(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: 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * == Discussion == * dan crashing to talk about Tor VPN app signing strategy and consequences * will be distributed over 3 mediums (tpo website, google play and fdroid) * sharing the key over the 3 mediums will make possible for users to switch upgrade channels if one gets blocked * google wants access to the private key * the plan is to share the key between fdroid and tpo, but have a different key for google * TorBrowser Android doesn't have that problem because is an old app and google don't require keys for old apps * meskio will coordinate with applications team to see how to integrate TorVPN in gettor == Actions == == Interesting links == * FOCI 2025.2 proceedings https://foci.community/foci25.html * "Fingerprint-resistant DTLS for usage in Snowflake" by theodorsm https://www.petsymposium.org/foci/2025/foci-2025-0006.pdf * "Encrypted Client Hello (ECH) in Censorship Circumvention" https://www.petsymposium.org/foci/2025/foci-2025-0016.pdf * PETS 2025 * "CenPush: Blocking-Resistant Control Channel Using Push Notifications" by cohosh et al. https://petsymposium.org/popets/2025/popets-2025-0153.pdf == Reading group == * We will discuss "Encrypted Client Hello (ECH) in Censorship Circumvention" on August 14 * https://www.petsymposium.org/foci/2025/foci-2025-0016.pdf * 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): 2025-07-24 Last week: - dependency upgrades - release snowflake-webext 0.9.4 - opened issue for weird proxy count graphs (snowflake#40472) - finished adapting client poll metrics scripts for rendezvous method counts (snowflake#40464) - wrote a fix to get country metrics for ampcache polls (snowflake!591) - opened an issue about FIFO vs LIFO (snowflake#40473) - worked on investigating snowflake rendezvous errors (snowflake#40447) This week: - follow-up on new conjure bridge set up(conjure#46) - start work around snowflake enumeration attacks - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - follow up on snowflake rendezvous failures - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2025-07-24 Last week: Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2024-07-24 Last week: - recommend snowflake in russia over circumventions settings (rdsys-admin!42) - add a prometheus alerts on a drop of snowflake client polls (team#161) - fix the rdsys staging test-authority deploy (tpa/team#41769) - reassign moat bridges (rdsys#233) - review the situation of Tor in Togo (censorship-analysis#40066) - some more report reviews Next week: - wrap up P158 (rdsys staging) Shelikhoo: 2024-07-24 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 - Create new webtunnel release(STALLED BY ISSUE BELOW) - Unexpected Gitlab Runner Failure from Rate Limiting (https://gitlab.torproject.org/tpo/tpa/team/-/issues/42245) - Add Domain Fronting Test Support to probeobserver ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) - Vantge point maintaince - Merge request reviews Next (working) Week/TODO: - Merge request reviews - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) (cont.) - Create webtunnel release v0.0.3 - invesgate webtunnel domain fronting support and dynamic bridge support onyinyang: 2025-07-24 Last week(s): - Finished up work on webtunnel button - Added some logs to help debug https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/249 Next week: - Next is looking into this mystery: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/262#note_3… - Vacation next 2 weeks Switch back to some of these: As time allows: 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: 2025-06-12 Last weeks: - Applying for funding from NLnet to implement DTLS 1.3 in Pion. Got through the first round. - Writing paper for FOCI: continuation of master thesis about reducing distinguishability of DTLS in Snowflake by implementing covert-dtls, further analysis of collected browser fingerprint and stability test of covert-dtls in snowflake proxies. Draft: https://theodorsm.net/FOCI25 - Key takeaways: * covert-dtls is stable when mimicking DTLS 1.2 handshakes, while the randomization approach— though more resistant to fingerprinting — tends to be less stable. * Chrome webextensions are more unstable than standalone proxies * covert-dtls should be integrated in Snowflake proxies as they produce the ClientHello messages during the DTLS handshake. * Chrome randomizes the order of extension list. * Firefox uses DTLS 1.3 by default in WebRTC. * A prompt adoption of DTLS 1.3 in both Snowflake and our fingerprint-resistant library is needed to keep up with browsers * The evolution of browsers’ fingerprints had no noticeable effect on Snowflake’s number of daily users over the last year. * Even with a sharp drop in the amount of proxies, it does not seem to affect the number of Snowflake users. * Browser extensions make Snowflake resistant to ClientHello fingerprinting. * Standalone proxies can serve more Snowflake clients per volunteer than webextensions. * We need metrics on which types of proxies are actually being matched and successfully used by clients. Next weeks: - Getting paper camera ready. - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Help with: - Should we do user testing of covert-dtls? Facilitator Queue: onyinyang 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 -- --- onyinyang GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036

1 0

Anti-censorship team meeting notes, 2025-07-17
by meskio 17 Jul '25

17 Jul '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-07-17-16.00.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, July 24 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… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * == Discussion == == 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): 2025-07-10 Last week: - found and fixed regression in snowflake prometheus stats (snowflake#40470) - met with new conjure bridge operator (conjure#46) - added June Snowflake SQS costs https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - added a clarification to the broker metrics spec (snowflake!577) - updated discussion on client rendezvous errors (snowflake#40447) - fixed up client-polls merge request in snowflake-graphs - https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - opened issue to follow up on reports of short-lived client connections (snowflake#40471) This week: - snowflake-webext version bump and deployment - follow-up on new conjure bridge set up(conjure#46) - start work around snowflake enumeration attacks - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - follow up on snowflake rendezvous failures - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2025-07-10 Last week: - further commenting on a FEP design https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… - snowflake VPS bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - readjusted the snowflake broker resource allocation downward to what it had been before the Iran shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - made graphs of snowflake usage during the Iran shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - did review of client-polls.csv MR in snowflake-graphs https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - opened a Dockerfile MR on behalf of an external user https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - speculated on snowflake proxy WebRTC connections preventing computer from sleeping https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - answered a WebTunnel failure report, weirdly the cause seems to be DNS https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2024-07-17 Last week: - catching up with russian censorship (censorship-analysis#40057) - review reports - catch up after vacation Next week: - wrap up P158 (rdsys staging) Shelikhoo: 2024-07-17 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 - [Deployment] Meek Bridge Offline, we should consider switching to anther hosting provider(https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/16… - [Appoved Merge Request] Bug 41508: Switch built-in meek bridge to meek-unredacted (https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re…) - Vantge point maintaince - Merge request reviews Next (working) Week/TODO: - Merge request reviews - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) (cont.) onyinyang: 2025-07-10 Last week(s): - Mid-year break - Finished up work on webtunnel distribution through telegram: - https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158#note_32… - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/534 - Looking into bridge distribution issues: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/267 - Related to rdsys-admin update on 06/26? - restarted rdsys to see if that helps - Next is looking into this mystery: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/262#note_3… Next week: Finish up webtunnel work on rdsys Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… Switch back to some of these: As time allows: - 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: 2025-06-12 Last weeks: - Applying for funding from NLnet to implement DTLS 1.3 in Pion. Got through the first round. - Writing paper for FOCI: continuation of master thesis about reducing distinguishability of DTLS in Snowflake by implementing covert-dtls, further analysis of collected browser fingerprint and stability test of covert-dtls in snowflake proxies. Draft: https://theodorsm.net/FOCI25 - Key takeaways: * covert-dtls is stable when mimicking DTLS 1.2 handshakes, while the randomization approach— though more resistant to fingerprinting — tends to be less stable. * Chrome webextensions are more unstable than standalone proxies * covert-dtls should be integrated in Snowflake proxies as they produce the ClientHello messages during the DTLS handshake. * Chrome randomizes the order of extension list. * Firefox uses DTLS 1.3 by default in WebRTC. * A prompt adoption of DTLS 1.3 in both Snowflake and our fingerprint-resistant library is needed to keep up with browsers * The evolution of browsers’ fingerprints had no noticeable effect on Snowflake’s number of daily users over the last year. * Even with a sharp drop in the amount of proxies, it does not seem to affect the number of Snowflake users. * Browser extensions make Snowflake resistant to ClientHello fingerprinting. * Standalone proxies can serve more Snowflake clients per volunteer than webextensions. * We need metrics on which types of proxies are actually being matched and successfully used by clients. Next weeks: - Getting paper camera ready. - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Help with: - Should we do user testing of covert-dtls? Facilitator Queue: onyinyang 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

maintenance: Gitaly migration to improve GitLab performance (TPA-RFC-89)
by Antoine Beaupré 14 Jul '25

14 Jul '25

Summary: migrate all Git storage to the new `gitaly-01` back-end, each Git repository read-only during its migration, in the coming week. **Table of Contents** - Proposal - Affected projects - alpha phase, day one (2025-07-14) - beta phase, day two (2025-07-15) - production phase, day two or three (2025-07-15+) - Objections and exceptions - Impact - Projects read-only during migration - Additional complexity for TPA - Timeline - Hardware - Background - Alternatives considered - Full read-only backups - Partial or on-demand migration - References and discussions # Proposal Move all Git repositories to the new [Gitaly][] server during Week 28, progressively, which means it will be impossible to push new commits to a repository while it is migrated. This should be a series of short, scoped outage, as each repository is marked as read-only one at a time when it's migrated. The Gitaly migration procedure seems well test and robust, as each repository is checkedsummed before and after migration. We are hoping this will improve overall performance on the GitLab server, and is part of the design upstream GitLab suggests in scaling an installation of our size. ## Affected projects We plan on migrating the following name spaces in order: ### alpha phase, day one (2025-07-14) This is mostly dogfooding and automation: 1. `anarcat` (already done) 2. `tpo/tpa` 3. `tpo/web` ### beta phase, day two (2025-07-15) This is to include testers outside of TPA yet on projects that are less mission critical and could survive *some* issues with their Git repositories. 4. `tpo/community` 5. `tpo/onion-services` 6. `tpo/anti-censorship` 7. `tpo/network-health` ### production phase, day two or three (2025-07-15+) This is essentially all remaining projects: 8. `tpo/core` (includes c-tor and Arti!) 9. `tpo/applications` (includes Tor Browser and Mullvad Browser) 10. all remaining projects ### Objections and exceptions If you do not want any such disruption in your project, please let us know before the deadline (2025-07-15) so we can skip your project. But we would rather migrate *all* projects off of the server to simplify the architecture and better understand the impact of the change. We would like, in particular, to migrate all of `tpo/applications` repositories in the coming week. Inversely, if you want your project to be prioritized (it might mean a performance improvement!), let us know and you can jump the queue! ## Impact ### Projects read-only during migration While a project is migrated, it is "read-only", that is no change can be done to the Git repository. We believe that other features in projects (like issues and comments) should still work, but the [upstream documentation][] on this is not exactly clear: > To ensure data integrity, projects are put in a temporary read-only > state for the duration of the move. During this time, users receive > a The repository is temporarily read-only. Please try again > later. message if they try to push new commits. So far our test migrations have been so fast (a couple of seconds per project) that we have not really been able to test this properly. ### Additional complexity for TPA TPA will need to get familiar with this new service. [Installation documentation][] is available and all the code developed to deploy the service is visible in an [internal merge request][]. I understand this is a big change right before going on vacation, so any TPA member can veto this and switch to the alternative, a partial or on-demand migration. ## Timeline We plan on starting this work on July 15th, the coming Tuesday. ## Hardware Like the current git repositories on `gitlab-02` the git repositories on `gitaly-01` will be hosted on NVMe disks. # Background GitLab has been having performance problems for a long time now. And for almost as long, we've had the project to "scale GitLab to 2,000 users" ([tpo/tpa/team#40479][]). And while we believe bots (and now, in particular Large Language Models (LLM) bot nets) are responsible for a lot of that load, our [last performance incident][] concluded by observing that there seems to be a correlation between real usage and performance issues. Indeed, during the July break, GitLab's performance was stellar and, on Monday, as soon as Europe woke up from the break, GitLab's performance collapsed again. And while it's *possible* that bots are driven by the same schedule as Tor people, we now feel it's simply time to scale the resources associated with one of our most important services. Gitaly is GitLab's implementation of a Git server. It's basically a web interface to translate (GRPC) requests into Git. It's currently running on the same server as the main GitLab app, but a new server has been built. New servers could be built as needed as well. Anarcat performed [benchmarks][] showing equivalent or better performance of the new Gitaly server, even when influenced by the load of the current GitLab server. It is expected the new server should reduce the load on the main GitLab server, but it's not clear by how much just yet. We're hoping this new architecture will give us more flexibility to deploy new such backends in the future and isolate performance issues to improve diagnostics. It's part of the normal roadmap in scaling a large GitLab installation such as ours. # Alternatives considered ## Full read-only backups We have considered performing a full backup of the entire git repositories before the migration. Unfortunately, this would require setting a read-only mode on all of GitLab for the duration of the backup which, according to our test, could take anywhere from 20 to 60 minutes, which seemed like an unacceptable downtime. Note that we have nightly backups of the GitLab server of course, which is also backed by RAID-10 disk arrays on two different servers. We're only talking about a fully-consistent Git backup here, our normal backups (which, rarely, can be inconsistent and require manual work to reconnect some refs) are typically sufficient anyways. See [tpo/tpa/team#40518][] for a discussion on GitLab backups. ## Partial or on-demand migration We have also considered doing a more piecemeal approach and just migrating some repositories. We worry that this approach would lead to confusion about the real impact of the migration. Still, if any TPA member feels strongly enough about this to put a veto on this proposal, we can take this path and instead migrate a few repositories instead. We could, for example, migrate only the "alpha" targets and a few key repositories in the `tpo/applications` and `tpo/core` groups (since they're prime crawler targets), and leave the mass migration to a later time, with a longer test period. # References and discussions See the [discussion issue][] for comments and more background. [discussion issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42225 [Gitaly]: https://gitlab.com/gitlab-org/gitaly [upstream documentation]: https://docs.gitlab.com/api/project_repository_storage_moves/ [last performance incident]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42152 [Installation documentation]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#gitaly [internal merge request]: https://gitlab.torproject.org/tpo/tpa/puppet-control/-/merge_requests/89 [tpo/tpa/team#40479]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40479 [benchmarks]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42225#note_3223245 [tpo/tpa/team#40518]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40518 -- Antoine Beaupré torproject.org system administration

2 1

Anti-censorship team meeting notes, 2025-07-10
by Shelikhoo 13 Jul '25

13 Jul '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-07-10-16.01.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, July 17 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… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * == Discussion == (July 10 New:) == Actions == == Interesting links == (July 10 New:) * https://github.com/net4people/bbs/issues/496 TLSMirror: Looks like TLS Censorship Resistant Transport Protocol is Looking for Developer Feedback == 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): 2025-07-10 Last week: - found and fixed regression in snowflake prometheus stats (snowflake#40470) - met with new conjure bridge operator (conjure#46) - added June Snowflake SQS costs https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - added a clarification to the broker metrics spec (snowflake!577) - updated discussion on client rendezvous errors (snowflake#40447) - fixed up client-polls merge request in snowflake-graphs - https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - opened issue to follow up on reports of short-lived client connections (snowflake#40471) This week: - snowflake-webext version bump and deployment - follow-up on new conjure bridge set up(conjure#46) - start work around snowflake enumeration attacks - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - follow up on snowflake rendezvous failures - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2025-07-10 Last week: - further commenting on a FEP design https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… - snowflake VPS bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - readjusted the snowflake broker resource allocation downward to what it had been before the Iran shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - made graphs of snowflake usage during the Iran shutdown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - did review of client-polls.csv MR in snowflake-graphs https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - opened a Dockerfile MR on behalf of an external user https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - speculated on snowflake proxy WebRTC connections preventing computer from sleeping https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - answered a WebTunnel failure report, weirdly the cause seems to be DNS https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2024-06-26 Last week: - merge the contaners of rdsys and bridgestrap, the staging server is life... - investigate the changes in webtunnel used in russia to bypass censors (censorship-analisys#40064) - test snowflake proxy patch for Iran (snowflake#40465) - support grant writting Next week: - AFK Shelikhoo: 2024-07-10 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 - [Invesgate, Deployment] Meek Bridge Offline, we should consider switching to anther hosting provider(https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/16… - [Merge Request] Bug 41508: Switch built-in meek bridge to meek-unredacted (https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re…) - Vantge point maintaince - Merge request reviews Next (working) Week/TODO: - Merge request reviews - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) (cont.) onyinyang: 2025-07-10 Last week(s): - Mid-year break - Finished up work on webtunnel distribution through telegram: - https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158#note_32… - https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/534 - Looking into bridge distribution issues: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/267 - Related to rdsys-admin update on 06/26? - restarted rdsys to see if that helps - Next is looking into this mystery: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/262#note_3… Next week: Finish up webtunnel work on rdsys Blog post for conjure: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… Switch back to some of these: As time allows: - 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: 2025-06-12 Last weeks: - Applying for funding from NLnet to implement DTLS 1.3 in Pion. Got through the first round. - Writing paper for FOCI: continuation of master thesis about reducing distinguishability of DTLS in Snowflake by implementing covert-dtls, further analysis of collected browser fingerprint and stability test of covert-dtls in snowflake proxies. Draft: https://theodorsm.net/FOCI25 - Key takeaways: * covert-dtls is stable when mimicking DTLS 1.2 handshakes, while the randomization approach— though more resistant to fingerprinting — tends to be less stable. * Chrome webextensions are more unstable than standalone proxies * covert-dtls should be integrated in Snowflake proxies as they produce the ClientHello messages during the DTLS handshake. * Chrome randomizes the order of extension list. * Firefox uses DTLS 1.3 by default in WebRTC. * A prompt adoption of DTLS 1.3 in both Snowflake and our fingerprint-resistant library is needed to keep up with browsers * The evolution of browsers’ fingerprints had no noticeable effect on Snowflake’s number of daily users over the last year. * Even with a sharp drop in the amount of proxies, it does not seem to affect the number of Snowflake users. * Browser extensions make Snowflake resistant to ClientHello fingerprinting. * Standalone proxies can serve more Snowflake clients per volunteer than webextensions. * We need metrics on which types of proxies are actually being matched and successfully used by clients. Next weeks: - Getting paper camera ready. - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Help with: - Should we do user testing of covert-dtls? Facilitator Queue: meskio onyinyang 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

Anti-censorship team meeting notes, 2025-06-26
by onyinyang 11 Jul '25

11 Jul '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-06-26-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, July 11 16:00 UTC Facilitator:shelikhoo ^^^(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: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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * Mid-year Tor AFK Jun 30-Jul 5, no meeting July 4 == Discussion == * Iran network situation (updates from last week) * references * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * https://github.com/net4people/bbs/issues/484 * https://ntc.party/t/network-shutdown-in-iran-since-2025-06-18/17068 * https://ioda.inetintel.cc.gatech.edu/country/IR?from=1750090308 * network is coming back so there is more information available about how/why snowflake is overloaded * broker or proxy pool is very overloaded * restricted proxy pool is totally exhausted * equal number of matched vs idle proxies * number of clients has doubled since 2025-06-20 https://metrics.torproject.org/userstats-bridge-transport.html?start=2025-0… * snowflake-01 https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6… * snowflake-02 https://metrics.torproject.org/rs.html#details/91DA221A149007D0FD9E5515F578… * community team is asking for more specific+actionable information from the anti-censorship team: not just that we need proxies, but how many proxies? how many users are there in Iran right now? the information needs to be appealing to people outside the tor community. * https://mastodon.social/@torproject/114745109066226826 outreach: "We're still in need of more #snowflake extensions to help keep Iranians connected during this critical time." * our prometheus metrics are the best source of real-time proxy usage, but they are not publicly available. could share screenshots to show the number of matched clients. * Has information on polls per country * https://snowflake-broker.torproject.net/prometheus * snowflake_rounded_client_poll_total has a "cc" field * snowflake-stats metrics in CollecTor * https://gitlab.torproject.org/tpo/community/relays/-/issues/116 "[Snowflake] We need more snowflake proxies" * we now have access to a vantage point: * investigate if snowflake is being blocked by fingerprint or listing proxies * there are reports that google might be reachable in Iran * if so maybe ampcache works and things like champa are useful for people to reach the rest of internet * https://repo.or.cz/champa.git * https://github.com/net4people/bbs/issues/485 * This did indeed work, to a very limited extent. Enough to get connected to Telegram for 10 minutes. * webtunnel bridges block in Russia * https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… * the block seems to be SNI based * the censor is likely to be listing and blocking bridges == Actions == == Interesting links == * https://github.com/pion/webrtc/wiki/Release-WebRTC@v4.0.0#dtls-provides-hoo… == Reading group == * We will discuss "A Wall Behind A Wall: Emerging Regional Censorship in China (Henan firewall)" on June 26 * https://gfw.report/publications/sp25/en/ * 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): 2025-06-26 Last week: - merged and deployed broker metrics rewrite (snowflake#40458) - discussed broker metrics interpretation - https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - reached out to new conjure bridge operator with installation instructions - monitored snowflake overload situation - opened issue to change proxy NAT reassignment (snowflake-webext#118) This week: - follow up on snowflake rendezvous failures - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 dcf: 2025-06-26 Last week: - reviewed snowflake-graphs MR to add client-polls data https://gitlab.torproject.org/dcf/snowflake-graphs/-/merge_requests/1 - refactoring in snowflake-graphs - support during Iran network shutdown Next week: - re-reduce snowflake broker resource allocation https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Help with: meskio: 2024-06-26 Last week: - merge the contaners of rdsys and bridgestrap, the staging server is life... - investigate the changes in webtunnel used in russia to bypass censors (censorship-analisys#40064) - test snowflake proxy patch for Iran (snowflake#40465) - support grant writting Next week: - AFK Shelikhoo: 2024-06-26 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 - Snowfalke Staging Server Experiment - [Deploy] Add Domain Fronting Testing Support to logcollector - [Invesgate] Meek-CDN77 stop working in China (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/162) - Merge request reviews Next (working) Week/TODO: - Merge request reviews - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) (cont.) onyinyang: 2025-06-26 Last week(s): - Started looking into unresolved lox issues, signalling channel library - Pivoted to webtunnel distribution through telegram: -https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158#note_3210454 -https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/534 Next week: Mid-year break Finish up webtunnel work on rdsys Switch back to some of these: As time allows: - 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: 2025-06-12 Last weeks: - Applying for funding from NLnet to implement DTLS 1.3 in Pion. Got through the first round. - Writing paper for FOCI: continuation of master thesis about reducing distinguishability of DTLS in Snowflake by implementing covert-dtls, further analysis of collected browser fingerprint and stability test of covert-dtls in snowflake proxies. Draft: https://theodorsm.net/FOCI25 - Key takeaways: * covert-dtls is stable when mimicking DTLS 1.2 handshakes, while the randomization approach— though more resistant to fingerprinting — tends to be less stable. * Chrome webextensions are more unstable than standalone proxies * covert-dtls should be integrated in Snowflake proxies as they produce the ClientHello messages during the DTLS handshake. * Chrome randomizes the order of extension list. * Firefox uses DTLS 1.3 by default in WebRTC. * A prompt adoption of DTLS 1.3 in both Snowflake and our fingerprint-resistant library is needed to keep up with browsers * The evolution of browsers’ fingerprints had no noticeable effect on Snowflake’s number of daily users over the last year. * Even with a sharp drop in the amount of proxies, it does not seem to affect the number of Snowflake users. * Browser extensions make Snowflake resistant to ClientHello fingerprinting. * Standalone proxies can serve more Snowflake clients per volunteer than webextensions. * We need metrics on which types of proxies are actually being matched and successfully used by clients. Next weeks: - Getting paper camera ready. - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) Help with: - Should we do user testing of covert-dtls? Facilitator Queue: meskio onyinyang 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

2 1

User Support Report for June 2025
by ebanam 11 Jul '25

11 Jul '25

Hello everyone, Following is the report from user support team for the month of June. 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 ## Farsi-speaking user support Last month, in light of the conflict[1], we received a lot of tickets from users trying to connect to Tor from Iran. Due to the severe censorship imposed on the internet and at times, total internet disruptions (i.e Iran blocking international connections), users haven't been able to connect to the internet reliably and, consequently, to the Tor network. Throughout this time, we have been gathering feedback and information from users who were able to contact us on our user support channels. At the moment, highly depending on factors like the region the user is connecting from and internet service provider (ISP), users in Iran might be able to connect to Tor with Snowflake and other pluggable transports. Haidi worked on localized user support for Farsi-speaking users which included but was not limited to helping users to troubleshoot, gather feedback and help with instructions to use censorship circumvention methods in Tor Browser Desktop and Android and other Tor powered apps (like Orbot and Onion Browser). Due to the urgent situation caused by the conflict; Haidi, ebanam and Gus made it a top priority to help users in Iran get connected. * 195 tickets in total (↑159 as compared to May) * 157 tickets on Telegram * 38 tickets on Email ## Russian-speaking user support In June, we observed the first instances of WebTunnel bridge blocking on a few ISPs in Russia[2]. This new wave of blocking is likely the main factor behind the increased number of support tickets from Russia in June and reflects a broader tightening of censorship in the country[3]. Nina worked on reviewing, answering and processing feedback from Google Play Store comments and localized user support for Russian-speaking users which included but was not limited to helping users with instructions to use censorship circumvention methods in Tor Browser Desktop and Android and other Tor powered apps (like Orbot, Onion Browser, Tails), troubleshoot and gather user feedback. * 1335 tickets in total (↑197 as compared to May) * 1146 tickets on Telegram * 188 tickets on Email * 1 ticket on WhatsApp ## General user support ebanam worked on Tor Browser user support related tasks prior to and after Tor Browser releases; updated user-facing documentation in the Tor Browser User Manual and the Support Portal and helping users in regions where Tor is censored which included but was not limited to helping users with instructions to use censorship circumvention methods that work best, troubleshoot, censorship analysis and gathering user feedback. For the past few months, we have been receiving relatively higher number of tickets from users trying to connect to Tor from China, given that most of obfs4 bridges shared by rdsys have not been working. Users trying to unblock Tor from China, will have to use bridges with WebTunnel pluggable transport. For instructions on fetching WebTunnel bridges and using them with Tor Browser, refer to the "How to circumvent the Great Firewall and connect to Tor from China?" article on the Support Portal.[4] With WebTunnel bridges working much more reliably in regions where Tor is being censored, like in Russia and China, we have received feedback from users using Tails to provide support for WebTunnel bridges[5]. In June, we received a couple of tickets about this. In June, Nina and ebanam investigated why Tor Browser for Android users are having issues related to the browsing speed[6] and we're planning to investigate more of this issue in July. * 701 tickets in total (↓7 as compared to May) * 404 tickets on Email * 266 tickets on Telegram * 17 tickets on WhatsApp * 14 tickets on Signal That's it for the summary, following is a more detailed report about the tickets our user support team worked on last month. # Frontdesk (email user support channel) * 762(↓) RT tickets created * 693(↓) RT tickets resolved Tickets by topics and numbers: 1. 318(↓) tickets: instructions to circumvent censorship for Chinese speaking users. 2. 188(↓) tickets: circumventing censorship in Russian speaking countries. 3. 70(↓) tickets: help with troubleshooting existing Tor Browser install on Desktop (Windows, macOS and Linux). 4. 37(↑) tickets: circumventing censorship with Tor in Farsi. 5. 4(↓) tickets: reports of websites blocking Tor connections or not performing well in Tor Browser. 6. 3(↓) tickets: help with troubleshooting existing Tor Browser install on Android. 7. 3(↑) tickets: help with the correct Tor app to install on iOS (Onion Browser). 8. 3(↑) tickets: queries from Tor relay operators. 9. 2(↑) tickets: questions about Letterboxing in Tor Browser. 10. 2(↑) tickets: help with installing Tor Browser on Desktop on Linux. 11. 2(↑) tickets: queries and feedback about the changes to Security Levels in latest versions of Tor Browser.[7] 12. 2(↑) tickets: questions about "Dark Mode" in Tor Browser.[8] 13. 1(↑) ticket: report of Tor Browser being slow.[9] # Telegram, WhatsApp and Signal user support channels * 1779(↑) tickets resolved Breakdown: * 1746(↑) tickets on Telegram * 18(↑) tickets on WhatsApp * 15(↓) tickets on Signal Tickets by topics and numbers: 1. 1238(↑) tickets: circumventing censorship in Russian speaking countries. 2. 157(↑) tickets: circumventing censorship with Tor in Farsi. 3. 63(↑) tickets: instructions to circumvent censorship for Chinese speaking users. 4. 37(↑) tickets: helping users on iOS, using Onion Browser or Orbot, to use censorship circumvention methods. 5. 14(↑) tickets: help with instructions to use bridges with Orbot. 6. 10(↓) tickets: help with troubleshooting Tor Browser Android. 7. 10(↓) tickets: instructions on how to get Tor Browser binaries from GetTor. 8. 8(↓) tickets: help with troubleshooting Tor Browser Desktop on Windows, macOS and Linux. 9. 5(↑) ticket: help with using Snowflake with Tor to circumvent censorship. 10. 4(↓) tickets: help with instructions to use bridges with Tails. 11. 3(-) tickets: questions about onion services and how to access them. 12. 3(↑) tickets: help with instructions to use pluggable transports with little-t tor. 13. 2(↓) tickets: users seeing a "proxy refused" error when visiting websites on Tor Browser for Android using Samsung devices. 14. 2(↑) tickets: instructions to verify Tor Browser's GPG signature. 15. 1(↑) ticket: instructions to download Tor Browser 13.5 legacy for legacy operating systems. # Topics from the Tor Forum * Static Captcha when fetching bridges from within Tor Browser.[10] * Censorship of Tor in Russia.[11] # Highlights from Google Play Store * Tor Browser for Android had a Google Play rating of 4.386 (↓0.021) stars in June, lower as compared to in May. * In June, Tor Browser for Android (TBA) got 725 (↑100) new reviews. With the total count of reviews for the app standing at 63,311. * Tor Browser for Android Alpha (TBA - Alpha) app had a rating of 4.184 (↓0.029) stars in June, lower as compared to in May. * In June, Tor Browser for Android (TBA - Alpha) got 26 (↓19) new reviews. With the total count of reviews for the app standing at 8,599. Like last month, the major complaints we got about Tor Browser for Android were related to browsing speed. Thanks! -- ebanam [1]: https://github.com/net4people/bbs/issues/484 [2]: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… [3]: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… [4]: https://support.torproject.org/censorship/connecting-from-china/ [5]: https://gitlab.tails.boum.org/tails/tails/-/issues/20267 [6]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43841 [7]: https://forum.torproject.org/t/feedback-proposal-for-securitylevel-module-f… [8]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40337 [9]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43841 [10]: https://forum.torproject.org/t/captcha-when-fetching-bridges-in-tor-browser… [11]: https://forum.torproject.org/t/so-russia-began-blocking-webtunnel-bridges-w…

1 0

meeting minutes
by Antoine Beaupré 07 Jul '25

07 Jul '25

# Roll call: who's there and emergencies anarcat, groente, lelutin and zen present # Dashboard review ## Normal per-user check-in * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… * https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&utf8=%E2%9C%93&… ## General dashboards: * https://gitlab.torproject.org/tpo/tpa/team/-/boards/117 * https://gitlab.torproject.org/groups/tpo/web/-/boards * https://gitlab.torproject.org/groups/tpo/tpa/-/boards # Third quarter priorities and coordination https://gitlab.torproject.org/tpo/tpa/team/-/wikis/meeting/2025-06-16#secon… Planned work: - vacations! anarcat and lavamind are AFK for 3 weeks each in the quarter - YEC is coming up - trixie batch two, some of batch 3 (puppet/ganeti?) - rdsys and snowflake containerization - authentication merge plan (still being developed) - minio cluster in production (currently in development) - puppet merge work has definitely started, steps A-D done, E-K next # Metrics of the month * host count: 96 * number of Apache servers monitored: 33, hits per second: 659 * number of self-hosted nameservers: 6, mail servers: 96 * pending upgrades: 172, reboots: 72 * average load: 1.34, memory available: 4.3 TB/6.5 TB, running processes: 165 * disk free/total: 66.9 TB/169.5 TB * bytes sent: 530.9 MB/s, received: 355.2 MB/s * [GitLab tickets][]: 241 tickets including... * open: 0 * icebox: 132 * roadmap::future: 44 * needs information: 6 * backlog: 28 * next: 17 * doing: 6 * needs review: 8 * (closed: 4136) * [~Technical Debt][]: 12 [Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards [~Technical Debt]: https://gitlab.torproject.org/groups/tpo/tpa/-/issues/?state=opened&label_n… Upgrade prediction graph lives at https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/trixie/ Now also available as the main Grafana dashboard. Head to <https://grafana.torproject.org/>, change the time period to 30 days, and wait a while for results to render. -- Antoine Beaupré torproject.org system administration

1 0

PieroV's Monthly Status Report, June 2025
by Pier Angelo Vendrame 02 Jul '25

02 Jul '25

Hi everyone, Here is my status report for June 2025. During the first week of the month, I attended the web engines hack fest [wehf]. After I came back, I've worked only on the ESR transition. First, I've finalized the toolchain updates [tor-browser-build!1212] [tor-browser-build!1232]. It took me a while to complete the MR for Android because we might have a reproducibility problem caused by the R8 optimizer [tor-browser-build#41495]. Eventually, I decided to send the MR for review, and to come back to reproducibility problems we might find when building 15.0a1. Also, I investigated our new APK sizing problems and modified our scripts to build little-t-tor and its dependencies with clang's option `-Oz` [tor-browser-build!1242]. In this way, we saved almost 400kB, which is not bad at all, considering our limit is 100MB. Then, when 140.0esr was released upstream, I rebased onto it. However, I still haven't opened an MR because we are switching to Firefox's new git history for it, and we needed to assess the effects on our infrastructure first. Finally, I commented the HTML version of the range-diff between 128 and 140-based Tor Browser, for making the review easier [tor-browser#43852]. Best, Pier [tor-browser#43852] https://gitlab.torproject.org/tpo/applications/tor-browser/-/work_items/438… [tor-browser-build#41495] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… [tor-browser-build!1212] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… [tor-browser-build!1232] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… [tor-browser-build!1242] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… [wehf] https://webengineshackfest.org/

1 0

Rhatto's Monthly Status Report, June 2025
by rhatto 27 Jun '25

27 Jun '25

Hi all :) This is my monthly status report for June 2025 with the main relevant activities I have done, was involved or are related to my work during the period. * Revived Chutney functional tests: https://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/4 Example job: https://gitlab.torproject.org/rhatto/onionbalance/-/jobs/1033518 * Ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. * Also took some time to improve my workflow. -- Silvio Rhatto pronouns he/him

1 0

Changing Applications Team Meeting
by Morgan 26 Jun '25

26 Jun '25

Hi everyone, The Applications Team will no longer be holding our weekly team planning meetings in #tor-meeting on Mondays. Instead, we will be holding office-hours in #tor-meeting on Wednesdays from 1700 to 1800 UTC. Our first office-hours will be on 9 July after our break next week. We are of course also available in #tor-browser-dev throughout the work-week. See you all on the internet .o/ best, -morgan

1 0