Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2024-03-06T18:39:12Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42436Allow for multiple configured (front, reflector) domain fronting pairs in Moa...2024-03-06T18:39:12ZCecylia BocovichAllow for multiple configured (front, reflector) domain fronting pairs in Moat moduleIt's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastl...It's happened twice now that the domain fronting settings for Moat have stopped working:
- [when `cdn.sstatic.net` moved to CloudFlare](https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000314.html)
- [when Fastly stopped supporting domain fronting and `foursquare.com` renewed its cert](https://github.com/net4people/bbs/issues/309)
When Moat stops working, it leaves us scrambling to find new front domains, the update process requires a new release, and it can be difficult for users to receive updates or connect if Connection Assist is unreachable. It's also difficult to choose a single front domain that will work in almost every place. Even though Connect Assist allows us offer country-specific circumvention settings, we have only a single setting for using Connect Assist itself.
Ideally, we could provide multiple (front, reflector) pairs, and iterate through them until a working pair is found. That pair can be saved for future use until it stops working and the module will re-iterate through the list until a new pair is found.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804Tor Browser's new obfs4proxy client has compatibility issues with old obfs4pr...2022-11-22T13:00:04ZatariTor Browser's new obfs4proxy client has compatibility issues with old obfs4proxy bridges<!--
* Use this issue template for reporting a new bug.
-->
### Summary
When starting TB 11.0.6 on Linux with self-defined bridges at bootstrapping following messages show up in log multiple times:
[WARN] Proxy Client: unable to connec...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
When starting TB 11.0.6 on Linux with self-defined bridges at bootstrapping following messages show up in log multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)
Bridges work after bootstrapping. Warnings irritate anyhow.
### Steps to reproduce:
Set some bridge-lines in TB config and restart the browser
### What is the current bug behavior?
Tor Logs show these warnings multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)
### What is the expected behavior?
No warning like in the builds before
### Environment
Tor Browser 11.0.6 downloaded via auto-update | Linux Debian
Started with ~/tor-browser_en-US/Browser/start-tor-browser
### Relevant logs and/or screenshots
Multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42350newwin: consider exempting some `moz-extension://` scheme windows2024-03-12T09:04:47ZThorinnewwin: consider exempting some `moz-extension://` scheme windowsI'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden chang...I'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden changed from using a new window (in reality in a new tab) to a using a small resized window anchored to the top right - for UX reasons - the problem is, RFP's new win will open it at 1400 x 900 max.
here's how it should look (I'm just using a blank page, it makes more sense on a login)
![bitwarden](/uploads/b71c4f91ac347512424899f1dbf2a882/bitwarden.png)
here's what actually happens
- if you have the width, it actually positions top/left correctly, but the dimensions is the issue. I have just moved the second window for this image
![bitwarden-RFP](/uploads/aca05e5e8988dcc829d9c01dc76581b4/bitwarden-RFP.png)
Note: the scheme is `moz-extension://` and the window has no tabstrip, urlbar, toolbar - so this means it's useless to repurpose for loading websites, so we should be good to exempt these cases from newwin dimensions
@ma1 cc @pierovma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42172browser.startup.homepage and TOR_DEFAULT_HOMEPAGE are ignored for the new win...2023-11-27T08:34:38ZRusty Birdbrowser.startup.homepage and TOR_DEFAULT_HOMEPAGE are ignored for the new window opened by New Identity### Summary
In 13.0, the `browser.startup.homepage` pref (and hence also the `TOR_DEFAULT_HOMEPAGE` environment variable, which populates the pref) is no longer used for the initial new window that is opened by `New Identity`. This new ...### Summary
In 13.0, the `browser.startup.homepage` pref (and hence also the `TOR_DEFAULT_HOMEPAGE` environment variable, which populates the pref) is no longer used for the initial new window that is opened by `New Identity`. This new window uses `about:tor` instead.
### Steps to reproduce:
1. Run `TOR_DEFAULT_HOMEPAGE='https://example.com/' ./start-tor-browser`
2. Connect
3. Trigger `New Identity`
### Environment
Linux (x86_64)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42106SessionFileInternal.getWriter() called too early in new identity2023-10-11T21:37:25ZJeremyRandSessionFileInternal.getWriter() called too early in new identityWhile debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) aft...While debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) after the fixes from @pierov's testbuild were applied. There are still a few errors showing up in the log. Neither Patrick nor I am confident about whether they're harmless, so probably someone should investigate them.
The most concerning (to my untrained eye) log entries are:
```
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]
_collectStartupConditionsTelemetry resource:///modules/BrowserGlue.sys.mjs:1649
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.sys.mjs:1759
BG_observe resource:///modules/BrowserGlue.sys.mjs:981
_delayedStartup chrome://browser/content/browser.js:2106
BrowserGlue.sys.mjs:1658:15
```
```
uncaught exception: SessionFileInternal.getWriter() called too early! Please read the session file from disk first. 2
```
```
TypeError: this.client is undefined
RemoteSecuritySettings.sys.mjs:538:7
```
See the above forum link for full context on where the errors show up in the log. I have no idea whether these errors also show up in non-Whonix environments. To be clear, Patrick isn't observing any actually-wrong *behavior*, so *probably* everything is OK... but seems better to check than assume.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41883Remove Menu > Help > Switching to a new device2023-10-04T15:49:45ZThorinRemove Menu > Help > Switching to a new devicetitle says it alltitle says it allhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41716Figure out how to display conflux circuits in Tor Browser's UI2024-01-29T19:26:13Zmicahmicah@torproject.orgFigure out how to display conflux circuits in Tor Browser's UINow that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer n...Now that circuit display was literally just re-implemented...
When 0.4.8 becomes stabilized (this will take a few months still), conflux will come to the network. Conflux will open a new world with tor circuits: circuits are no longer necessarily static, now they can be dynamic, the TCP circuits can change paths, and can have multiple paths, and doing so can bring some nice improvements for people.
We need to start thinking about how we want to communicate to the user in TB. Specifically that the circuit(s) are conflux circuits. Users knowing that they are using a conflux circuit will provide valuable information to them (and their feedback to us as well).
Because the circuits can now change paths, this could have a lot of UI visualization implications, such as reflecting that there are these paths that are now ready, or that there is a new circuit leg available. That would be the nice (but complicated) signal to users, but starting with something simple by just indicating in the UI that this is a conflux circuit (eg. literally just writing the word 'conflux' in green or something) would be a good first signal step. So there is a UX question here.
For the dev side of things, right now its possible (in 0.4.8) to get from the control port that a circuit is a conflux circuit, but it doesn't have any advanced information that would be useful for multi-leg displays, but if we want to show those types of things, we will need to talk about what would be needed to be added to tor to extract that information.
perhaps we can have a ad-hoc session at our in-person meeting to brief folks on what conflux means and its benefits.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41546Connect button fails silently if pressed immediatley after about:connect load2023-07-31T16:27:56ZcypherpunksConnect button fails silently if pressed immediatley after about:connect loadObserved apparently since 12.0 on multiple Windows machines (7, 2x10 at least).
After starting the browser and clicking `Connect` it waits a second as `Connecting` and returns to `Not connected` again. Clicking `Connect` second time work...Observed apparently since 12.0 on multiple Windows machines (7, 2x10 at least).
After starting the browser and clicking `Connect` it waits a second as `Connecting` and returns to `Not connected` again. Clicking `Connect` second time works as expected. Doesn't seem to be faulty mouse, but who knows.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41541Update builtin bridges from Circumvention Settings API2024-03-27T15:25:34Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40658s96 mega-dev issue on torconnect feature2022-04-15T20:50:21Zrichards96 mega-dev issue on torconnect featureAn issue to track the entire update to the torconnect feature
### Links:
- Design Doc: https://docs.google.com/document/d/16NVqOvIOdy26vvH7P94D1kXmXoppKTRmv4T--fMfHjg/edit
- User-flow figma: https://www.figma.com/file/yApSDTlsppvH8w250...An issue to track the entire update to the torconnect feature
### Links:
- Design Doc: https://docs.google.com/document/d/16NVqOvIOdy26vvH7P94D1kXmXoppKTRmv4T--fMfHjg/edit
- User-flow figma: https://www.figma.com/file/yApSDTlsppvH8w2508zV8k/about%3Atorconnect-User-Flows?node-id=84%3A516
- More User-flow figma: https://www.figma.com/file/Vsh1aPOZGneDX4Zp27mjsK/Sponsor-30?node-id=531%3A2047
- New Moat APIs: https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40025#note_2753073
- Querying new Moat API in tor-browser: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40645
### Todo:
- [x] Handle Moat errors properly:
- https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main/bridgedb/distributors/moat/server.py#L648
- https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main/bridgedb/distributors/moat/server.py#L226
```
<meskio> now you can get two different error codes: 400 and 406
<meskio> 406 is for when it can't find the country for the given IP
<meskio> 400 is for malformed requests, for example see:
```
- [x] implement new moat APIs and replace existing consumers with new moat module (#40645)
- [x] Update the about:torconnect state machine to facilitate the userflow in the above linked figma (#40662)
- @duncan: what do we do when no settings are available for the user's location? we could either go with a fallback (obfs4?) or leave it to the user
- [ ] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40707
- [x] Update the about:torconnect frontend page to match additional UI flows (#40773)
- [x] Update about:preferences page to match new UI designs (#40774)
User Testing from nah: https://www.figma.com/proto/Vsh1aPOZGneDX4Zp27mjsK/Sponsor-30?page-id=531%3A2047&node-id=717%3A3003&viewport=241%2C48%2C0.08&scaling=min-zoom&starting-point-node-id=717%3A3003&show-proto-sidebar=1
Ping @duncan @meskioTor Browser 11.5richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40564[meta] Evaluate if Tor Browser is meeting the needs of our users2022-01-31T16:54:17ZMatthew Finkel[meta] Evaluate if Tor Browser is meeting the needs of our usersTor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important ...Tor Browser has many goals as defined in the [Design document](https://2019.www.torproject.org/projects/torbrowser/design/), but we should take a step backward and look at the larger picture of whether these goals are actually important for the [people](https://community.torproject.org/user-research/persona/) we are trying to protect.
We should be able to justify our general design requirements through the needs of our users, instead of defining the strictest-possible private browser design and then applying that to all of the use cases. Indeed, this should influence tor-browser-spec#25021.
cc @duncan @nahTor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40170Decide how we should notify users that their OS won't be supported in the nea...2021-12-07T10:14:55ZMatthew FinkelDecide how we should notify users that their OS won't be supported in the near futureImmediately, we have:
- [x] #40049
- [x] #40136
We'll have more in the future, so we could create a more general plan now.Immediately, we have:
- [x] #40049
- [x] #40136
We'll have more in the future, so we could create a more general plan now.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40027Publish Fenix-based testing versions on Google Play2020-11-19T18:10:29ZMatthew FinkelPublish Fenix-based testing versions on Google PlayWe can use Google Play's testing channels (internal/alpha/beta) for releasing "preview" and incremental builds of Fenix-based Tor Browser.We can use Google Play's testing channels (internal/alpha/beta) for releasing "preview" and incremental builds of Fenix-based Tor Browser.2020-08-11https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40005Review advice on VPN use during onboarding2022-03-21T20:08:35ZAntonelaantonela@torproject.orgReview advice on VPN use during onboardingMany first-time users are attempting to configure VPNs on Tor Browser, some of whom mistakenly believe VPN usage is critical to protecting their privacy.
This ticket is to review the existing onboarding flow as an education opportunity ...Many first-time users are attempting to configure VPNs on Tor Browser, some of whom mistakenly believe VPN usage is critical to protecting their privacy.
This ticket is to review the existing onboarding flow as an education opportunity and amend as required to provide up to date advice on VPN use.
Consider this as a reference ticket to: https://gitlab.torproject.org/legacy/trac/-/issues/30514https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42429Android Connection Assist Non-Portriat-Phone Sizes Design2024-02-29T00:51:27ZclairehurstAndroid Connection Assist Non-Portriat-Phone Sizes DesignFor tor-browser#41188 we have portrait designs, but don't have landscape (and other non-protrait-phone) designs. How do we want the landscape (and other non-portriat-phone sizes) to look for connection assist? I was messing with trying t...For tor-browser#41188 we have portrait designs, but don't have landscape (and other non-protrait-phone) designs. How do we want the landscape (and other non-portriat-phone sizes) to look for connection assist? I was messing with trying to make it look better and have some references. I made the buttons have a max width, brought the toggle closer to the text, and reduced the spacing for the text so that it fits better horizontally (otherwise views start overlapping on certain screens with enough going on)
Mock Native Landscape
![Mock_Native_Landscape](/uploads/b2f313b9b51ae7a0499b3bfde3d917a7/Mock_Native_Landscape.png)
Current HTML Landscape
![HTML_Landscape](/uploads/6fa173af6b86fa10d8c1db5e072c27da/HTML_Landscape.png)
Mock Tablet
![Mock_Tablet](/uploads/bfc51dbdad8bfc6b6d60ea768e3dfb86/Mock_Tablet.png)
Mock Foldable
![Mock_Foldable](/uploads/38eb8f5c11b61ee47fd8e2c1db3d81be/Mock_Foldable.png)
Current Native Portrait
![Native_Portrait](/uploads/384005393822624e481d9a2e60a3935f/Native_Portrait.png){width=25%}donutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42418TorBrowser leave trace on the Windows Event Log by default and there is no wa...2024-03-05T13:50:25ZcypherpunksTorBrowser leave trace on the Windows Event Log by default and there is no way to stop this!To be clear, Mozilla Firefox does same thing.
Steps.
1. Launch Tor Browser latest
2. Open "eventvwr.ms" (The event viewer of Windows)
3. Open "Windows Logs/Application"
You'll see tons of:
```
The description for Event ID 5 from sourc...To be clear, Mozilla Firefox does same thing.
Steps.
1. Launch Tor Browser latest
2. Open "eventvwr.ms" (The event viewer of Windows)
3. Open "Windows Logs/Application"
You'll see tons of:
```
The description for Event ID 5 from source Tor Browser Launcher cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42406Betterboxing's gradient is visible in new pages2024-02-20T14:38:00ZPier Angelo VendrameBetterboxing's gradient is visible in new pagesI think it's a little bit strange to see the gradient for some time while loading new pages, or under certain other conditions.
![screencapture](/uploads/b30950cd64f8a3c46d97377a7aa04604/screencapture.mp4)
What do you think @jag?I think it's a little bit strange to see the gradient for some time while loading new pages, or under certain other conditions.
![screencapture](/uploads/b30950cd64f8a3c46d97377a7aa04604/screencapture.mp4)
What do you think @jag?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42397Change RFP-spoofed Timezone from UTC to a real-world, less discriminable one2024-03-06T08:57:54ZThorinChange RFP-spoofed Timezone from UTC to a real-world, less discriminable oneSee:
- https://github.com/mullvad/mullvad-browser/issues/96
- https://bugzilla.mozilla.org/show_bug.cgi?id=1835987
Since `UTC` is rare (if not non-existent outside of RFP?) it looks as if this is being used as a blocker in some anti-bot...See:
- https://github.com/mullvad/mullvad-browser/issues/96
- https://bugzilla.mozilla.org/show_bug.cgi?id=1835987
Since `UTC` is rare (if not non-existent outside of RFP?) it looks as if this is being used as a blocker in some anti-bot scripts etc, and while TB and RFP are not trying to hide, it's not ideal to use non-common values for compat reasons - not that this is compat. `UTC` is unique (with `Factory` which is just as rare if even used) as a stable all-year-round, all-years measurement for other dates (which usually also have DTS) to be compared to. That is, only `UTC` is _always_ offset as `0` (which makes sense). This made it easy and simple for users to calculate their real time on sites - e.g. sporting event times
Using an amazing tool I found on the internet, tests reveal that there are 13 real-world TZs being used that are identical since 1912, and only off by 16.3333 minutes prior to that
- https://arkenfox.github.io/TZP/tests/timezones.html
- turn on RFP so the diffs are 0's
- type in `1911, 1912`, run `combine years`
item 1
```
<snip> UTC <snip>
a54eb173
1911: 0, 0
1912: 0, 0
```
item 10
```
Africa/Abidjan, Africa/Accra, Africa/Bamako, Africa/Banjul, Africa/Conakry, Africa/Dakar, Africa/Freetown, Africa/Lome, Africa/Nouakchott, Africa/Ouagadougou, Africa/Timbuktu, Atlantic/Reykjavik, Atlantic/St_Helena
1911: -16.133333333333333, -16.133333333333333
1912: 0, 0
```
If we cover all years, these are still the only differences between these 13 and UTC - i.e pre-1912. PS: I cheated and modified the code to only use those 14 TZs and all years from 0 to 2500 :smile:
So in theory, we could use one of these (or if we were sneaky we could randomize it per eTLD+1 per session/identity), and users use-cases of recent and future dates (calendars, web email, looking up event times for sports or concerts etc) will still look and behave like UTC. Dates prior to 1912 are unlikely to need or even use conversion to the user's timezone (e.g. history articles etc). And this should stop the anti-bot discrimination
I wonder if we patch that here in MB first? What would users think when they see non-UTC being reported? Will we be flooded with bug reports? Note there are no entropy issues as all users would still look the same. One consideration is timeZoneNames, but that would be equivalency of locale (which we set same as language)
cc @ruihildt @tom @richard to check my logic and proposed solutionma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42385Design dialog to share Lox invites2024-02-27T19:07:34ZJag TalonDesign dialog to share Lox invitescc @donuts @henry
**Design estimate:**
* Complexity: small (1 day)
* Copy existing modals from Firefox's design system.
* Uncertainty level: low (1.1)
* I believe there's no uncertainty here. All we need is something that's good ...cc @donuts @henry
**Design estimate:**
* Complexity: small (1 day)
* Copy existing modals from Firefox's design system.
* Uncertainty level: low (1.1)
* I believe there's no uncertainty here. All we need is something that's good enough for now.
* Total: 1-1.1 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42370Missing Tor Browser for Android store icon for F-droid2024-01-19T16:32:55ZclairehurstMissing Tor Browser for Android store icon for F-droid<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot belo...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot below)
### Environment
**Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.**
**Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.**
F-droid Basic, Calyxos 5.2.0, Android 14, pixel4a
### Relevant logs and/or screenshots
![Screenshot_20240116-122120](/uploads/324de075c1bfb2a67a0f773e03e3e104/Screenshot_20240116-122120.png){width=25%}clairehurstclairehurst