- tor-project - lists.torproject.org

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

intrigeri's report, February 2025
by intrigeri 03 Mar '25

03 Mar '25

Hi, User-visible ============ - I've prepared the Tails 6.12 release. - I've reviewed and supported the work of my team-mates on a number of high priority user-visible improvements. User-invisible ============== Apart of the usual amount of KTLO work: - I have upgraded AppArmor to 4.1 in Debian in time for the freeze of Trixie. - We've met with a number of stakeholders to figure out the strategy for Tails comms this year, and how we're going to transition the existing Tails comms tools & processes now that we're part of Tor. - I've met with Freedom of the Press Foundation staff in order to support their efforts to add Dangerzone to Debian, in a way that will make it easier to use this tool in Tails. - The Tails Team had a post-mortem of our last security audit and identified a few low-hanging fruits that we can pick in order to avoid introducing similar vulnerabilities again in the future. Team lead ========= - We've finalized our priorities for 2025: https://gitlab.tails.boum.org/tails/team/-/wikis/home#priorities - I have uplifted a few ideas from my team to the operations team. Accounting & Fundraising ======================== - I have helped with the process of closing Tails' donation infrastructure and merging it into Tor's. Cheers, -- intrigeri

1 0

PieroV's Monthly Status Report, February 2025
by Pier Angelo Vendrame 03 Mar '25

03 Mar '25

Hi everyone, Here is my status report for February 2025. At the beginning of the month, I worked on releasing 14.0.5 and 13.5.12. I prepared them, and after we built them, I also signed them. I also took some time to repurpose an old computer for this task to run it in an environment completely isolated from my usual developer machine. However, Tor Browser 14.0.5 had a problem [tor-browser#43468] and crashed on older macOS versions because of an upstream WebRTC update. For some reason, Firefox and Mullvad Browser were not affected. So, I investigated to find the cause of the problem and created a patch, both for us and for Firefox [Bug 1946501]. After that, I went back to work on uplifts. The first was Bug 1923260 [Bug 1923260], a patch initially sent to us by a contributor. Upstream asked for some changes, but I had to verify them, and it has been a while since I made some C++ changes to Firefox specific to Android that needed to be debugged first. While waiting for the letterboxing improvements to land, I started checking a problem with the initial size of Firefox windows when system scaling is enabled [tor-browser#43205]. Eventually, it was a platform-specific problem 😭. On Windows, some intermediate rounding (spread across several functions) leads to a wrong final window size being passed to the OS API [Bug 1947439]. On Linux, some window sizes are never applied, even when set with external tools such as xdotool. I think the problem is somewhere in the X.org server rather than being a response from Firefox. So, I decided to write a workaround at a higher level since fixing the actual causes would have been much longer and complicated. Also about screen size, I started a patch [tor-browser!1388] to change how we spoof the sizes of the outer window and of the screen. Currently, we lie about them being the same as the inner window. However, this stands out compared to usual values and sometimes leads to the misdetection of our users as bots. My current patch still needs some changes, so it hasn't been merged, yet. After that, I resumed integration of the Lox crates on Tor Browser. Our initial approach was to use a WASM blob, but we decided to integrate the actual crates for several reasons [tor-browser#43096]. Finally, I resumed the RR rebase effort [tor-browser#43512]: I rebased from Firefox 130 to 131 and from 131 to 132, and I also reviewed Bea's rebase from 129 to 130. Best, Pier [Bug 1923260] https://bugzilla.mozilla.org/show_bug.cgi?id=1923260 [tor-browser#43468] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43468 [Bug 1946501] https://bugzilla.mozilla.org/show_bug.cgi?id=1946501 [tor-browser#43205] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43205 [Bug 1947439] https://bugzilla.mozilla.org/show_bug.cgi?id=1947439 [tor-browser#43096] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096 [tor-browser!1388] https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests… [tor-browser#43512] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43512

1 0

Anti-censorship team meeting notes, 2025-02-27
by Shelikhoo 02 Mar '25

02 Mar '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-02-27-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday,March 06 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 == * rdsys 1.0 release * https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ == Discussion == for Feb 27: * Next Step for Datagram mode transport mode for Snowflake * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * The broker can now reject older proxies based on the version number * The new server, broker, and proxy is designed to work with both new and old client * We still need to add the support for new protocol to webextension version of the proxy * Should we add both version of protocol to the client? or should we just merge the proxy, broker, and server code now, and wait long enough before merging the client? * The plan is to merge and deploy support for the new protocol in proxies first, monitor the status of proxy upgrades, and then later release client support. * Metrics to track proxy version updates: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/95 * The broker in the MR has the ability to reject all proxies that do not have updated protocol support, which is one way of ensuring compatibility between the protocol support of clients and proxies. (It avoids a situation where a client expects to be able to support the new datagram mode, and gets assigned a proxy that does not support that mode.) * The broker could, notionally, be more sophisticated, and take protocol support into account when matching clients with proxies. That would also be a way of ensuring backward compatibility. The broker doing that kind of matching was deliberately left out of the early draft of the MR (which focused only on the mechanics of implementing the datagram mode), but could be considered now. * Options before us: * 1. Merge and deploy to production the already implemented standalone proxy, broker, and bridge changes. (And implement support in WebExtension proxies in the meanwhile.) * 2. Deploy a testing broker, in order to test the new protocol without affecting the current proxy pool. * This could be with a testing proxy pool or without, or first one then the other. * 3. Other plans, such as client and proxy version matching. * shelikhoo will create a testing broker deployment with a small number of proxies for testing. The broker will work with both old and new clients, but the broker, bridge, and proxies must be updated. * Prepare an MR with just the broker, bridge, and proxy changes. Regardless of how we handle backward compatibility, that will be the first step. * Gitlab Dependency Proxy and our merge request pipeline * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * The pipeline will stop working when we are developing from our "personal" fork of it * meskio will check with TPA and see if there's a known solution that works for personal forks. for March 6: * 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." == Actions == == Interesting links == * TURN/STUN server networks from https://www.petsymposium.org/foci/2025/foci-2025-0003.php "Using TURN Servers for Censorship Evasion" * https://developers.cloudflare.com/calls/turn/ * https://www.metered.ca/tools/openrelay/ * https://www.expressturn.com/ * https://xirsys.com/ * https://arxiv.org/abs/2409.06247 "Differential Degradation Vulnerabilities in Censorship Circumvention Systems" Several recently proposed censorship circumvention systems use encrypted network channels of popular applications to hide their communications. For example, a Tor pluggable transport called Snowflake uses the WebRTC data channel, while a system called Protozoa substitutes content in a WebRTC video-call application. By using the same channel as the cover application and (in the case of Protozoa) matching its observable traffic characteristics, these systems aim to resist powerful network-based censors capable of large-scale traffic analysis. Protozoa, in particular, achieves a strong indistinguishability property known as behavioral independence. We demonstrate that this class of systems is generically vulnerable to a new type of active attacks we call "differential degradation." These attacks do not require multi-flow measurements or traffic classification and are thus available to all real-world censors. They exploit the discrepancies between the respective network requirements of the circumvention system and its cover application. We show how a censor can use the minimal application-level information exposed by WebRTC to create network conditions that cause the circumvention system to suffer a much bigger degradation in performance than the cover application. Even when the attack causes no observable differences in network traffic and behavioral independence still holds, the censor can block circumvention at a low cost, without resorting to traffic analysis, and with minimal collateral damage to non-circumvention users. * Wallbleed: A Memory Disclosure Vulnerability in the Great Firewall of China * https://gfw.report/publications/ndss25/en/ == Reading group == * We will discuss "Identifying VPN Servers through Graph-Represented Behaviors" on February 27 * https://dl.acm.org/doi/10.1145/3589334.3645552 * https://dl.acm.org/doi/pdf/10.1145/3589334.3645552 * https://github.com/chenxuStep/VPNChecker * https://openreview.net/pdf?id=7024czziih public peer reviews * https://github.com/net4people/bbs/issues/455 dcf's summary * 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-02-27 Last week: - found an issue with the broker's rate limiting (?) causing 504 errors (snowflake#40451) - debugged and wrote a fix for SQS queue problems (snowflake#40363) - wrote a fix for config options clobbering each other (snowflake#40483) - fixed the SQS unit tests (snowflake#40453) - supported conjure work - reviewed snowflake!315 This week: - support conjure work - follow up on 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-02-27 Last week: - reviewed snowflake webextension snowflake-allow local storage patch https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented on snowflake broker rate limiting and 504 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - worked out payment for January 2025 Greenhost invoice https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - asked about snowflake broker rate limiting, source IP address and X-Forwarded-For https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… wrote a summary of this week's reading group paper https://github.com/net4people/bbs/issues/455 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… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2024-02-27 Last week: - basic rsdys containers (rdsys#219) - snowflake CI using gitlab container proxy (snowflake!522) - add settings distributor option to c-tor (tor!860) - write a blogpost on the rdsys 1.0 release https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ - put bridgedb-metrics on logrotate (rdsys-admin!38) - keep old bridgedb-metrics logs (rdsys!489) Next week: - steps towards a rdsys in containers (rdsys#219) Shelikhoo: 2024-02-27 Last Week: - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - [Done] Add support for using a proxy to connect to the PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/… - [Done] Add Document for Bridge Line formats ( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt… ) - Merge request reviews Next Week/TODO: - Merge request reviews - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements onyinyang: 2025-02-27 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… - FOCI - Finished work on implementing issuer efficiency for check-blockage and trust-promotion protocols - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/284 Next week: - finish up ampcache registration method (sqs on hold for now) - Begin work on either obfs4 transport or decoy registration option - 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-02-26 (AFK 27 feb) Last weeks: - Implementing key_share extension support in covert-dtls - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - 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

sajolida's report, September 2024
by sajolida 27 Feb '25

27 Feb '25

Hi, September was again more busy than average to respect the timeline of Project 101 (Tor VPN) and Tails releases. Tor VPN ======= - I analyzed the usability test of Tor VPN 0.6.2 that I did in August. https://gitlab.torproject.org/tpo/ux/research/-/issues/69 In short, the usability of Tor VPN 0.6.2 is decent when people don't need to use a bridge, but very bad when Tor is blocked. None of the participant managed to use a bridge on their own. The main issues are unclear system status and confusing network model. Quotes: “Tor is like a bridge.“ — P5 “I'm looking for bridges that make it like if I were in Switzerland.“ — P4 “It should say: You are being blocked! With Tor you can bypass this censorship using a bridge.“ — P6 Summary of findings: https://gitlab.torproject.org/-/project/92/uploads/1fba8220a110622d852bf448… List of all issues: https://nc.torproject.net/s/fXbRYw76pTXJZym Video clips: https://nc.torproject.net/f/645757 - I created GitLab issues to document the most severe issues: Improve feedback while "Connecting" https://gitlab.torproject.org/tpo/applications/vpn/-/issues/181 Clarify connection status on all screens https://gitlab.torproject.org/tpo/applications/vpn/-/issues/182 Allow changing exit location from Configure menu https://gitlab.torproject.org/tpo/applications/vpn/-/issues/185 Improve discoverability of the list of countries https://gitlab.torproject.org/tpo/applications/vpn/-/issues/186 Clarify what can be tapped in the Bridges screen https://gitlab.torproject.org/tpo/applications/vpn/-/issues/187 Remove the need to press Enter when entering a bridge line https://gitlab.torproject.org/tpo/applications/vpn/-/issues/188 Clarify which bridge is being used (eg. after Bridge Bot) https://gitlab.torproject.org/tpo/applications/vpn/-/issues/189 Improve discoverability of the circuit view https://gitlab.torproject.org/tpo/applications/vpn/-/issues/190 Allow configuring only a single bridge https://gitlab.torproject.org/tpo/applications/vpn/-/issues/193 Rethink how the different relays are named https://gitlab.torproject.org/tpo/applications/vpn/-/issues/194 Clarify just enough about the network model https://gitlab.torproject.org/tpo/applications/vpn/-/issues/195 Don't allow changing exit location unless already connected https://gitlab.torproject.org/tpo/applications/vpn/-/issues/196 Report loss of connectivity to the Tor network https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/110 - I started brainstorming solutions to all of these issues with Duncan and the rest of the UX team. Tails ===== I wrote some documentation to help users with recent issues: - Shim SBAT verification error (#20471) https://tails.net/news/version_6.7/#sbat - Provide fsck from Welcome Screen when the file system of the Persistent Storage is corrupted (#15451) https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1586 This one was a LOT of work to figure out which data forensics path we should recommend to users and document the main ones step-by-step. -- sajolida

1 5

cve's monthly status report
by Clara Engler 27 Feb '25

27 Feb '25

# Introduction Dear tor-project@, my work in February 2025 has been centered around two small but powerful tools that I have authored during this time period. # oniux In the beginning of the month, I started the *oniux* project[1], which utilizes `namespaces(7)` and onionmasq in order to securely isolate an arbitrary application through Tor. It basically serves as a replacement for torsocks but in a way that is less hacky and sounds more correct. My work centered around studying the inner workings of Linux namespaces and capabilities, writing an initial prototype and finally the real implementation. I have also given a German-language presentation about this at my local hackspace and can give you the slides on request. Please read the projects README for further information about this, including the inner workings on which I have spent a huge effort to document those. # TorVault During the other half the month, I started the *TorVault* project[2], which makes it possible to use the `OfflineMasterKey` feature for relays in combination with a Yubikey. It provides a guide on how to generate and import a long-term Ed25519 identity key onto a Yubikey (recommended) or on how to generate a long-term Ed25519 identity key on the Yubikey itself. The program itself then provides an interactive dialogue that prompts the user for the relevant information (device name, expiration date, paths, ...). In the end, the program generates and exports the relevant keys and certificate(s) which are then ready to be deployed into the relays `keys/` folder. I have announced the project onto the tor-relays@ mailing list and I am already using it in production for my own relay. Right now, I have plans to port this tool into Rust in order to eventually integrate it into Arti. Unfortunately, the Rust ecosystem is – at the moment – not far enough to support this, because Curve25519 support in Yubikeys is a rather new feature not supported by the most popular Rust Yubikey crate. This is also an area I am working on at the moment. Thank You, Clara --- [1]: https://gitlab.torproject.org/cve/oniux [2]: https://gitlab.torproject.org/tpo/core/TorVault

1 0

Rhatto's Monthly Status Report, February 2025
by rhatto 25 Feb '25

25 Feb '25

Hi all :) This is my monthly status report for February 2025 with the main relevant activities I have done, was involved or are related to my work during the period. Sending this early on as I'll be AFK in the next days/week. For other Onion Services news, check this post: https://forum.torproject.org/t/some-news-from-the-onion-space-february-2025… ## Ansible This month was focused in fixing and improving CI for the Ansible codebase, which resulted in three new small projects: * AnCIble - opinionated CI templates for Ansible roles and playbooks: https://gitlab.torproject.org/tpo/onion-services/ansible/ancible * Example role: https://gitlab.torproject.org/tpo/onion-services/ansible/example-role * Example playbook: https://gitlab.torproject.org/tpo/onion-services/ansible/example-playbook ## Other * Improved Onionprobe installation docs: * Page: https://onionservices.torproject.org/apps/web/onionprobe/installation/ * Ticket: https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/101 * Improved the Onion Services research references: * Page: https://onionservices.torproject.org/research/references/ * Ticket: https://gitlab.torproject.org/tpo/onion-services/onionplan/-/issues/33 * Ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. -- Silvio Rhatto pronouns he/him

1 0

UX Team meeting moved to Monday 24th
by Duncan R. 13 Feb '25

13 Feb '25

Hello friends, As Monday 17th is a US holiday, and I’ll be AFK on Tuesday, the UX Team meeting has been postponed until the following Monday instead. Thanks, D

1 0

Anti-censorship team meeting notes, 2025-02-13
by onyinyang 13 Feb '25

13 Feb '25

1 Hey everyone! 1 2 Here are our meeting logs: 3 http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-02-13-16.00.html 4 5 And our meeting pad: 6 7 Anti-censorship work meeting pad 8 -------------------------------- 9 Anti-censorship 10 -------------------------------- 11 12 Next meeting: Thursday,Feb 27 16:00 UTC 13 Facilitator: shelikhoo 14 ^^^(See Facilitator Queue at tail) 15 16 Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC 17 (channel is logged while meetings are in progress) 18 19 This week's Facilitator: onyinyang 20 21 == Goal of this meeting == 22 23 Weekly check-in about the status of anti-censorship work at Tor. 24 Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. 25 26 27 == Links to Useful documents == 28 * Our anti-censorship roadmap: 29 * Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards 30 * The anti-censorship team's wiki page: 31 * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home 32 * Past meeting notes can be found at: 33 * https://lists.torproject.org/pipermail/tor-project/ 34 * Tickets that need reviews: from projects, we are working on: 35 * All needs review tickets: 36 * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… 37 * Project 158 <-- meskio working on it 38 * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… 39 40 41 == Announcements == 42 43 * No meeting February 20th. There is FOCI at the same time 44 * https://foci.community/ 45 * snowflake-graphs proxy CSV files (client-match.csv, proxy-country.csv, proxy-nat-type.csv, proxy-type.csv) are available again. (Working around a bad descriptor that had prevented updates since 2024-08.) 46 * https://gitlab.torproject.org/dcf/snowflake-graphs/-/commit/089e0af01aa6383… 47 48 == Discussion == 49 50 * moderation of mailing lists to prevent spam 51 * https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… 52 * we agree to moderate new subscribers and remove the moderation flag on first post if is not spam 53 * Whether to switch to debian fork of golang for CI 54 * https://gitlab.torproject.org/tpo/tpa/team/-/issues/42014#note_3159983 55 * The problem is sporadic CI failures due to container rate limits. 56 * The rate limit problem has been fixed, for the anti-censorship team at least, by maintaining our own mirror of container images: 57 https://gitlab.torproject.org/tpo/anti-censorship/duplicatedcontainerimages/ 58 * tpo/tpa/team#42014 is a request to have the admin team take on the responsibility of mirroring those container images. 59 * The admin team prefers that we use their existing Debian images that contain golang, rather than take on a new set of container mirrors. 60 * shelikhoo has a distaste for Debian-based images, stemming from past experience with excessive patching and slow updates. shelikhoo prefers either to build our own golang from source (possibly on a Debian-based image), or else use a binary release of golang. 61 * Debian patches to golang: https://sources.debian.org/patches/golang-1.19/1.19.13-1~bpo11%2B1/ 62 * So the trilemma is: 1. extra maintenance for the anti-censorship team (duplicatedcontainerimages), 2. extra maintenance for the admin team, or 3. using the admin team–maintained images which shelikhoo does not want to use. 63 * The resolution is #1: keep using our own mirror at our own maintenance expense. 64 * TPA provides golang containers based on oldstable, stable, testing and sid versions of golang 65 * golang version in debian might be different than the official one 66 * we'll keep using our mirrors of containers 67 * Would we like to support WASM version of proxy? 68 * https://gitlab.torproject.org/WofWca/snowflake/-/compare/main...wasm?from_p… 69 * we could replace the javascript logic of the webextension with the WASM version of the standalone proxy. Removing the need to duplicate functionallity in two languages 70 * When compiled to WASM, Pion acts as a wrapper around the browser's own WebRTC API (i.e. Pion doesn't craft its own DTLS records etc.). So it may be possible to keep browser protocol fingerprints the way they are already. 71 * https://github.com/pion/webrtc/blob/v4.0.9/examples/README.md#webassembly "Pion WebRTC can be used when compiled to WebAssembly, also known as WASM. In this case the library will act as a wrapper around the JavaScript WebRTC API." 72 73 for Feb 27: 74 * 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… 75 * "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." 76 77 == Actions == 78 79 == Interesting links == 80 81 * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… 82 * https://opencollective.com/censorship-circumvention/projects/snowflake-dail… 83 * €3,917.57 snowflake-01 bandwidth expenses in 2024 84 85 == Reading group == 86 87 * We will discuss "Identifying VPN Servers through Graph-Represented Behaviors" on February 27 88 * https://dl.acm.org/doi/10.1145/3589334.3645552 89 * https://dl.acm.org/doi/pdf/10.1145/3589334.3645552 90 * https://github.com/chenxuStep/VPNChecker 91 * Questions to ask and goals to have: 92 * What aspects of the paper are questionable? 93 * Are there immediate actions we can take based on this work? 94 * Are there long-term actions we can take based on this work? 95 * Is there future work that we want to call out in hopes that others will pick it up? 96 97 == Updates == 98 Name: 99 This week: 100 - What you worked on this week. 101 Next week: 102 - What you are planning to work on next week. 103 Help with: 104 - Something you need help with. 105 106 cecylia (cohosh): 2025-02-13 107 Last week: 108 - supported conjure work 109 - reviewed snowflake!315 110 - helped debug and and give feedback on snowflake website 111 - updated our jasmine tests for snowflake-webext CI (snowflake-webext#112) 112 - responded to emails on SQS rendezvous 113 - commented on onionperf + python3.13 issue (onionperf#40051) 114 - finally closed out the meek bridge handover issue (team#133) 115 - updated team#142 with recent proxy count graphs and closed it 116 - other random reviews and todos 117 This week: 118 - support conjure work 119 - debug SQS rendezvous 400 errors 120 - take a look at potential snowflake orbot bug 121 - https://github.com/guardianproject/orbot-android/issues/1183 122 - maybe do some lox work 123 124 dcf: 2025-02-13 125 Last week: 126 - snowflake azure CDN bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… 127 - decommissioned the snowflake-broker.azureedge.net CDN profile https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 128 - decommissioned the old snowflake broker VPS instance https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 129 - verified documentation fix for snowflake-broker journalctl command https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 130 Next week: 131 - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 132 - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 133 - open issue to disable /debug endpoint on snowflake broker 134 Help with: 135 136 meskio: 2024-02-13 137 Last week: 138 - long discussions around rdsys in containers (rdsys#219) 139 - debug why webtunnel in lyrebird is not accepting https proxy (lyrebird#40024) 140 - fix moat so it will distribute webtunnel bridges in russia (rdsys#256) 141 - bring backward compatibility on the moat captcha API (rdsys!480) 142 Next week: 143 - steps towards a rdsys in containers (rdsys#219) 144 145 Shelikhoo: 2024-02-13 146 Last Week: 147 - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements 148 - [Invesgate]Add support for using a proxy to connect to the PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/… 149 - Merge request reviews 150 Next Week/TODO: 151 - Merge request reviews 152 - [Refine] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements 153 - [Deploy] Remove domain snowflake-broker.bamsoftware.com from snowflake broker's ACME tool 154 - [Fix] Add support for using a proxy to connect to the PTs(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/… 155 156 onyinyang: 2025-02-13 157 Last week(s): 158 - continued work on ampcache registration method for conjure 159 - WIP MR: https://github.com/cohosh/conjure/pull/1 160 Next week: 161 - finish up ampcache registration method (sqs on hold for now) 162 - Begin work on either obfs4 transport or decoy registration option 163 - FOCI 164 - add TTL cache to lox MR for duplicate responses: 165 https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305 166 As time allows: 167 - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols 168 - Work on outstanding milestone issues: 169 - key rotation automation 170 171 Later: 172 pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) 173 - add pref to handle timing for pubkey checks in Tor browser 174 - add trusted invitation logic to tor browser integration: 175 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 176 - improve metrics collection/think about how to show Lox is working/valuable 177 - sketch out Lox blog post/usage notes for forum 178 179 (long term things were discussed at the meeting!): 180 - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice 181 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? 182 1. Are there some obvious grouping strategies that we can already consider? 183 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?) 184 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? 185 186 theodorsm: 2025-02-13 187 Last weeks: 188 - Debugging Tor Build with covert-dtls: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 189 Next weeks: 190 - Update covert-dtls to handle new DTLS extensions in recent browsers 191 - Write instructions on how to configure covert-dtls with snowflake client 192 - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) 193 - Condensing thesis into paper (on hold) 194 Help with: 195 - Test stability of covert-dtls in snowflake 196 197 198 199 Facilitator Queue: 200 onyinyang shelikhoo meskio 201 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 202 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