- tor-project - lists.torproject.org

Applications Team IRC meeting cancelled until June 9th
by Morgan 19 May '25

19 May '25

Hi everyone, The apps team has a series of conflicts over the next few weeks, so the next regularly scheduled irc meeting will be on Monday June 19th at 1600 UTC as usual. best, -morgan

1 0

Anti-censorship team meeting notes, 2025-05-15
by Shelikhoo 15 May '25

15 May '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-05-15-15.59.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, May 22 16:00 UTC Facilitator: onyinyang ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: shelikhoo == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == Links to Useful documents == * Our anti-censorship roadmap: * Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards * The anti-censorship team's wiki page: * https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home * Past meeting notes can be found at: * https://lists.torproject.org/pipermail/tor-project/ * Tickets that need reviews: from projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * == Discussion == * Testing plans for unreliable transport mode for snowflake * Requires a complex testing setup that asks for some study * k3s or kubernetes based * The testing setup is meant to be reusable beyond testing for the unreliable transport mode * It is not needed to understand the stanging environment just to deploy new branches * Use for automated deployment? It's not set up for that now, but could be. == 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-05-15 Last week: - submitted conjure station MR to get CDN77 domain fronting working - https://github.com/refraction-networking/conjure/pull/291 - did some pair debugging - read up on the snowflake staging environment - https://gitlab.torproject.org/shelikhoo/snowflakestaging/-/issues/1 - started testing unreliable transport mode for snowflake - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - resumed work on snowflake metrics improvements - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… This week: - support conjure work - finish testing and give feedback on unreliable transport mode for snowflake - 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 dcf: 2025-05-15 Last week: - opened issue for missing documentation for client-snowflake-timeout-count in snowflake broker-spec.txt https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - commented more on @luiz proposal for an updated FEP pluggable transport https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… 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-05-15 Last week: - learn about podman quadlets and try to make them work for rdsys (rdsys#219) - investigate (and fail to find) why some users in russia can't reach moat/circumvention settings (rdsys#264) Next week: - steps towards a rdsys in containers (rdsys#219) - investigate why we don't distribute webtunnel bridges over https some days (rdsys#262) Shelikhoo: 2024-05-15 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 - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) - 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 - Support the Testing of domain fronting sites ( https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/… ) (cont.) - Snowfalke Staging Server Experiment(Almost Done ^~^) onyinyang: 2025-05-15 Last week(s): - Attempted to get gotapdance decoy routing working - decoy routing may be a less viable solution than we expected, waiting for more info from UC Boulder folks - Working on more straightforward improvements to bufferedconn for the time being Next week: - Continue on bufferedconn improvements and other conjure reliability improvments for Objective 2: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… 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-04-10 Last weeks: - fixing bugs in covert-dtls, only mimic DTLS 1.2 - Running proxy with covert-dtls - MR 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 (are we going to run a user test?) - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper Help with: - Test stability of covert-dtls in snowflake Facilitator Queue: onyinyang meskio shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0

Are there countries where using Tor is illegal?
by Cristian Consonni 11 May '25

11 May '25

Hi, (Sorry if this question has already been asked in the past, feel free to point me to the relevant resources.) I know that the legal FAQs by the EFF state that: «we believe that running a Tor relay — including an exit relay that allows people to anonymously send and receive traffic — is legal under U.S. law.»[1] I also know there is a list of countries for which there is legislation that exclude communication service providers from liability. They are indicated in the Legal of the Tor Exit Guidelines page[2], they are USA, Germany, Netherlands, Austria, France, and Sweden. >From some articles in the press[3a][3b] it may be illegal - depending on how you interpret the wording[*] - to use Tor (and other technologies such as VPNs or proxies) in the UAE, with fines ranging in the millions of dirhams (hundreds of thousand of dollars). A couple of weeks ago it was discussed - on this list as well - that a law was introduced to the state parliament to ban Tor[4a][4b]. This follows a case of some months ago of a Russian Tor exit node operator being arrested for inciting mass riots and terrorism[4c][4d]. The idea of blocking VPNs or Tor seems to have already been considered in the past[4e]. This infographic about pluggable transports[5] suggests access to the Tor network is censored or limited in China, Uzbekistan, Iran, and Kazakhstan. Tor being censored orblocked may be different from it being illegal. What about other countries? Is there a place where I can find more about this topic? Cristian [1]: https://www.torproject.org/eff/tor-legal-faq.html.en [2]: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines [3a]: http://www.emirates247.com/news/emirates/dh500-000-fine-if-you-use-fraud-ip… [3b]: http://news.softpedia.com/news/people-caught-using-vpns-tor-or-proxies-in-t… [*]: «Whoever uses a fraudulent computer network protocol address (IP address) by using a false address or a third-party address by any other means for the purpose of committing a crime or preventing its discovery» [4a]: https://lists.torproject.org/pipermail/tor-talk/2017-June/043293.html [4b]: https://trac.torproject.org/projects/tor/ticket/22055 [4c]: https://lists.torproject.org/pipermail/tor-talk/2017-April/043109.html [4d]: https://techcrunch.com/2017/04/24/dmitry-bogatov-tor-russia/ [4e]; https://torrentfreak.com/vpn-and-tor-ban-looming-on-the-horizon-for-russia-… [5]: https://www.torproject.org/images/PT/2016-07-how-to-use-PT.png

4 3

TPA-RFC-87: container image lifecycle
by Antoine Beaupré 08 May '25

08 May '25

--- affected users: container registry users deadline: 2025-05-08 (3 weeks) status: proposed discussion: https://gitlab.torproject.org/tpo/tpa/base-images/-/issues/24 --- Summary: TPA container images will follow upstream OS support schedules Table of contents: - Proposal - Debian images - Ubuntu images - Alternatives considered - Different schedules according to image type - Upgrades in lockstep with our major upgrades - Upgrade completes before EOL - Upgrade completes after EOL - References # Proposal Container image versions published by TPA as part of the `base-images` repository will be supported following upstream (Debian and Ubuntu) support policies, including "LTS" releases. In other words, we will *not* retire the images in lockstep with the normal "major release" upgrade policy, which typically starts the upgrade during the freeze and aims to retire the previous release within a year. This is to give our users a fallback if they have trouble with the major upgrades, and to simplify our upgrade policy. This implies supporting 4 or 5 Debian build per image, per architecture, depending on how long upstream live, including testing and unstable. We can make exceptions in case our major upgrades take an extremely long time (say, past the LTS EOL date), but we *strongly* encourage all container image users to regularly follow the latest "stable" release (if not "testing") to keep their things up to date, regardless of TPA's major upgrades schedules. Before image retirements, we'll send an announcement, typically about a year in advance (when the new stable is released, which is typically a year before the previous LTS drops out of support) and a month before the actual retirement. ## Debian images Those are the Debian images currently supported and their scheduled retirement date. | codename | version | end of support | |------------|---------|----------------| | `bullseye` | 11 | 2026-08-31 | | `bookworm` | 12 | 2028-06-30 | | `trixie` | 13 | likely 2030 | | `sid` | N/A | N/A | Note that `bullseye` was actually retired already, before this proposal was adopted ([tpo/tpa/base-images#19][]). [tpo/tpa/base-images#19]: https://gitlab.torproject.org/tpo/tpa/base-images/-/issues/19 ## Ubuntu images Ubuntu releases are tracked separately, as we do not actually perform Ubuntu major upgrades. So we currently have those images: | codename | version | end of support | |------------|-----------|----------------| | `focal` | 20.04 LTS | 2025-05-29 | | `jammy` | 22.04 LTS | 2027-06-01 | | `noble` | 24.04 LTS | 2029-05-31 | | `oracular` | 24.10 | 2025-07 | Concretely, it means we're supporting a relatively constant number (4) of upstream releases. Note that we do not currently build other images on top of Ubuntu images, and would discourage such an approach, as Ubuntu is typically not supported by TPA, except to build third-party software (in this case, "C" Tor). # Alternatives considered Those approaches were discussed but ultimately discarded. ## Different schedules according to image type We've also considered having different schedules for different image types, for example having only "stable" for some less common images. This, however, would be confusing for users: they would need to *guess* what exactly we consider to be a "common" image. This implies we build more images than we might truly need (e.g. who really needs the `redis-server` image from `testing` *and* `unstable`?) but this seems like a small cost to pay for the tradeoff. We currently do not feel the number of built images is a problem in our pipelines. ## Upgrades in lockstep with our major upgrades We've also considered retiring container images in lockstep with the major OS upgrades as performed by TPA. For Debian, this would have *not* include LTS releases, unless our upgrades are delayed. For Ubuntu, it includes LTS releases and supported rolling releases. For Debian, it meant we generally supported 3 releases (including testing and unstable), except during the upgrade, when we support 4 versions of the container images for however long it takes to complete the upgrade after the stable release. This was confusing, as the lifetime of an image depended upon the speed at which major upgrades were performed. Those are highly variable, as they depend on the team's workload and the difficulties encountered (or not) during the procedure. It could mean that support for a container image would abruptly be dropped if the major upgrade crossed the LTS boundary, although this is also a problem with the current proposal, alleviated by pre-retirement announcements. ### Upgrade completes before EOL In this case, we complete the Debian 13 upgrade before the EOL: - 2025-04-01: Debian 13 upgrade starts, 12 and 13 images supported - 2025-06-10: Debian 13 released, Debian 14 becomes `testing`, 12, 13 and 14 images supported - 2026-02-15: Debian 13 upgrade completes - 2026-06-10: Debian 12 becomes LTS, 12 support dropped, 13 and 14 supported In this case, "oldstable" images (Debian 12) images are supported 4 months after the major upgrade completion, and 14 months after the upgrades start. ### Upgrade completes after EOL In this case, we complete the Debian 13 upgrade after the EOL: - 2025-04-01: Debian 13 upgrade starts, 12 and 13 images supported - 2025-06-10: Debian 13 released, Debian 14 becomes `testing`, 12, 13 and 14 images supported - 2026-06-10: Debian 12 becomes LTS, 12, 13 and 14 supported - 2027-02-15: Debian 13 upgrade completes, Debian 12 images support dropped, 13 and 14 supported - 2028-06-30: Debian 12 LTS support dropped upstream In this case, "oldstable" (Debian 12) images are supported zero months after the major upgrades completes, and 22 months after the upgrade started. # References - [discussion issue][] - [Debian release support schedule][] - [Ubuntu][] and [Debian][] release timelines at Wikipedia - [Debian major upgrades progress and history][] [discussion issue]: https://gitlab.torproject.org/tpo/tpa/base-images/-/issues/24 [Debian major upgrades progress and history]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades#all-time-… [Debian]: https://en.wikipedia.org/wiki/Debian_version_history#Release_table [Ubuntu]: https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions [Debian release support schedule]: https://www.debian.org/releases/ -- Antoine Beaupré torproject.org system administration

1 1

Anti-censorship team meeting notes, 2025-05-08
by meskio 08 May '25

08 May '25

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-05-08-16.00.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday, May 15 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: 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 == * About SnowflakeStaging(https://gitlab.torproject.org/shelikhoo/snowflakestaging) * Please have a trial of the Snowflake Packet Transport Mode! * Relicense as MIT BSD 3Clause * Anything we wants to modify? * Anything we wants to add? * We will discuss this again this week to get feedback since other snowflake developers were away last week * cohosh will review it and provide feedback * Find a long term solution for utls downgrade check * https://metrics.torproject.org/userstats-bridge-combined.html?start=2025-02… * that was an emergency patch to backport the uTLS security update * https://gitlab.torproject.org/shelikhoo/utls-temporary * https://gitlab.torproject.org/shelikhoo/utls-temporary/-/commit/55c892a09c8… * we can't update uTLS because we need to keep supporting go 1.21 until Firefox ESR 140 (September) * we'll maintain our fork until that date * RFC: Collect Snowflake Proxy Pool Health Information (https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/…) * will try to do the analisys with the current tools and explore more if the change on the loging system is needed * deprecate obfs4-bridge docker image for arm and 386 * https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/iss… == Actions == == Interesting links == * Big uptick in (especially) snowflake users from Turkmenistan since 2025-04-28 * https://metrics.torproject.org/userstats-bridge-combined.html?start=2025-02… * https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… == 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-05-08 Last week: - pair debugging phantombox with onyinyang - pair debugging conjure test network setup with ln5 - conjure#52 - presented project 173 work at all hands - worked on fix for CDN77 domain fronting with conjure - conjure#49 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 dcf: 2025-05-08 Last week: - commented on @luiz proposal for an updated FEP pluggable transport https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… 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-05-08 Last week: - containarize a test bridge authority (rdsys#219) - investigate why we don't distribute webtunnel bridges over https some days (rdsys#262) - fix obfs4-bridge docker parser to allow params with = (docker-obfs4-bridge#23) - evaluate the deprecation of arm and 386 on obfs4-bridge docker image (docker-obfs4-bridge#25) Next week: - steps towards a rdsys in containers (rdsys#219) - investigate why we don't distribute webtunnel bridges over https some days (rdsys#262) Shelikhoo: 2024-05-08 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 - Research Collect Snowflake Proxy Pool Health Information (https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/…) - Snowfalke Staging Server Experiment - Vantage point maintainence - 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 - Research about designing an armored bridge line sharing URL format https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126 - Vantage point maintainence - Snowfalke Staging Server Experiment(Almost Done ^~^) onyinyang: 2025-05-08 Last week(s): - Got phantombox working - Tried to make progress on decoy routing - Looked into turbotunnel implementation for conjure, seems like overkill for now - Working on more straightforward improvements to bufferedconn for the time being Next week: - Continue on bufferedcomm improvements and other conjure reliability improvments for Objective 2: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… 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-04-10 Last weeks: - fixing bugs in covert-dtls, only mimic DTLS 1.2 - Running proxy with covert-dtls - MR 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 (are we going to run a user test?) - Fix merge conflicts in MR (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…) - Condensing thesis into paper Help with: - Test stability of covert-dtls in snowflake Facilitator Queue: shelikhoo onyinyang 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

Haidi April'25 Monthly report
by haidis＠riseup.net 07 May '25

07 May '25

Hi! Below is my April’25 (Period: 2025-04-01 - 2025-04-30) report! In April, I resolved 92 tickets: * On Telegram (@TorProjectSupportBot) – 88 (from Iran); * On RT (frontdesk@tpo) – 4 (from Iran); * On WhatsApp (+447421000612) - 0; * And on Signal (+17787431312) - 0; I Worked on a forum document for ” Iran : Circumventing Censorship with Tor” to update according to the latest screenshots, translation, instruction and links. Working on some Farsi translations articles and text modules according to the latest Tor version. Thanks, Haidi

1 0

Nina’s Monthly Status Report, April 2025
by Nina 06 May '25

06 May '25

Hi! Below is my April’25 report! In April, I resolved 629 (↓47) tickets: * On Telegram (@TorProjectSupportBot) - 531 (↓40); * On RT (frontdesk@tpo) - 94 (↓8); * On WhatsApp (+447421000612) - 3 (0); * And on Signal (+17787431312) - 1 (↑1). My main focus remains the same: I help Russian-speaking users bypass censorship and troubleshoot any issues with Tor Browser. Idocumentedthe latest internet censorship developments in Russia[1] and how it's affecting Tor users, for example, Tails users connecting over Tele2, Beeline and other mobile providersin Russiaare having a very difficult time to connect to Tor as obfs4 is no longer working for them. Adding Webtunnel support in more Tor powered apps like Orbot and Tails would help Russian users to connect to Tor. In April'25 we had a major release 14.5 [2] - so I worked on updating templates in Russian to reflect the latest changes. I also took part in the translation of the Tor Browser User Survey into Russian[3]. We've received some feedback regarding the changes in how Tor Browser 14.5 handles OS spoofing in the HTTP User-Agent header. There was some misunderstanding, with concerns that certain fingerprinting protections might have been removed. I reassured users that Tor Browser still spoofs the operating system version and architecture, limiting this information to broad categories such as Windows, macOS, Linux, or Android. What’s new in version 14.5 is that this behavior is now consistent across both JavaScript and HTTP headers. *##**Google Play Reviews for Tor Browser**(TBA)**and Tor Browser Alpha**for Android* * Tor Browser for Android had a Google Play rating of *4.416*(↑0.01) stars in April, higher than in March’25. * Tor Browser for Android (TBA) got 625 (↓69) reviews out of 62,020 for the lifetime. * Tor Browser for Android Alpha (TBA-Alpha) app had a rating of 4.213 (↑0.005) starts in April, higher than in March’25. * In April, Tor Browser for Android (TBA-Alpha) got 45 (↓4) reviews out of 8,555 for the lifetime. In April the major complaints we got about Tor Browser for Android were related to Tor Browser speed (15). [1] https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… [2] https://blog.torproject.org/new-release-tor-browser-145/ [3] https://gitlab.torproject.org/tpo/community/l10n/-/issues/40152

1 0

Felicia's Monthly Status Report, April 2025
by Priscila 05 May '25

05 May '25

Hi everyone, This is my status report for April 2025. It's a list of all tasks I've been involved with/responsible for. ## Design tasks 1. Allow authentication of Onion Services on Android: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31672 2. Figure out how to display conflux circuits in Tor Browser’s UI: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41716 3. Update Connection Assist for Android designs: https://gitlab.torproject.org/tpo/ux/design/-/issues/136 4. Review error prompt shown when Tor exits: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43186 5. Review new download and support templates: https://gitlab.torproject.org/tpo/web/team/-/issues/59 ## UX support 1. Simplify which circuit we show in the Tor circuit panel: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43608#n… 2. Create a tor circuits hub: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43605#n… Best, Priscila (aka Felicia) - UX Team

1 0

ebanam's monthly user support and status report for April 2025
by ebanam 05 May '25

05 May '25

Hello everyone, With the first milestone release of Tor Browser (14.5)[0] in the year, I worked on a few related tasks, namely, updating the Tor Browser User Manual before the release[1], updating the Support Portal[2] and other relevant user support documentation on our support channels and the Tor Forum and user support work post-release. I made progress with writing documentation for the upcoming Tor VPN Android client[3]. Much of my user support related work last month, as is usual, was focused on helping users in regions where Tor is censored. That's it for the summary, following is a more detailed report about the tickets our user support team worked on last month. # Updates We fixed some issues with our Signal user support channel and it should be reachable again[4]. To reach our team on Signal, please contact +17787431312 or @torsupport.89 on Signal. # Frontdesk (email user support channel) * 679(↑) RT tickets created * 691(↑) RT tickets resolved Tickets by topics and numbers: 1. 383(↓) tickets: instructions to circumvent censorship for Chinese speaking users. 2. 102(-) tickets: circumventing censorship in Russian speaking countries. 3. 15(↓) tickets: help with troubleshooting existing Tor Browser install on Desktop (Windows, macOS and Linux). 4. 4(↑) tickets: reports of fake apps on iOS AppStore masquerading as official Tor Browser. 5. 4(↑) tickets: help with troubleshooting existing Tor Browser install on Android. 6. 3(-) tickets: reports of websites blocking Tor connections. 7. 3(↑) tickets: help with installing Tor Browser on Windows. 8. 2(↓) tickets: installing Tor Browser on Linux. 9. 2(↑) tickets: questions about onion services and how to access them. 10. 2(↑) tickets: question about setting up a Tor relay. 11. 2(↑) tickets: users seeing a "proxy refused" error when visiting websites on Tor Browser for Android using Samsung devices.[5] 12. 2(↑) tickets: reports of Tor bug (tor 0.4.8.16): https://gitlab.torproject.org/tpo/core/tor/-/issues/41040 13. 1(↓) ticket: Unable to login on X.com (formerly Twitter) when using Tor Browser.[6] 14. 1(↓) ticket: circumventing censorship with Tor in Farsi. 15. 1(-) ticket: Websites display in other languages when using Tor Browser. 16. 1(↑) ticket: question about operating system spoofing in Tor Browser. 17. 1(↑) ticket: question about the Tor Browser User Survey. 18. 1(↑) ticket: question about contributing and helping with with localization. 19. 1(↑) ticket: helping users on iOS, using Onion Browser or Orbot, to use censorship circumvention methods. 20. 1(↑) ticket: Bridges website hitting an error while fetching bridges with WebTunnel pluggable transport.[7] # Telegram, WhatsApp and Signal user support channels * 866(↑) tickets resolved Breakdown: * 827(↑) tickets on Telegram * 13(↓) tickets on WhatsApp * 26(↑) tickets on Signal Tickets by topics and numbers: 1. 509(↓) tickets: circumventing censorship in Russian speaking countries. 2. 102(↑) tickets: circumventing censorship with Tor in Farsi. 3. 55(↓) tickets: instructions to circumvent censorship for Chinese speaking users. 4. 14(↓) tickets: helping users on iOS, using Onion Browser or Orbot, to use censorship circumvention methods. 5. 13(↑) tickets: help with using Snowflake with Tor to circumvent censorship. 6. 11(↓) tickets: help with troubleshooting Tor Browser Desktop on Windows, macOS and Linux. 7. 11(↑) tickets: help with troubleshooting Tor Browser Android. 8. 7(↑) tickets: instructions on how to get Tor Browser binaries from GetTor. 9. 5(↓) tickets: help with instructions to use bridges with Tails. 10. 4(-) tickets: questions about onion services and how to access them. 11. 4(↑) tickets: Unable to login on X.com (formerly Twitter) when using Tor Browser. 12. 3(↑) tickets: Bookmarks are failing to load on Tor Browser for Android Alpha. (Issue is resolved.) 13. 2(↑) tickets: instructions to download Tor Browser 13.5 legacy for legacy operating systems. 14. 1(↓) ticket: users seeing a "proxy refused" error when visiting websites on Tor Browser for Android using Samsung devices. 15. 1(↑) ticket: question about operating system spoofing in Tor Browser. # Highlights from the Tor Forum 1. Tor user support now available in Farsi.[8] 2. Canvas fingerprinting protection in Tor Browser.[9] 3. Download protection in Tor Browser.[10] 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://blog.torproject.org/new-release-tor-browser-145/ [1]: https://gitlab.torproject.org/tpo/web/manual/-/issues/182 [2]: https://gitlab.torproject.org/tpo/web/support/-/issues/390 [3]: https://gitlab.torproject.org/tpo/web/support/-/issues/370 [4]: https://gitlab.torproject.org/tpo/community/support/-/issues/40188 [5]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42714 [6]: https://forum.torproject.org/t/x-com-formerly-twitter-issues-with-tor-brows… [7]: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/262 [8]: https://forum.torproject.org/t/tor-user-support-now-available-in-farsi/18520 [9]: https://forum.torproject.org/t/why-website-display-stripes/18281 [10]: https://forum.torproject.org/t/tor-browser-blocking-downloads/18316

1 0

cve's monthly status report -- April 2025
by Clara Engler 05 May '25

05 May '25

Hello tor-project@, the following contains a list of the work I have done for Tor in April 2025. # arti * Assisted gabi in the release of 1.4.2 * Removed a dead code reference in the RPC API * Added a gitignore for Python * Added a CI check for wildcard requirements in Cargo.toml files # onionmasq * Updated arti to 1.4.2 * Fixed rust-clippy CI container failure * Migrated all containers to a common image * Rewrote the integration test suite to a much cleaner implementation that is not using dirty hacks such as nested bash scripts # onionprobe * Began working on a rewrite of this tool in Rust * Rewrite is already capable of many features, with the exports to Prometheus and friends being the notable exception at the moment. # oniux * Worked together with a contributor to make oniux work without capabilities, by using user namespaces! * This is a really cool thing I am pretty proud of. 🙂 * Fixed a bug regarding mounting by studying the mount(2) syscall in depth and re-mounting '/' with MS_PRIVATE | MS_REC everywhere in order to avoid "leaks" outside of the mount namespace * Improved the overall documentation of oniux # misc * I had some time off this month due to two public holidays as well as a sickness from which I had to recover (nothing serious, just a common cold, I am already doing fine again) * There was also some legal stuff regarding my planned switch from a contractor to an employee * I submitted a talk about onion services to the GPN23 in Karlsruhe

1 0