- tor-project - lists.torproject.org

Anti-censorship team meeting notes, 2025-03-20
by Shelikhoo 20 Mar '25

20 Mar '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-03-20-16.01.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday,March, 27 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 == Mar 20 New: * Snowflake Staging Server & rdsys containerization * TPA supported system doesn't allow to have more than one domain name per branch in a staging server * snowflake needs two: broker and server * shelikhoo is experiments with k8s + terraform * shelikhoo will keep working on this since there is no overall rejection to this design == Actions == == Interesting links == * https://github.com/doudoulong/Minecruft-PT/blob/main/README.md#tor-browser-… == Reading group == * We will discuss "Differential Degradation Vulnerabilities in Censorship Circumvention Systems" on April 3 * https://arxiv.org/abs/2409.06247 * 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-03-20 Last week: - found and fixed cause of sqs rendezvous errors (snowflake#40363) - implemented better timeouts at broker for client offers (snowflake#40449) - lower proxy answerTimeout for web-based proxies (snowflake-webext#115) - remove bad relay pattern log message and default-relay-pattern option for broker (snowflake#40454) - followed up on Snowflake rendezvous errors in general (snowflake#40447) - tagged and released snowflake proxy v2.11.0 - confirmed fixes for domain fronting issues on old android versions (lyrebird#40012) - opened issue to update PTs in Tor Browser (tor-browser-build#41299) - released snowflake-webext 0.9.3 This week: - support conjure work - follow up on snowflake rendezvous failures - reduce/remove use of mutexes for broker metrics (snowflake#40458) - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 - maybe do some lox work dcf: 2025-03-20 Last week: - archived a Kazakhstan URL blocklist https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Next week: - archive snowflake-webextension-0.9.3 - 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-03-20 Last week: - build rdsys containers in the CI (rdsys#219) - stop distributing dysfunctional bridges (team#156) - downgrade lyrebird to use go 1.22 (lyrebird#40026) - release lyrebird 0.6.0 - test covertdtls MR proxy (snowflake!448) - debug dependency proxy for snowflake (snowflake!522) Next week: - steps towards a rdsys in containers (rdsys#219) Shelikhoo: 2024-03-20 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 - Snowflake Staging Server Discussion(https://gitlab.torproject.org/tpo/tpa/team/-/issues/42080) - Snowfalke Staging Server Experiment - Merge request reviews Next Week/TODO: - Merge request reviews - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Snowfalke Staging Server Experiment onyinyang: 2025-03-13 Last week(s): - continued work on ampcache registration method for conjure - WIP MR: https://github.com/cohosh/conjure/pull/1 - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - lox issuer efficiency merged! Next week: - HACS/Zkproofs/OSCW/RWC - finish up ampcache registration method - Begin work on decoy registration option - 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 As time allows: - 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-03-06 Last weeks: - Implementing key_share extension support in covert-dtls - Implementing mimicking DTLS 1.3 extensions - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Update MR with new covert-dtls version. - Write instructions on how to configure covert-dtls with snowflake client - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake 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

TPA-RFC-83: Mail log retention
by Antoine Beaupré 18 Mar '25

18 Mar '25

Summary: extend the retention limit for mail logs to 10 days # Background We currently rotate mail logs daily and keep them for 5 days. That's great for privacy, but not so great for people having to report mail trouble in time. In particular, when there are failures with mail sent just before the weekend, it gives users a very short time frame to report issues. # Proposal Extend the retention limit for mail (`postfix` and `rspamd`) logs to 10 days: one week, plus "flexible Friday", plus "weekend". ## Goals Being able to debug mail issues when users notice and/or report them after five days. ## Tasks Adjust logrotate configuration for syslog-ng and rspamd. ## Scope All TPA servers. ## Affected users Sysadmins and email users, which is pretty much everyone. ## Timeline Logging policies will be changed on Wednesday March 19th. # References TPA has various log policies for various services, which we have been meaning to document for a while. This policy proposal doesn't cover for that, see [tpo/tpa/team#40960][] for followup on that more general task. [tpo/tpa/team#40960]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40960 See also the [discussion issue][]. [discussion issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42081 -- Antoine Beaupré torproject.org system administration

1 0

Anti-censorship team meeting notes, 2025-03-13
by onyinyang 13 Mar '25

13 Mar '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-03-13-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, March 20 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 == * snowflake dependencies need go 1.23 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * should we update it? * go 1.23 is already in debian backports * Tor Browser is already using go 1.23? * no, Tor Browser is staying on 1.21 on macOS until ESR 140, due June 2025 * we will hold off on the dependency updates (which contain changes we believe do not affect us) until after ESR 140 and Tor Browser updating to go 1.23 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * should we change default relay pattern policy on snowflake broker * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * we still have relays that have not updated since we added support for multiple bridges * The purpose of the allowed relay pattern check at the broker is not to avoid surprising proxy operators by connecting to a new relay destination; it's because old proxies that do not send a relay pattern to the broker cannot connect to any other relay destination. They have snowflake.torproject.net hardcoded and do not know how to connect to any other relay. If a client were to request a connection to the snowflake-02 relay, and was assigned such an old proxy, the proxy would connect to snowflake-01 anyway, and leave the client with a Tor fingerprint mismatch error. * Therefore adjusting the presumedPatternForLegacyClient on the broker to accept old proxies would not work. Old proxies (that don't support relay patterns) would start getting clients again, but any clients that request a relay other than snowflake-01 would get failed connections. * There's no facility on the broker to, say, match old proxies only with those clients that happen to request snowflake-01. Once a proxy is in the pool, it's treated equally to all other proxies. Such a matching facility could conceivably be implemented, but none currently exists. It may not be worth the complexity anyway. * The intention therefore was that the broker simply reject old proxies (that do not send a relay pattern). That is, in effect, what is now happening, but it happens by a roundabout way: proxy polls and doesn't set an allowed relay pattern → broker assigns a default allowed relay pattern that never works → broker rejects the proxy poll because of the relay pattern mismatch. * The downsides of the status quo are that (1) the broker logs are full of "rejected relay pattern from proxy" errors, and (2) the old proxies just keep on uselessly polling. * Consensus for dealing with the current situation: * Make the broker code more straightforward with respect to rejecting old proxies: do it at an early stage, don't even bother assigning a default relay pattern to them (and remove the code that does). * Update metrics/logging. Disable the "rejected relay pattern from proxy" at the broker, and just keep it as a metrics counter. * For the future, it would be handy if there were a feature whereby the broker, by sending a specific kind of response to a proxy, could cause the proxy to disable itself (say, stop polling for 24h) and log a visible message to the operator. In effect, we could push the "rejected relay pattern from proxy" error out to the proxy logs, which would (1) stop proxies that only support an obsolete protocol from uselessly polling, and (2) inform the operator and encourage them to upgrade. * In the absence of such a feature, it might be possible to find a way to crash old proxies by sending a specific kind of broker response. For example, an overlong HTTP body, or a JSON unmarshaling error. Even if it is not possible to convey a reason why it is happening to the proxy operator, it might get the operators attention, and at least reduce unhelpful polling volume. * One complication with this idea: some proxies are running in a container, or similar, and are configured to auto-restart after they exit. Proxies that work this way might paradoxically increase their effective polling rate if remotely disabled, because there's no interval rate limiting on the first poll. * Even so, if we find such a "disable" broker response, we could try having the broker send it to old proxies (those that don't support relay patterns) for 1h. The ones that are configured to restart will restart, but the one that are not will stop operating. * Related issue: "Let the broker inform proxies how often to poll" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…. The broker could send a time many hours in the future. This would help with reducing the polling rate, even if it does not result in the proxy log message. * A standalone proxy auto-update mechanism could be an alternative or addition to support for a broker "disable" signal. == 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-03-13 Last week: - wrote and deployed a CPU and goroutine profiling patch for the snowflake broker (snowflake#40447) - found a potential performance improvement related to mutexes (snowflake#40458) - confirmed that congestion isn't the cause of sqs rendezvous errors (snowflake#4036) - found source of "rejected relay pattern" log messages (snowflake#40454) - modified broker metrics to show client polls that timed out (snowflake!530) - reviewed merge requests - helped with conjure pt work This week: - support conjure work - follow up on snowflake rendezvous failures - reduce/remove use of mutexes for broker metrics (snowflake#40458) - set absolute time limit on broker http responses (snowflake40449) - snowflake proxy release - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 - maybe do some lox work dcf: 2025-03-13 Last week: - snowflake VPS hosting bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… 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-03-13 Last week: - set up snowflake proxies with coverdtls (snowflake!448) - investigate why our email distributor is not handing out emails (rdsys#260) - debug gitlab container proxy (snowflake!522) - investigate why users get bridges with local addresses (team#156) Next week: - steps towards a rdsys in containers (rdsys#219) - investigate rdsys distributing local addressed bridges (team#156) Shelikhoo: 2024-03-13 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 - Vantage Point maintaince - Merge request reviews Next Week/TODO: - Merge request reviews - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Snowflake Staging Server Discussion(https://gitlab.torproject.org/tpo/tpa/team/-/issues/42080) - Vantage Point maintaince onyinyang: 2025-03-13 Last week(s): - continued work on ampcache registration method for conjure - WIP MR: https://github.com/cohosh/conjure/pull/1 - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… - lox issuer efficiency merged! Next week: - HACS/Zkproofs/OSCW/RWC - finish up ampcache registration method - Begin work on decoy registration option - 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 As time allows: - 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-03-06 Last weeks: - Implementing key_share extension support in covert-dtls - Implementing mimicking DTLS 1.3 extensions - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Update MR with new covert-dtls version. - Write instructions on how to configure covert-dtls with snowflake client - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake 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

Haidi February '25 Report
by Haidi 11 Mar '25

11 Mar '25

Hi! Below is my February’25 (Period: 2025-02-01 - 2025-02-28) report! In February, I began working on tests and documentation, focusing on integrating pluggable transports with little-t-tor on Windows. I then collected data across different operating systems and contributed to the corresponding GitLab documentation ticket. Spent some time learning the workflow for merging and committing documents in GitLab for the Tor Project. *Add documentation about using pluggable transports with little-t-tor* <https://gitlab.torproject.org/tpo/web/support/-/issues/378#top> https://gitlab.torproject.org/tpo/web/support/-/issues/378 Thanks, Haidi

1 0

minutes from the sysadmins
by Antoine Beaupré 10 Mar '25

10 Mar '25

Hi, We had a quick monthly meeting, here are the minutes. # Roll call: who's there and emergencies anarcat, groente, lavamind, lelutin and zen. lavamind and groente star. Tails pipelines are failing because of issues with the debian APT servers, zen and groente will look into it. # Checkin 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> # Roadmap review We reviewed the spreadsheet with plans for March. # Puppet merge broad plan Work is starting in March, there doesn't seem to be objections to the plan. We'll need volunteers to start work on TPA's side as well. anarcat will start haggling people near the end of March, hopefully. # Next meeting As usual. # Metrics of the month * hosts in Puppet: 89, LDAP: 89, Prometheus exporters: 583 * number of Apache servers monitored: 33, hits per second: 679 * number of self-hosted nameservers: 6, mail servers: 89 * pending upgrades: 0, reboots: 0 * average load: 1.57, memory available: 2.95 TiB/5.11 TiB, running processes: 187 * disk free/total: 58.40 TiB/143.90 TiB * bytes sent: 467.62 MB/s, received: 296.47 MB/s * [GitLab tickets][]: 246 tickets including... * open: 0 * icebox: 148 * future: 46 * needs information: 6 * backlog: 24 * next: 7 * doing: 9 * needs review: 7 * (closed: 3980) [Gitlab tickets]: https://gitlab.torproject.org/tpo/tpa/team/-/boards -- Antoine Beaupré torproject.org system administration

1 0

Felicia's Monthly Status Report, February 2025
by Priscila 10 Mar '25

10 Mar '25

Hi everyone, This is my status report for February 2025. It’s a list of all tasks I’ve been involved in/responsible for. ## Design tasks 1. Review error prompt shown when Tor exits: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43186 2. Warn users about Connection Assist removing user-added bridges: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42546 3. Improvements to the “Use bridges” toggle in Connection settings: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43483 4. Design a banner to recruit survey participants: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43489 5. Make Android’s Connection settings consistent with the VPN: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41187 6. Validate user added bridge addresses on Android: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42633 7. Allow authentication of Onion Services on Android: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31672 ## UX support 1. 2 buttons displayed onion-available and connect when Tor daemon killed: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43406 2. Handle failing to apply tor settings: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43405 3. Allow user use Connection Assist at any time: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43435 4. Show the urlbar Connect button during a bootstrap or final error: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43465 Best, Priscila (aka Felicia) - UX Team

1 0

GitLab Account Request for GSoC Contribution
by harshita roonwal 10 Mar '25

10 Mar '25

Hello Tor Project Team, I am interested in contributing to the Tor Project as part of Google Summer of Code (GSoC) 2025. Specifically, I want to work on the Relay to Relay Connectivity in the Tor Network project. To do so, I need access to GitLab for: - Reviewing and discussing project issues. - Contributing code and submitting merge requests. - Communicating with mentors and other contributors. Here are my details: - Name: Harshita Roonwal - Preferred Username: harshita_r - Email Address: roonwal721972(a)gmail.com - GSoC Project Interest: Relay to Relay Connectivity in the Tor Networ Looking forward to your approval. *Best Regards*

1 0

Anti-censorship team meeting notes, 2025-03-06
by meskio 06 Mar '25

06 Mar '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-03-06-16.00.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday,March 11 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 == * There is a new version of the snowflake website * https://snowflake.torproject.org/ * https://blog.torproject.org/snowflake-refresh-to-help-more-people-get-onlin… * you can help translating it: * https://hosted.weblate.org/projects/tor/snowflake-web/ == Discussion == * Should we user test snowflake with covert-dtls? It is difficult to force Snowflake client to become the DTLS client: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * "After some debugging, reading the pion webrtc source code, and referencing RFC 5763 (DTLS-SRTP framework) I realized why hook was never triggered. The Snowflake client will almost always become the server in the DTLS handshake as sends the SDP Offer every time. According to the RFC, only the offer can decide who becomes the client or server." * we'll use the testing setup of a broker, bridge, ... that we plan to do also for the unreliable transport * meskio will update his proxies to test the new developments on covertls (DTLS 1.3) * snowflake broker match failure rate is high? * high number of 504 errors https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * lots of client poll timeout log messages https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * SQS rendezvous seems to perform badly under high load https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * removing the rate limit at the broker didn't fully address issues https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * cohosh will prepare a MR for the broker using pprof to monitor if there are goroutinges being blocked * we'll discuss with this MR if we want to deploy it in production == Actions == == Interesting links == * https://forum.torproject.org/t/snowflake-daily-operations-february-2025-upd… * Snowflake users still declining month by month * https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6… * https://metrics.torproject.org/rs.html#details/91DA221A149007D0FD9E5515F578… == 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-03-06 Last week: - AWS accounting - followed up on SQS errors (snowflake#40363) - worked on a fix for broken shadow integration tests (snowflake#40456) - helped debug conjure registration work (conjure#43) - did some tests to figure out cause of snowflake broker failure rate (snowflake#40447) This week: - support conjure work - follow up in snowflake rendezvous failures - take a look at potential snowflake orbot bug - https://github.com/guardianproject/orbot-android/issues/1183 - maybe do some lox work dcf: 2025-03-06 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-03-06 Last week: - config as env variables for dsys private data (rdsys#219) - remove moat shim token and dummy bridges - improvements on rdsys docker images - investigate how the gitlab container dependency proxy works (snowflake!522) Next week: - steps towards a rdsys in containers (rdsys#219) Shelikhoo: 2024-03-06 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 - Vantage Point maintaince - Merge request reviews Next Week/TODO: - Merge request reviews - [Testing] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2025-03-06 Last week(s): - continued work on ampcache registration method for conjure - WIP MR: https://github.com/cohosh/conjure/pull/1 - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… Next week: - finish up ampcache registration method (sqs on hold for now) - Begin work on decoy registration option - 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 As time allows: - 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-03-06 Last weeks: - Implementing key_share extension support in covert-dtls - Implementing mimicking DTLS 1.3 extensions - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Update MR with new covert-dtls version. - Write instructions on how to configure covert-dtls with snowflake client - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake 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

ebanam's monthly report and user support report for February 2025
by ebanam 05 Mar '25

05 Mar '25

Hello everyone, Most of my work last month focussed on helping users in regions where Tor is censored, which includes helping users with instructions to download Tor Browser binaries from GetTor and/or official mirrors, verifying Tor Browser's GPG signature, help with using censorship circumvention methods that works best for them and overall troubleshooting. I wrote some documentation[0] about the emergency downgrade for Tor Browser on macOS resulting from the Tor Browser bug#43468[1] and worked on a number of tasks before and after the merge cdr.link instances(ticketing system for our WhatsApp, Signal and Telegram support channels)[2]. Following is a more detailed report about the tickets our user support team worked on last month. # Frontdesk (email user support channel) * 535(↓) RT tickets created * 574(↓) RT tickets resolved Tickets by topics and numbers: 1. 326(↓) RT tickets: instructions to circumvent censorship for Chinese speaking users. 2. 106(↓) RT tickets: circumventing censorship in Russian speaking countries. 3. 16(↑) RT tickets: help with troubleshooting existing Tor Browser install on Desktop (Windows, macOS and Linux). 4. 5(↑) tickets: bug on Tor Browser for macOS "ScreenCaptureKit framework should be a weak link" (the issue is resolved with Tor Browser 14.0.6)[1]. 5. 4(↓) RT tickets: WebTunnel bridges campaign. 6. 4(↑) RT tickets: reports of a fake apps on iOS AppStore masquerading as official Tor Browser. 7. 3(↓) RT tickets: questions about how Tor works - is my IP visible when using Tor? what application level protections I get when using Tor Browser? what are 'Security Levels' in the Tor Browser etc. 8. 3(↓) RT tickets: questions about setting up a bridge relay or snowflake proxy. 9. 2(-) RT tickets: help with troubleshooting Tor Browser Android. 10. 2(↑) RT tickets: help with instructions to use bridges with Tails. 11. 2(↑) RT tickets: users seeing a "proxy refused" error when visiting websites on Tor Browser[3] 12. 2(↑) RT tickets: issues with Ubuntu packages on deb.torproject.org and its Onion Service[4]. 13. 1(↓) RT ticket: reports of websites blocking Tor connections. 14. 1(↓) RT ticket: help with instructions to verify Tor Browser's GPG signature. 15. 1(↓) RT ticket: questions about how one can contribute to Tor - code, documentation, localization, etc. 16. 1(↑) RT ticket: Universal 2nd Factor (U2F) (i.e. YubiKey) support is disabled in Tor Browser[5]. 17. 1(-) RT ticket: instructions to download Tor Browser 13.5 legacy for legacy operating systems. 18. 1(↑) RT ticket: Windows' built-in on-screen keyboard not working with Tor Browser[6]. 19. 1(↑) RT ticket: video rendering issues on Youtube due to blocking of canvas fingerpriting on Tor Browser[7]. 20. 1(↑) RT ticket: "New Identity" feature not available on Tor Browser for Android[8]. 21. 1(↑) RT ticket: static Captcha when requesting bridges in Tor Browser[9]. 22. 1(↓) RT ticket: reports of anti-virus software blocking Tor Browser. 23. 1(↑) RT ticket: issue with signing up for Tor Weather. 24. 1(↓) RT ticket: question about onion services and how to access them. # Telegram, WhatsApp and Signal user support channels * 671(↓) tickets resolved Breakdown: * 653(↓) tickets on Telegram * 14(↓) tickets on WhatsApp * 4(↑) tickets on Signal Tickets by topics and numbers: 1. 365(↓) tickets: circumventing censorship in Russian speaking countries. 2. 28(↓) tickets: instructions to circumvent censorship for Chinese speaking users. 3. 16(↑) tickets: help with troubleshooting Tor Browser Desktop on Windows, macOS and Linux. 4. 12(↓) tickets: helping users on iOS, using Onion Browser or Orbot, to use censorship circumvention methods. 5. 6(↑) tickets: help with troubleshooting Tor Browser Android. 6. 5(↑) tickets: help with using bridges and snowflake with little-t-tor. 7. 5(↑) tickets: help with instructions to use bridges with Tails. 8. 4(↑) tickets: instructions on how to get Tor Browser binaries from GetTor. 9. 3(↓) tickets: questions about onion services and how to access them. 10. 1(↑) ticket: bug on Tor Browser for macOS "ScreenCaptureKit framework should be a weak link" (the issue is resolved with Tor Browser 14.0.6). 11. 1(↑) ticket: issues with Ubuntu packages on deb.torproject.org and its Onion Service. 12. 1(↓) ticket: users seeing a "proxy refused" error when visiting websites on Tor Browser for Android using Samsung devices. # Highlights from the Tor Forum 1. Download Tor Browser 13.5 legacy on Windows 7, 8 and 8.1 and macOS 10.12, 10.13 and 10.14[10]. 2. "New Identity" and canvas fingerprinting protections in Tor Browser[11]. 3. Tor Browser crashes on Windows 11.[12] 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. best, e. [0]: https://gitlab.torproject.org/tpo/community/support/-/issues/40183 [1]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43468 [2]: https://gitlab.torproject.org/tpo/community/support/-/issues/40181 [3]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42714 [4]: https://status.torproject.org/issues/2025-02-25-ubuntu-packages/ [5]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34193 [6]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40794 [7]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43482 [8]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28800 [9]: https://forum.torproject.org/t/always-the-same-captcha-when-requesting-brig… [10]: https://forum.torproject.org/t/download-tor-browser-13-5-legacy-on-windows-… [11]: https://forum.torproject.org/t/is-new-identity-enough-to-protect-me-as-i-ne… [12]: https://forum.torproject.org/t/tor-launches-and-the-firefox-browser-quits-i…

1 0

Nina’s Monthly Status Report, February, 2025
by Nina 05 Mar '25

05 Mar '25

Hi! Below is my February’25 report! In February, I resolved 567 (↓337) tickets: * On Telegram (@TorProjectSupportBot) - 461 (↓251); * On RT (frontdesk@tpo) - 106 (↓85); * On WhatsApp (+447421000612) - 0 (0); * And on Signal (+17787431312) - 0 (0). My main focus in February was helping Russian-speaking users bypass censorship. I shared instructions, gathered user feedback, and helped troubleshoot any issues they were facing with Tor Browser. I also worked on providing feedback for Google Play Store users' reviews. In February I took part in translation Tor Browser user survey to Russian[1], updated the issue about the virtual keyboard not working on tablets with Windows [2], and investigated canvas issues [3]. Also in February the user support team dealt with the issue of Tor Browser not working on older MacOS devices [4][5]. The issue was fixed in Tor Browser 14.0.6. *##**Google Play Reviews for Tor Browser**(TBA)**and Tor Browser Alpha**for Android* * Tor Browser for Android had a Google Play rating of 4.397 (↑0.015) stars in February, which is higher than in January'25. * Tor Browser for Android (TBA) got 615 (↓142) reviews out of 60,916 for the lifetime. * Tor Browser for Android Alpha (TBA-Alpha) app had a rating of 4.219 (↓0.009) which is lower than in January'25. * In February, Tor Browser for Android (TBA-Alpha) got 42 (↑5) reviews out of 8,480 for the lifetime. The most common issues on the Google Play store reviews remain the same: * “Tor Browser doesn’t work”: - often from Russian users, who are struggling to find a way to connect to Tor. I offer users to contact us via support channels, so I often see them improving our app's rating. * “Tor speed is too slow”: This issue is currently under investigation. I offer users to change the tor circuit, and if it doesn't help - to contact us. [1] https://gitlab.torproject.org/tpo/community/l10n/-/issues/40152 [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40794 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43482 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43468 [5] https://forum.torproject.org/t/tor-browser-wont-launch-anymore-on-mac-help/

1 0