Hello everyone,
This is a summary of the work I did in the month of September followed
by a more detailed report of the work done by our user support team. I
made some small additions to the user-facing documentation on our
Support Portal[0]. With 7 Tor Browser (Alpha and Stable) releases in the
month, I answered a number of Tor Browser related user support tickets
and allocated some time to test the latest Alpha releases. Majority of
my work was dedicated to help users in regions where Tor is censored
which includes but is not limited to 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.
Here's a more detailed breakdown of the tickets our user support team
worked on last month:
# Frontdesk (email user support channel)
* 543(↓) RT tickets created
* 712(↑) RT tickets resolved
Tickets by topics and numbers:
1. 322(↓) RT tickets: private bridge requests from Chinese speaking
users.
2. 193(↓) RT tickets: circumventing censorship in Russian
speaking countries.
3. 8 RT tickets: help with installing Tor Browser on
desktop operating systems.
4. 6 RT tickets: questions about Tor Browser dropping support for legacy
operating systems, i.e. Windows 7/8/8.1 and macOS ≤ 10.14[1].
5. 3 RT tickets: questions about using Tor from users in Brazil after
X (Twitter) was blocked.
6. 3 RT tickets: Captchas missing when fetching bridges from BridgeDB[2].
7. 3 RT tickets: instructions to download Tor Browser binaries from
GetTor (email and Telegram).
8. 3 RT tickets: questions about contributing to Tor.
9. 2(↓) RT tickets: circumventing censorship with Tor in Farsi.
10. 2 RT tickets: help with instructions to verify Tor Browser signature.
11. 2 RT tickets: reports of Letterboxing in Tor Browser visible even if
disabled with tiled window managers[3].
12. 2 RT tickets: reports of websites blocking Tor.
13. 2 RT tickets: reports of fake apps on iOS AppStore masquerading as
official Tor Browser.
14. 2 RT tickets: how to add/change default search engine on Tor Browser.
15. 2 RT tickets: questions about the 'Security Levels' in Tor Browser.
16. 1 RT ticket: help with setting up a Snowflake proxy.
17. 1 RT ticket: help with setting up a Bridge relay.
18. 1 RT ticket: anti-virus (on Windows) blocking Tor Browser.
# Telegram, WhatsApp and Signal Support channel
* 814(↑) tickets resolved
Breakdown:
* 773(↑) tickets on Telegram
* 41(↑) tickets on WhatsApp
* 0(-) ticket on Signal
Tickets by topics and numbers:
1. 471(↓) tickets: circumventing censorship in Russian speaking
countries.
2. 45(↓) tickets: circumventing censorship with Tor in Farsi.
3. 30(↑) tickets: private bridge requests from Chinese speaking users.
4. 20 tickets: helping users on iOS, using Onion Browser or Orbot, to
use censorship circumvention methods.
5. 11 tickets: instructions on how to get Tor Browser binaries from GetTor.
6. 8 tickets: questions about what onion services are and how to access them.
7. 6 tickets: help with using bridges with Orbot.
8. 5 tickets: help with troubleshooting Tor Browser install on Linux.
9. 4 tickets: troubleshooting Tor Browser install on Android.
10. 3 tickets: instructions to use bridges with Tails.
11. 2 tickets: help with troubleshooting Tor Browser install on macOS.
12. 2 tickets: help with setting up Snowflake proxy.
13. 2 tickets: help with using bridges with little-t-tor.
14. 1 ticket: question about using Tor from a user in Brazil after
X (Twitter) was blocked.
# Highlights from the Tor Forum
1. Call for alpha testers to help test the latest Tor Alpha before Tor
Browser 14 release[4].
2. Disable compatibility mode on Windows 10/11 to
not get notified about Tor Browser dropping support for legacy operating
systems[5][1].
3. NoScript per-site permissions on Tor Browser[6].
4. Do not disable NoScript in Tor Browser[7].
Thanks!
e.
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.
[0]: https://gitlab.torproject.org/tpo/web/support/-/commits/main?author=ebanam
[1]: https://support.torproject.org/tbb/tor-browser-and-legacy-os/
[2]: https://lists.torproject.org/pipermail/tor-relays/2024-September/021868.html
[3]: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42670
[4]: https://forum.torproject.org/t/new-alpha-release-tor-browser-14-0a7/14862
[5]: https://forum.torproject.org/t/dont-understand-warning-about-windows-releas…
[6]: https://forum.torproject.org/t/noscript-per-site-permissions-question-about…
[7]: https://forum.torproject.org/t/should-i-disable-noscript-in-tor-browser/144…
Hi all :)
This is my monthly status report for September 2024 with the main relevant
activities I have done, was involved or are related to my work during the
period.
For other Onion Services news, check this post:
https://forum.torproject.org/t/some-news-from-the-onionspace-2024-09/14963
# Planning
Helped with the overall planning for the upcoming Onion Service tooling
development.
It allowed me to figure out priorities, and finally clean my backlog.
This also resulted in creating an Onion Services feature matrix
comparing Arti and C Tor:
https://onionservices.torproject.org/dev/implementations/
The current plan is summarized below.
## Oniongroove - next generation onionsite manager
Project page: https://onionservices.torproject.org/apps/web/oniongroove/
Plan: have Oniongroove acting as a middleware, abstracting specifics from the
underlying Tor (and perhaps the HTTPS rewriting proxy) implementation.
Advantages: it might be easier for Onion Service Operators to adopt
a tool supporting both backends. They can start using the C Tor backend
and later on switch for Arti, eg. once the needed feature set becomes
supported.
Current goals:
* Goal 1: support both C Tor and Arti as backends (prototype).
* Goal 2: feature-parity with Onionspray, for the C Tor
backend (taking some onionsites we manage as a reference for
the requirements); migration procedure from Onionspray (production-ready).
## Onionspray - current onionsite manager
Project page: https://onionservices.torproject.org/apps/web/onionspray/
Current focus:
* Keep supporting Onionspray until there's feature parity with Oniongroove,
plus a migration procedure.
* Merge requests are welcome :)
## Onionbalance - load balancer for Onion Services
Project page: https://onionservices.torproject.org/apps/base/onionbalance/
The road mapping discussion for Onionbalance is still ongoing.
Meanwhile, my focus would be to keep the software working, and going through
issues and MRs when doable.
It's still uncertain how load balancing with Onion Services should be done
in the long term, since:
* Proof of Work (PoW) Support in Onionbalance is still in the
discussion phase:
https://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/13
* A replacement built-in directly on Arti still needs design; it will possibly
be based on changes in the descriptor; a publisher node would be way simpler
than the current functionality. There's still no timeline for that.
On the other hand, Onionbalance is basically a descriptor publisher. So,
roughly speaking, migrating away from Onionbalance to an Arti-equivalent
implementation won't require Operators to migrate all their C Tor setup to
Arti: they could just replace their Onionbalance instance with something else
and keep all their backend onionsites with C Tor for a while.
That said, depending on the design changes to implement PoW, it would still
be needed to backport this feature to the C Tor backends and clients, which may
not be a lot of stuff (possibly just descriptor changes).
In summary, one way to move forward could be (but these are still only
speculations):
1. Creating a spec for PoW with descriptor-based load balancing: this seems to be
mostly about (new) descriptor field(s).
2. Evaluate/scope what would be needed to:
* Implement this both for Onionbalance. Maybe it's just a few changes...
* Implement this on Arti. That involves implementing the whole load
balancing feature.
* Backport the changes needed on C Tor both for backends and clients.
3. Then we could decide whether to do it for Onionbalance to win time, or
just skip it in favor of a migration.
## Onionprobe - monitoring tool for onionsites
Project page: https://onionservices.torproject.org/apps/web/onionprobe/
Current focus: properly set the Grafana dashboard within Tor Project:
https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/93
Support for the Arti backend was postponed to future (2026+), after Arti's RPC
is stabilized. This is being tracked at
https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/86
There are lots of ideas for improvements, that may be implemented
opportunistically.
# Documentation
Did some documentation updates, including:
* The Certificate Proposals page:
https://onionservices.torproject.org/research/proposals/usability/certifica…
* Some roadmap scenarios (but these still need more work):
https://onionservices.torproject.org/research/scenarios/ux/https://onionservices.torproject.org/research/scenarios/network/
--
Silvio Rhatto
pronouns he/him
Hi! Below is my September’24 report!
In September, I resolved 994 (↑16) tickets:
* On Telegram (@TorProjectSupportBot) - 728 (↑41);
* On RT (frontdesk@tpo) - 189 (↓44);
* On WhatsApp (+447421000612) - 27 (↑19);
* and on Signal (+17787431312) - 0 (0).
I also took part in forum moderation [1], worked with storereviews, and
joinedthe Tor relay operators meetup.
The focus of my work is to help Russian-speaking users:
- to bypass censorship and to connect to Tor;
- to troubleshoot any problems with Tor Browser;
- to collect users' feedback and then use it to provide working bridges.
We still got many tickets from Russia due to internet censorship getting
stronger; our users reported that many Tor bridges didn't work for
them.Also, we got multiple requests from Russian-speakingTails users.
In September, I also checked and edited several user support
templatesused in our support tools.
*Google Play Reviews for Tor Browser**(TBA)**and Tor Browser Alpha**for
Android*
Tor Browser App had a Google Play rating of 4.388-4.390 stars in
September 2024.
Tor Browser App got 668 reviews out of 57976 for the lifetime.
Most often topics of the reviews:
- Samsung users point out the error "Proxy server refused connection"
on their devices; [2]
- Some (mostly Google Pixel) users complain about Tor Browser draining
battery of their devices; [3]
- Tor Browser doesn't work - mostly from users from Russia, who are
struggling to find the working bridge;
- Kind words from Portuguese-speaking users from Brazil who started
using Tor Browser due to an internet censorship case in the country -
the X platform (former Twitter) was blocked [4].
Tor Browser Alpha App had a rating of 4.265, lower than Tor Browser Stable.
In September, Tor Browser Alpha got 35 reviews out of 8337 for the lifetime.
[1] https://forum.torproject.org
[2]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42714
[3]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43137
[4] https://en.wikipedia.org/wiki/Blocking_of_Twitter_in_Brazil
Hi everyone!
Here is my status report for September 2024.
I dedicated a consistent part of this month to various tasks to fix
regressions we got after migrating to Firefox 128 or for refinements.
I started by re-implementing our search engine customization.
Upstream themselves reworked their configuration, so I ended up
reverting our previous patch and implementing a new one [0].
While at it, I removed some search engines we used to bundle by default,
such as Yahoo and Twitter.
I also re-implemented the functionality to send DuckDuckGo searches
through its HTML-only version when running at the safest security level [1].
After doing this for Tor Browser, I wrote similar patches for Mullvad
Browser [2].
After that, I worked on the Android part of our build system. I removed
the Lox WASM blob [3], which isn't currently used on Android. This
allowed us to ship x86 APKs on the Play Store again.
Then, I simulated a release build to check they don't fail when we're
close to the release period. However, they didn't work, and I had to fix
our dependency list [4].
Also, I fixed single-arch Android test builds [5].
Then, I focused on a disk leak problem. Firefox downloads and opens some
formats in the browser without asking for confirmation by default when
the server sends them as attachments.
There's a preference for force-inlining PDFs
(browser.download.open_pdf_attachments_inline), but it doesn't work on
other formats. Therefore, I extended that functionality, but I'm not
completely satisfied. In our issue [6], I documented all the various
problems we still have. However, I will need more time and some help
from upstream to provide a better fix.
I also went back to one of my passions: fonts. I investigated the
differences between having and not having our custom font configuration
on Linux [7], and I thought of some strategies for 14.5, as we are too
late for 14.0. For now, I created some font aliases to improve
compatibility and updated our bundled fonts.
In addition to that, I helped with releasing. I rebased our browsers
onto Firefox 115.16.0esr and 128.3.0esr. Also, I prepared 13.5.3 and
13.5a10. The latter was an unplanned alpha release from a legacy branch
to test the watershed update procedure, which we need to provide
alternative updates for legacy platforms (Windows 7/8 and macOS up to
10.14).
Finally, I attended the Reproducible Build Summit in Hamburg [8]. I
joined the group that focused on writing documentation for repro build
beginners.
Best,
Pier
[0]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests…
[1]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42617
[2]
https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/328
[3]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests…
[4]
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4…
[5]
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4…
[6]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42220
[7]
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41799
[8] https://reproducible-builds.org/events/hamburg2024/
Summary: donation site will be down for maintenance on Wednesday
around 14:00 UTC, equivalent to 07:00 US/Pacific, 11:00
America/Sao_Paulo, 10:00 US/Eastern, 16:00 Europe/Amsterdam.
# Background
We're having [latency issues][] with the main donate site. We hope
that migrating it from our data center in Germany to the one in Dallas
will help fix those issues as it will be physically closer to the rest
of the cluster.
[latency issues]: https://gitlab.torproject.org/tpo/web/donate-neo/-/issues/134
# Proposal
Move the `donate-01.torproject.org` virtual machine, responsible for
the production <https://donate.torproject.org/> site, between the two
main Ganeti clusters, following the procedure detailed in [#41775][].
[#41775]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41775
Outage is expected to take no more than two hours, but no less than 15
minutes.
# References
See the discussion issue for more information and feedback:
<https://gitlab.torproject.org/tpo/tpa/team/-/issues/41775>
--
Antoine Beaupré
torproject.org system administration
Hi,
GitLab recently introduced a maximum lifetime for *all* access
tokens. The change is discussed in a [blog post][1] from last
October. Most importantly:
> As of the 16.0 milestone (May 2023), we applied an expiration date of
> May 14, 2024, to any personal, group, or project access token that
> previously didn't have one.
We first noticed this issue in [January][2] and have looked at
mitigations, but ultimately, there's no good workaround short of
"service accounts" which is some Open Core thing they are pushing onto
us. There's some work upstream to make it easier to rotate tokens (which
make the entire security measure moot in the first place, fun).
So anyways. Your things might break now. And when you recreate the
tokens, they will still have an upper time limit (one year, IIRC), so
you will need to fix this again and again.
I'm sorry. Further discussion in [2]. For now our approach is wait and
see what gitlab.com is going to do, because this is breaking a *lot* of
things in a lot of places, and I can't imagine they will just let the
thing burn for that long. The actual recommended workaround from
upstream now is to have a *pair* of tokens that renew each other but we
have found that to be really impractical.
So for now, we're just trying to document the tokens we have and how to
refresh them, as an immediate mitigation. I encourage you to pay
attention to the "your token has expired" notification as well.
Good luck!
[1]: https://about.gitlab.com/blog/2023/10/25/access-token-lifetime-limits/
[2]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41510
--
Antoine Beaupré
torproject.org system administration