Hey everyone!
Here are our meeting logs:
http://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-03-13-16.00.html
And our meeting pad:
Anti-censorship work meeting pad
--------------------------------
Anti-censorship
--------------------------------
Next meeting: Thursday, March 20 16:00 UTC
Facilitator: shelikhoo
^^^(See Facilitator Queue at tail)
Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC
(channel is logged while meetings are in progress)
This week's …
[View More]Facilitator: onyinyang
== Goal of this meeting ==
Weekly check-in about the status of anti-censorship work at Tor.
Coordinate collaboration between people/teams on anti-censorship at the
Tor Project and Tor community.
== Links to Useful documents ==
* Our anti-censorship roadmap:
*
Roadmap:https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards
* The anti-censorship team's wiki page:
*
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home
* Past meeting notes can be found at:
* https://lists.torproject.org/pipermail/tor-project/
* Tickets that need reviews: from projects, we are working on:
* All needs review tickets:
*
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s…
* Project 158 <-- meskio working on it
*
https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na…
== Announcements ==
*
== Discussion ==
* snowflake dependencies need go 1.23
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* should we update it?
* go 1.23 is already in debian backports
* Tor Browser is already using go 1.23?
* no, Tor Browser is staying on 1.21 on macOS until ESR
140, due June 2025
* we will hold off on the dependency updates (which contain
changes we believe do not affect us) until after ESR 140 and Tor Browser
updating to go 1.23
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* should we change default relay pattern policy on snowflake broker
*
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
* we still have relays that have not updated since we added
support for multiple bridges
* The purpose of the allowed relay pattern check at the broker
is not to avoid surprising proxy operators by connecting to a new relay
destination; it's because old proxies that do not send a relay pattern
to the broker cannot connect to any other relay destination. They have
snowflake.torproject.net hardcoded and do not know how to connect to any
other relay. If a client were to request a connection to the
snowflake-02 relay, and was assigned such an old proxy, the proxy would
connect to snowflake-01 anyway, and leave the client with a Tor
fingerprint mismatch error.
* Therefore adjusting the presumedPatternForLegacyClient on the
broker to accept old proxies would not work. Old proxies (that don't
support relay patterns) would start getting clients again, but any
clients that request a relay other than snowflake-01 would get failed
connections.
* There's no facility on the broker to, say, match old proxies
only with those clients that happen to request snowflake-01. Once a
proxy is in the pool, it's treated equally to all other proxies. Such a
matching facility could conceivably be implemented, but none currently
exists. It may not be worth the complexity anyway.
* The intention therefore was that the broker simply reject old
proxies (that do not send a relay pattern). That is, in effect, what is
now happening, but it happens by a roundabout way: proxy polls and
doesn't set an allowed relay pattern → broker assigns a default allowed
relay pattern that never works → broker rejects the proxy poll because
of the relay pattern mismatch.
* The downsides of the status quo are that (1) the broker logs
are full of "rejected relay pattern from proxy" errors, and (2) the old
proxies just keep on uselessly polling.
* Consensus for dealing with the current situation:
* Make the broker code more straightforward with respect to
rejecting old proxies: do it at an early stage, don't even bother
assigning a default relay pattern to them (and remove the code that does).
* Update metrics/logging. Disable the "rejected relay
pattern from proxy" at the broker, and just keep it as a metrics counter.
* For the future, it would be handy if there were a feature
whereby the broker, by sending a specific kind of response to a proxy,
could cause the proxy to disable itself (say, stop polling for 24h) and
log a visible message to the operator. In effect, we could push the
"rejected relay pattern from proxy" error out to the proxy logs, which
would (1) stop proxies that only support an obsolete protocol from
uselessly polling, and (2) inform the operator and encourage them to
upgrade.
* In the absence of such a feature, it might be possible to
find a way to crash old proxies by sending a specific kind of broker
response. For example, an overlong HTTP body, or a JSON unmarshaling
error. Even if it is not possible to convey a reason why it is happening
to the proxy operator, it might get the operators attention, and at
least reduce unhelpful polling volume.
* One complication with this idea: some proxies are running
in a container, or similar, and are configured to auto-restart after
they exit. Proxies that work this way might paradoxically increase their
effective polling rate if remotely disabled, because there's no interval
rate limiting on the first poll.
* Even so, if we find such a "disable" broker response, we
could try having the broker send it to old proxies (those that don't
support relay patterns) for 1h. The ones that are configured to restart
will restart, but the one that are not will stop operating.
* Related issue: "Let the broker inform proxies how often
to poll"
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow….
The broker could send a time many hours in the future. This would help
with reducing the polling rate, even if it does not result in the proxy
log message.
* A standalone proxy auto-update mechanism could be an
alternative or addition to support for a broker "disable" signal.
== Actions ==
== Interesting links ==
*
== Reading group ==
* We will discuss "" on
*
* Questions to ask and goals to have:
* What aspects of the paper are questionable?
* Are there immediate actions we can take based on this work?
* Are there long-term actions we can take based on this work?
* Is there future work that we want to call out in hopes
that others will pick it up?
== Updates ==
Name:
This week:
- What you worked on this week.
Next week:
- What you are planning to work on next week.
Help with:
- Something you need help with.
cecylia (cohosh): 2025-03-13
Last week:
- wrote and deployed a CPU and goroutine profiling patch for
the snowflake broker (snowflake#40447)
- found a potential performance improvement related to
mutexes (snowflake#40458)
- confirmed that congestion isn't the cause of sqs
rendezvous errors (snowflake#4036)
- found source of "rejected relay pattern" log messages
(snowflake#40454)
- modified broker metrics to show client polls that timed out
(snowflake!530)
- reviewed merge requests
- helped with conjure pt work
This week:
- support conjure work
- follow up on snowflake rendezvous failures
- reduce/remove use of mutexes for broker metrics
(snowflake#40458)
- set absolute time limit on broker http responses
(snowflake40449)
- snowflake proxy release
- take a look at potential snowflake orbot bug
- https://github.com/guardianproject/orbot-android/issues/1183
- maybe do some lox work
dcf: 2025-03-13
Last week:
- snowflake VPS hosting bookkeeping
https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co…
Next week:
- open issue to have snowflake-client log whenever KCPInErrors
is nonzero
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
- parent:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Help with:
meskio: 2024-03-13
Last week:
- set up snowflake proxies with coverdtls (snowflake!448)
- investigate why our email distributor is not handing out
emails (rdsys#260)
- debug gitlab container proxy (snowflake!522)
- investigate why users get bridges with local addresses (team#156)
Next week:
- steps towards a rdsys in containers (rdsys#219)
- investigate rdsys distributing local addressed bridges (team#156)
Shelikhoo: 2024-03-13
Last Week:
- [Testing] Unreliable+unordered WebRTC data channel transport
for Snowflake rev2 (cont.)(
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
) testing environment setup/research
- Vantage Point maintaince
- Merge request reviews
Next Week/TODO:
- Merge request reviews
- [Testing] Unreliable+unordered WebRTC data channel transport
for Snowflake rev2 (cont.)(
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
) improvements
- Snowflake Staging Server
Discussion(https://gitlab.torproject.org/tpo/tpa/team/-/issues/42080)
- Vantage Point maintaince
onyinyang: 2025-03-13
Last week(s):
- continued work on ampcache registration method for conjure
- WIP MR: https://github.com/cohosh/conjure/pull/1
-
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj…
- lox issuer efficiency merged!
Next week:
- HACS/Zkproofs/OSCW/RWC
- finish up ampcache registration method
- Begin work on decoy registration option
- review Tor browser Lox integration
-
https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests…
- add TTL cache to lox MR for duplicate responses:
https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/305
As time allows:
- Work on outstanding milestone issues:
- key rotation automation
Later:
pending decision on abandoning lox wasm in favour of some kind
of FFI?
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096):
- add pref to handle timing for pubkey checks in Tor browser
- add trusted invitation logic to tor browser integration:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974
- improve metrics collection/think about how to show Lox is
working/valuable
- sketch out Lox blog post/usage notes for forum
(long term things were discussed at the meeting!):
- brainstorming grouping strategies for Lox buckets (of
bridges) and gathering context on how types of bridges are
distributed/use in practice
Question: What makes a bridge usable for a given user, and
how can we encode that to best ensure we're getting the most appropriate
resources to people?
1. Are there some obvious grouping strategies that we
can already consider?
e.g., by PT, by bandwidth (lower bandwidth bridges
sacrificed to open-invitation buckets?), by locale (to be matched with a
requesting user's geoip or something?)
2. Does it make sense to group 3 bridges/bucket, so
trusted users have access to 3 bridges (and untrusted users have access
to 1)? More? Less?
theodorsm: 2025-03-06
Last weeks:
- Implementing key_share extension support in covert-dtls
- Implementing mimicking DTLS 1.3 extensions
- Debugging Tor Build with covert-dtls:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
Next weeks:
- Update MR with new covert-dtls version.
- Write instructions on how to configure covert-dtls with
snowflake client
- Fix merge conflicts in MR
(https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…).
- Condensing thesis into paper (on hold)
Help with:
- Test stability of covert-dtls in snowflake
Facilitator Queue:
onyinyang shelikhoo meskio
1. First available staff in the Facilitator Queue will be the
facilitator for the meeting
2. After facilitating the meeting, the facilitator will be moved to the
tail of the queue
--
---
onyinyang
GPG Fingerprint 3CC3 F8CC E9D0 A92F A108 38EF 156A 6435 430C 2036
[View Less]
Hi! Below is my February’25 (Period: 2025-02-01 - 2025-02-28) report!
In February, I began working on tests and documentation, focusing on
integrating pluggable transports with little-t-tor on Windows. I then
collected data across different operating systems and contributed to the
corresponding GitLab documentation ticket.
Spent some time learning the workflow for merging and committing
documents in GitLab for the Tor Project.
*Add documentation about using pluggable …
[View More]transports with little-t-tor*
<https://gitlab.torproject.org/tpo/web/support/-/issues/378#top>
https://gitlab.torproject.org/tpo/web/support/-/issues/378
Thanks,
Haidi
[View Less]
Hello Tor Project Team,
I am interested in contributing to the Tor Project as part of Google Summer
of Code (GSoC) 2025. Specifically, I want to work on the Relay to Relay
Connectivity in the Tor Network project. To do so, I need access to GitLab
for:
- Reviewing and discussing project issues.
- Contributing code and submitting merge requests.
- Communicating with mentors and other contributors.
Here are my details:
- Name: Harshita Roonwal
- Preferred Username: harshita_r
…
[View More]- Email Address: roonwal721972(a)gmail.com
- GSoC Project Interest: Relay to Relay Connectivity in the Tor Networ
Looking forward to your approval.
*Best Regards*
[View Less]
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 …
[View More]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…
[View Less]
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 …
[View More]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/
[View Less]
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 …
[View More]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
[View Less]
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, …
[View More]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
[View Less]