Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2022-11-22T13:00:04Zhttps://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/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/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/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/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/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%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42355Fullscreen on Android doesn't hide system bars2024-01-11T16:31:14ZPier Angelo VendrameFullscreen on Android doesn't hide system barsIn Tor Browser 13.0.7, when you go on fullscreen on Android, system bars persist.
So, as a matter of fact, it isn't a real fullscreen.
STR:
1. Open a video (tried on Invidious instances, but also other sites)
2. Go to fullscreen
3. No...In Tor Browser 13.0.7, when you go on fullscreen on Android, system bars persist.
So, as a matter of fact, it isn't a real fullscreen.
STR:
1. Open a video (tried on Invidious instances, but also other sites)
2. Go to fullscreen
3. Notice that the both the bar with clock/notifications and the "navigation" bar are still visible (I'm using gesture-based navigation, so I don't have a bar with buttons, but a bar with a horizontal line)
If you open the same site on Firefox (but without a custom config such as ours), fullscreen works as expected.
It might have started after the security backport.
Tested on my Pixel 4a, I've seen the problem both on 13.0.7 and on 13.5a3.
/cc @ma1ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42305(Semi-)Automatically merge translation resources across tor browser releases ...2024-03-26T20:31:08Zhenry(Semi-)Automatically merge translation resources across tor browser releases (desktop)/cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch.../cc @emmapeel @pierov
When I had my time offline the week before last I wrote a script to which takes a `tor-browser` or `firefox-android` translation file (`.dtd`, `.properties`, `.ftl`, or android `.xml`), and a new and an old branch name, and merges the versions found in both branches together with a comment added for strings that will be dropped at the next release. Here is the initial draft of the script if you want a quick look: [combine-translation-versions.py](/uploads/83cf1424566cf3b3222e6a60682bcc56/combine-translation-versions.py)
We could use the output as the `en-US` source files for weblate, combining both the strings needed for the next release as well as for the current stable release. The idea being that in tor-browser we can stop trying to maintain all the old strings in the current development branch that are still needed for the current stable release. And we can avoid having to manual clean ups of old strings, like in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42221.
E.g., if we have `tor-browser.ftl` in tor-browser-xxx-13.5 with the content
```
string1 = String 1
new-string = New String
string2 = String 2
```
and in tor-browser-xxx-13.0 with the content
```
old-string = Old String
string1 = String 1
string2 = String 2
```
the script would output
```
string1 = String 1
new-string = New String
string2 = String 2
## Will be unused in Tor Browser 13.5!
old-string = Old String
```
The reason I add the comment is to provide a little notification to weblate translators in the "Source string description" to let them know that a string has a short lifetime. Weblate doesn't support descriptions for `.dtd` though so it won't work for that format.
@emmapeel and @pierov what do you think? And where would we want to run this script?
I guess we basically want to merge the translations files from both the branch used for current nightly and current stable. I'm not sure if this can be automatically pulled from `tor-browser-build` in a convenient way, or whether we would need some manual input.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42272Use a single QR code for multiple traditional bridge lines (≤3)2024-01-30T15:01:17ZdonutsUse a single QR code for multiple traditional bridge lines (≤3)See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.png.See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-qr.png.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42271Transition non-Lox bridges (i.e. built-in, requested, added) to use the new b...2024-01-30T15:01:22ZdonutsTransition non-Lox bridges (i.e. built-in, requested, added) to use the new bridge card formatSee the Figma file: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1)See the Figma file: [Figma / Tor Browser 13.5 / lox](https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=151%3A9289&mode=design&t=wDYnw2iq2A868OmH-1)henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42266Create "Find more bridges" sub-section within bridge settings2024-01-30T15:00:25ZdonutsCreate "Find more bridges" sub-section within bridge settingsSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pnghenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42265Add empty state placeholder for bridge cards2024-01-30T15:01:35ZdonutsAdd empty state placeholder for bridge cardsSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pnghenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42264Update strings across bridge settings as per the designs2024-01-30T15:02:27ZdonutsUpdate strings across bridge settings as per the designsSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pngSee: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036/designs/lox-not-connected.pnghenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42253Remove "New private tab" action and widget2024-02-22T13:38:36ZclairehurstRemove "New private tab" action and widget<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
After a long press on the icon, there is a "New private tab" button that has a lot of issues surrounding it (often brea...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
After a long press on the icon, there is a "New private tab" button that has a lot of issues surrounding it (often breaking the app) and I don't think that we need it. For instance if you tap on it when already connected to tor, you can get the screen in the second screenshot. If you then try to search you get the 3rd screenshot. It also has firefox branding (the eye mask).
### Relevant logs and/or screenshots
![Screenshot_2023-11-06_at_16.24.07](/uploads/2aa2eaf031aac3c14880cbca53686643/Screenshot_2023-11-06_at_16.24.07.png){width=25%}
![Screenshot_2023-11-06_at_16.41.11](/uploads/53a6a6e68f731283a643758305f071d5/Screenshot_2023-11-06_at_16.41.11.png){width=25%}
![Screenshot_2023-11-06_at_16.43.13](/uploads/1e8b83540fa18a73a585a2ef5d9843b4/Screenshot_2023-11-06_at_16.43.13.png){width=25%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42238Remove unwanted background from icons2023-11-20T15:27:01ZclairehurstRemove unwanted background from icons<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
In app and search widget Icons have an unwanted background. The icon with a background tint was only meant for the play...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
In app and search widget Icons have an unwanted background. The icon with a background tint was only meant for the playstore and launcher, not for any other UI
### Relevant logs and/or screenshots
Home screen ![Screenshot_2023-11-02_at_17.25.37](/uploads/a4f0364697a4602d68856cd43e8e65ea/Screenshot_2023-11-02_at_17.25.37.png)
Search Widget![Screenshot_2023-11-02_at_17.52.18](/uploads/ac65de8129ce4b1d1500c7d6f3bc5415/Screenshot_2023-11-02_at_17.52.18.png)clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42231Improve the network monitor patch for http onion resources2023-12-04T12:08:17Zcypherpunks1Improve the network monitor patch for http onion resourcesThe current patch (!646) adds a Security tab for http onion resources which crashes the Network panel when clicked. The security status could also take `dom.securecontext.allowlist_onions` into account.The current patch (!646) adds a Security tab for http onion resources which crashes the Network panel when clicked. The security status could also take `dom.securecontext.allowlist_onions` into account.