The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-08-18T22:23:22Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41735Fix the size and styling of the builtin bridges dialog to make it more consis...2023-08-18T22:23:22ZDan BallardFix the size and styling of the builtin bridges dialog to make it more consistent with FirefoxImprove the UX of the built-in bridges dialog (left over from #41617)
We've observed that users often find it difficult to differentiate between Tor Browser's various bridge options, tend to choose a built-in bridge option at random (se...Improve the UX of the built-in bridges dialog (left over from #41617)
We've observed that users often find it difficult to differentiate between Tor Browser's various bridge options, tend to choose a built-in bridge option at random (see: tpo/ux/research#100), and have trouble figuring out how to connect afterwards (see: #41060).
In response, we're proposing:
Fixing the size and styling of the dialog and its constituent elements to make it more consistent with Firefox
The Figma file is ready for dev handoff here: Figma link
This needs more clarification and was also determined to be worth deXULifying the dialog so wouldn't make the origional s30 timeframehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41731privacy.resistFingerprinting breaks pinch zoom on DuckDuckGo maps (Apple Maps...2023-12-11T14:39:03Zrichardprivacy.resistFingerprinting breaks pinch zoom on DuckDuckGo maps (Apple Maps/MapKit)Upstream here: https://bugzilla.mozilla.org/show_bug.cgi?id=1826051
Proposed solution is to remove pointer event support from RFP on Android. Seems like a reasonable idea but we should look into it and ensure pointer-related things are ...Upstream here: https://bugzilla.mozilla.org/show_bug.cgi?id=1826051
Proposed solution is to remove pointer event support from RFP on Android. Seems like a reasonable idea but we should look into it and ensure pointer-related things are normalized.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/161Mullvad browser classified as (Known Malicious) by McAfee Endpoint2023-08-18T22:29:04ZruihildtMullvad browser classified as (Known Malicious) by McAfee Endpoint> I had a few hours with it at work before my corporate office security team decided to contain the executable due to McAfee's classification. I'm not sure who's in charge of Mullvad browser's development, but I might touch base with som...> I had a few hours with it at work before my corporate office security team decided to contain the executable due to McAfee's classification. I'm not sure who's in charge of Mullvad browser's development, but I might touch base with some endpoint security vendors. I honestly don't know if it's McAfee's classification that's the problem or just my corporate idiot overlords. One thing is for sure, it didn't get their attention until after the fact because of how the browser is categorized.
>
> That said, screw corporate. I'll be running this more at home.
Source: https://www.reddit.com/r/mullvadvpn/comments/12bxwrv/mullvad_browser_classified_as_known_malicious_by/?rdt=40870https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/160Disable the cookie exceptions button in Private Browsing Mode2023-08-22T20:05:15ZruihildtDisable the cookie exceptions button in Private Browsing ModeCurrently, there's a warning in a grey box, which is very easy to miss (and is indeed missed by a lot of people).
Couldn't we just hide controls what is not relevant in PBM?
![image](/uploads/4fd1e374de35886be3d3e07d4ff05a48/image.png)...Currently, there's a warning in a grey box, which is very easy to miss (and is indeed missed by a lot of people).
Couldn't we just hide controls what is not relevant in PBM?
![image](/uploads/4fd1e374de35886be3d3e07d4ff05a48/image.png)
There's also a [related issue](https://github.com/mullvad/mullvad-browser/issues/29) in Mullvad's Github.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/157External links in the settings don't show a preview2023-08-22T19:59:06ZruihildtExternal links in the settings don't show a previewIn `about:preferences#general`, if you hover over `What's new` in the Mullvad Browser Updates section, a preview of the destination appears at the bottom left.
When you hover over similar links in the Settings linking to Mozilla pages, ...In `about:preferences#general`, if you hover over `What's new` in the Mullvad Browser Updates section, a preview of the destination appears at the bottom left.
When you hover over similar links in the Settings linking to Mozilla pages, you don't see the preview.
It would be nice to view the preview.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41715Outdated information in `about:manual#plugins`2023-08-22T19:52:56ZruihildtOutdated information in `about:manual#plugins``Video websites, such as Vimeo make use of the Flash Player plugin to display video content.`
AFAIK, this is not true anymore. Flash is dead anyway.^^`Video websites, such as Vimeo make use of the Flash Player plugin to display video content.`
AFAIK, this is not true anymore. Flash is dead anyway.^^https://gitlab.torproject.org/tpo/core/arti/-/issues/799Bootstrap event sender doesn't always report readiness correctly2023-11-13T15:40:07ZetaBootstrap event sender doesn't always report readiness correctlyIt's unclear whether this is working as intended or not, but it appears that loading a bootstrapped directory successfully from cache won't go and update the bootstrap status reported through `BootstrapEvents` as hitting 100%. The most I...It's unclear whether this is working as intended or not, but it appears that loading a bootstrapped directory successfully from cache won't go and update the bootstrap status reported through `BootstrapEvents` as hitting 100%. The most I managed to get it to was
```
2023-03-28T15:26:53.339788Z DEBUG arti_client::status: 45%: connecting successfully; directory is fetching authority certificates (8/8)
```
Since it never sets `ready_for_traffic` either, consumers depending on the bootstrap event sender might mistakenly think that bootstrap is still ongoing.
You can work around this in client code by calling `TorClient::bootstrap` manually and reporting completion when that function returns, but it'd be nice to have the event sender fixed;
- it seems weird that `TorClient::bootstrap` can return without `ready_for_traffic` also being set;
- and it seems weird that you will only see the 100% bootstrap event state when downloading a fresh directory.
(arti 1.1.2 installed via Cargo on Linux, but the problem also happens embedded on Android)Arti: Feature parity with the C implementationNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151WebRTC leaks UDP traffic outside socks5 proxy2024-02-21T13:20:46ZruihildtWebRTC leaks UDP traffic outside socks5 proxy- Connect to a socks5 proxy on port 1080 in your LAN that uses a different IP than your computer
- Create a room on meet.mullvad.net jitsi instance
- tcpdump on interface connected to internet and filter out port 1080
- observe UDP traff...- Connect to a socks5 proxy on port 1080 in your LAN that uses a different IP than your computer
- Create a room on meet.mullvad.net jitsi instance
- tcpdump on interface connected to internet and filter out port 1080
- observe UDP traffic to the remote jitsi meet peer
So this is not specific to Mullvad Browser, so not sure how/if we need to deal with it.ma1ma1https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/147On macOS, the launcher uses the stable icon even when alpha2023-10-16T21:19:18ZruihildtOn macOS, the launcher uses the stable icon even when alphaWhen installing the browser on macOS, the icon in the Applications folder and in the browser are correctly using the green alpha version.
However, the launcher icon in the bar is using the stable yellow version.When installing the browser on macOS, the icon in the Applications folder and in the browser are correctly using the green alpha version.
However, the launcher icon in the bar is using the stable yellow version.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/143Uninstalling when the browser is open on Windows 112023-03-28T10:46:51ZruihildtUninstalling when the browser is open on Windows 11On windows 11, after using the systeminstall, if you uninstall the browser while it's launched:
- the folder in Program Files will not be properly deleted
- trying to reinstall the browser will end up in error
On Firefox, if you try to ...On windows 11, after using the systeminstall, if you uninstall the browser while it's launched:
- the folder in Program Files will not be properly deleted
- trying to reinstall the browser will end up in error
On Firefox, if you try to uninstall the browser while it's running, a warning will popup.https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/129Exceptions to `Warn you when websites try to install add-ons`2023-03-23T15:37:39ZruihildtExceptions to `Warn you when websites try to install add-ons`Currently, this feature doesn't work.
I tried to add `mullvad.net` to see if I would have a warning when I tried to install the Mullvad Browser Extension from there.
But thinking about it, that's probably a feature.^^
What do you thin...Currently, this feature doesn't work.
I tried to add `mullvad.net` to see if I would have a warning when I tried to install the Mullvad Browser Extension from there.
But thinking about it, that's probably a feature.^^
What do you think about removing/hiding the `Exceptions...` button entirely?https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/128Plugins is an empty box2023-03-24T10:27:35ZruihildtPlugins is an empty boxIf it's meant to be empty and will stay empty, wouldn't it be better to hide the section entirely?
In Tor Browser, the following message appears: `Get extensions and themes on addons.mozilla.org`.
![image](/uploads/3d60bbc438033d991e4b...If it's meant to be empty and will stay empty, wouldn't it be better to hide the section entirely?
In Tor Browser, the following message appears: `Get extensions and themes on addons.mozilla.org`.
![image](/uploads/3d60bbc438033d991e4b4c51d604c5ba/image.png)https://gitlab.torproject.org/tpo/core/tor/-/issues/40774libtor.a: pubsub_install tor_raw_abort2024-03-20T17:17:22Zsbslibtor.a: pubsub_install tor_raw_abort### Summary
We see OONI Probe Android crashes where `pubsub_install` calls `tor_raw_abort` for tor 0.4.7.13 using libtor.a embedded into a dynamic library loaded by an Android app. As of 2023-02-09 (around when we started investigating)...### Summary
We see OONI Probe Android crashes where `pubsub_install` calls `tor_raw_abort` for tor 0.4.7.13 using libtor.a embedded into a dynamic library loaded by an Android app. As of 2023-02-09 (around when we started investigating), this issue occurred 526 times in the last 28 days and was one of the main sources of crashes for the OONI Probe Android app.
A typical stack trace obtained from the Google Play console looks like this:
```
backtrace:
#00 pc 0x0000000000089b0c .../lib64/bionic/libc.so (abort+164)
#01 pc 0x00000000013778a4 .../split_config.arm64_v8a.apk (tor_raw_abort_+12)
#02 pc 0x0000000001382150 .../split_config.arm64_v8a.apk (tor_abort_+12)
#03 pc 0x00000000012470a0 .../split_config.arm64_v8a.apk (pubsub_install+120)
#04 pc 0x0000000001247170 .../split_config.arm64_v8a.apk (tor_run_main+136)
```
We investigated this issue and manage to reproduce it initially on OONI Probe Android, then in Linux using our Go code for managing libtor.a, and finally with a pure C test case working under Linux. During this investigating we have never seen the first bootstrap failing. Rather, in some cases it took > 30 repeated bootstraps to observe the abort; in other cases, it occurred within the first 3-10 bootstraps.
I searched in the issue tracker for "pubsub", "pubsub_install", "SIGABRT", and "abort". AFAICT, there is no other open issue discussing this problem, however, I think https://gitlab.torproject.org/tpo/core/tor/-/issues/32729 may be related and ~similar.
### Steps to reproduce:
The following steps allowed me to reproduce the problem on Ubuntu 22.04.2:
1. `git clone https://gitlab.torproject.org/tpo/core/tor`
2. `cd tor`
3. `git checkout tor-0.4.7.13`
4. `git apply 004.diff` where `004.diff` is
```diff
diff --git a/src/lib/pubsub/pubsub_check.c b/src/lib/pubsub/pubsub_check.c
index 99e604d715..a5cc4b7658 100644
--- a/src/lib/pubsub/pubsub_check.c
+++ b/src/lib/pubsub/pubsub_check.c
@@ -25,6 +25,7 @@
#include "lib/malloc/malloc.h"
#include "lib/string/compat_string.h"
+#include <stdio.h>
#include <string.h>
static void pubsub_adjmap_add(pubsub_adjmap_t *map,
@@ -343,21 +344,27 @@ lint_message(const pubsub_adjmap_t *map, message_id_t msg)
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has subscribers, but no publishers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_pub == 0 for %s\n", get_message_id_name(msg));
ok = false;
} else if (n_sub == 0) {
log_warn(LD_MESG|LD_BUG,
"Message \"%s\" has publishers, but no subscribers.",
get_message_id_name(msg));
+ fprintf(stderr, "SBSDEBUG: n_sub == 0 for %s\n", get_message_id_name(msg));
ok = false;
}
/* Check the message graph topology. */
- if (lint_message_graph(map, msg, pub, sub) < 0)
+ if (lint_message_graph(map, msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_graph failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
/* Check whether the messages have the same fields set on them. */
- if (lint_message_consistency(msg, pub, sub) < 0)
+ if (lint_message_consistency(msg, pub, sub) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message_consistency failed for %s\n", get_message_id_name(msg));
ok = false;
+ }
if (!ok) {
/* There was a problem -- let's log all the publishers and subscribers on
@@ -385,6 +392,7 @@ pubsub_adjmap_check(const pubsub_adjmap_t *map)
bool all_ok = true;
for (unsigned i = 0; i < map->n_msgs; ++i) {
if (lint_message(map, i) < 0) {
+ fprintf(stderr, "SBSDEBUG: lint_message failed for %u %s\n", i, get_message_id_name((message_id_t)i));
all_ok = false;
}
}
@@ -401,11 +409,15 @@ pubsub_builder_check(pubsub_builder_t *builder)
pubsub_adjmap_t *map = pubsub_build_adjacency_map(builder->items);
int rv = -1;
- if (!map)
+ if (!map) {
+ fprintf(stderr, "SBSDEBUG: pubsub_build_adjacency_map failed\n");
goto err; // should be impossible
+ }
- if (pubsub_adjmap_check(map) < 0)
+ if (pubsub_adjmap_check(map) < 0) {
+ fprintf(stderr, "SBSDEBUG: pubsub_adjmap_check failed\n");
goto err;
+ }
rv = 0;
err:
```
5. `./autogen.sh`
6. `./configure --disable-asciidoc`
7. `make`
8. `mkdir tmp`
9. `vi tmp/main.c` where `main.c` contains
```C
#include "../src/feature/api/tor_api.h"
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
static void *threadMain(void *ptr) {
int *fdp = (int*)ptr;
(void)sleep(45 /* seconds */);
(void)close(*fdp);
free(fdp);
return NULL;
}
int main() {
for (;;) {
tor_main_configuration_t *config = tor_main_configuration_new();
if (config == NULL) {
exit(1);
}
char *argv[] = {
"tor",
"Log",
"notice stderr",
"DataDirectory",
"./x",
NULL,
};
int argc = 5;
if (tor_main_configuration_set_command_line(config, argc, argv) != 0) {
exit(2);
}
int filedesc = tor_main_configuration_setup_control_socket(config);
if (filedesc < 0) {
exit(3);
}
int *fdp = malloc(sizeof(*fdp));
if (fdp == NULL) {
exit(4);
}
*fdp = filedesc;
pthread_t thread;
if (pthread_create(&thread, NULL, threadMain, /* move */ fdp) != 0) {
exit(5);
}
(void)tor_run_main(config);
if (pthread_join(thread, NULL) != 0) {
exit(6);
}
fprintf(stderr, "********** doing another round\n");
}
}
```
10. `gcc -Wall tmp/main.c -L. -ltor -levent -lcrypto -lssl -lz -lm`
11. `./a.out 2>&1|tee LOG.txt`
The `tmp/main.c` command is a reasonable approximation of what our Go code for running tor does. The main difference is that we start tor with `DisableNetwork` set and re-enable network later. This difference does not seem to have any impact, since we saw aborts in both cases.
We run repeated bootstraps because the OONI Probe Android app loads tor and the Go code as a shared library and calls `tor_run_main` each time we run a OONI experiment that requires tor (typically, `vanilla_tor` and `torsf`).
### What is the current bug behavior?
We can cluster the kind of crashes we observed into two groups.
#### pubsub_adjmap_check failed
This crash has been the most frequent one we observed. With the above patch applied, it generally looks like this:
```
[... omitting logs from several bootstraps ...]
Mar 22 14:07:21.000 [notice] Owning controller connection has closed -- exiting now.
Mar 22 14:07:21.000 [notice] Catching signal TERM, exiting cleanly.
********** doing another round
SBSDEBUG: n_sub == 0 for orconn_state
SBSDEBUG: lint_message failed for 5 orconn_state
SBSDEBUG: n_pub == 0 for orconn_state
SBSDEBUG: lint_message failed for 34 orconn_state
SBSDEBUG: pubsub_adjmap_check failed
[1] 300227 IOT instruction (core dumped) ./a.out 2>&1 |
300228 done tee LOG.txt
```
When running this via Go code, we see a different message before the abort. I think this happens because Go installs its own handler for SIGABRT, while the C code does not install any handler. My understanding is also that "IOT instruction" is related to `SIGIOT`, which seems to be an alias for `SIGABRT` judging from include/linux/signal.h and Glib's bits/signum-generic.h.
My understanding of the above logs is that, somehow, a message is registered twice: once without publishers, and once without subscribers.
It's also important to point out that the message causing failure has not always been `orconn_state`. Based on all the aborts we have examined, it seems that also `orconn_status` could cause failures. For the sake of brevity, I am not going to copy here all the logs we collected, but you can read them along with my thought process when analyzing the bug at https://github.com/ooni/probe/issues/2406.
#### INTERNAL ERROR: Raw assertion failed in Tor 0.4.7.13 at src/app/main/subsysmgr.c:183: 0
This specific error occurred very rarely (2-3 times). It is not clear whether this is the same issue or not, however I think it makes sense to mention it in the same issue, because it occurred when using the above code to investigate pubsub_install aborts.
```
2023/03/21 17:59:13 info tunnel: tor: exec: <internal/libtor> x/tunnel/torsf/tor [...]
BUG: subsystem btrack (at 55) could not connect to publish/subscribe system.
============================================================ T= 1679421553
INTERNAL ERROR: Raw assertion failed in Tor 0.4.7.13 at src/app/main/subsysmgr.c:183: 0
A subsystem couldn't be connected.
./testtorsf(dump_stack_symbols_to_error_fds+0x58)[0xe6df08]
./testtorsf(tor_raw_assertion_failed_msg_+0x97)[0xe6e8d7]
./testtorsf(subsystems_add_pubsub_upto+0x128)[0xe47df8]
./testtorsf(pubsub_install+0x29)[0xdf9c99]
./testtorsf(tor_run_main+0x8a)[0xdf9e2a]
./testtorsf(_cgo_2d785783cadf_Cfunc_tor_run_main+0x1b)[0xdf665b]
./testtorsf[0x500e04]
SIGABRT: abort
PC=0x7fa00f89aa7c m=14 sigcode=18446744073709551610
signal arrived during cgo execution
```
(Because this specific error occurred when using Go code, here you see also the output of Go `SIGABRT` handler.)
The specific assertion that fails in this case is the following:
```C
int
subsystems_add_pubsub_upto(pubsub_builder_t *builder,
int target_level)
{
for (unsigned i = 0; i < n_tor_subsystems; ++i) {
const subsys_fns_t *sys = tor_subsystems[i];
if (!sys->supported)
continue;
if (sys->level > target_level)
break;
if (! sys_status[i].initialized)
continue;
int r = 0;
if (sys->add_pubsub) {
subsys_id_t sysid = get_subsys_id(sys->name);
raw_assert(sysid != ERROR_ID);
pubsub_connector_t *connector;
connector = pubsub_connector_for_subsystem(builder, sysid);
r = sys->add_pubsub(connector);
pubsub_connector_free(connector);
}
if (r < 0) {
fprintf(stderr, "BUG: subsystem %s (at %u) could not connect to "
"publish/subscribe system.", sys->name, sys->level);
raw_assert_unreached_msg("A subsystem couldn't be connected."); // <- HERE
}
}
return 0;
}
```
### What is the expected behavior?
On a very broad level, I think tor should not abort. Because I do not understand very well what is happening, it is difficult to provide a more specific recommendation about what the code should actually do.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
Always 0.4.7.13
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
Android (several versions and devices according to the Google Play console); Android 13 on Pixel 4a arm64 (my phone); Ubuntu 22.04.2 on amd64
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
Tor compiled along with all its dependencies using our build scripts as well as tor compiled from sources with Ubuntu 22.04.2 installation dependencies when reproducing the issue using the above mentioned steps.
### Relevant logs and/or screenshots
I think I already provided representative logs above. The https://github.com/ooni/probe/issues/2406 issue contains all the logs we produced while investigating this issue on our end. It also describes how we progressively narrowed down the problem from an abort in the Android app to an abort using Go code on Linux to the minimal instructions for reproducing the issue that I mentioned above.
On this note, I initially suspected that there was a data race on our end. That assumption was true but the abort continued to occur after I fixed the data race inside Go code. In any case, the possible presence of data races on our end prompted me to bypass our Go code and write C code that could allow reproducing the issue. In one of my final attempts at understanding the issue using just C code, I [patched tor to avoid aborting in case pubsub_install failed](https://github.com/ooni/probe/issues/2406#issuecomment-1479884981), recompiled and run with tsan enabled, [seeing just two pubsub_install failures over 490 runs and no sign of data races](https://github.com/ooni/probe/issues/2406#issuecomment-1480826748).
### Possible fixes
I don't know. Since the data-race theory is not supported by data and unlikely, perhaps it could be that state from previous runs causes issues with the pubsub subsystem that appear for repeated bootstraps? I'll be happy to collaborate and try other debugging strategies.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41685macOS can open links in new tabs when set as default browser (despite remotin...2023-03-21T14:30:03ZrichardmacOS can open links in new tabs when set as default browser (despite remoting being disabled)Haven't had a chance to debug too deeply, but the best guess is that the relevant code path is here:
- https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsMacRemoteServer.mm#34
This code should likely be checking fo...Haven't had a chance to debug too deeply, but the best guess is that the relevant code path is here:
- https://searchfox.org/mozilla-central/source/toolkit/components/remote/nsMacRemoteServer.mm#34
This code should likely be checking for the MOZ_NO_REMOTE env variable or something at that entry point and bailing early if it is present. I'm 90% sure this is an upstream bug so we should uplift once we have a patch.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41681subpixels: high precision measurement fingerprinting2023-11-04T01:04:56Zcypherpunkssubpixels: high precision measurement fingerprintingTor browser only randomise canvas fingerprint but https://www.bromite.org/detect is not randomised at all.Tor browser only randomise canvas fingerprint but https://www.bromite.org/detect is not randomised at all.https://gitlab.torproject.org/tpo/core/arti/-/issues/783Failure to bootstrap due to cache directory problems results in a bad end-use...2023-11-07T12:14:30ZetaFailure to bootstrap due to cache directory problems results in a bad end-user experience### Summary
While working on onionmasq, I encountered a problem with the Arti client failing to bootstrap. After some investigation, this appeared to be related to an issue with the cache. Deleting the cache entirely and restarting fixe...### Summary
While working on onionmasq, I encountered a problem with the Arti client failing to bootstrap. After some investigation, this appeared to be related to an issue with the cache. Deleting the cache entirely and restarting fixed things up, but the end-user experience here was lacking, especially in the context of integrating Arti as a library.
### Steps to reproduce:
1. Something weird happens to the cache directory
2. The Arti client no longer works
### What is the current bug behavior?
I got the following error message on calling `bootstrap()` which was resoundingly unhelpful:
```
onion_tunnel: Failed to bootstrap: tor: cache access problem: Unable to bootstrap a working directory
```
I then realised (given insider knowledge) that I had to format out the causes, and got this:
```
onion_tunnel: Caused by: Unable to bootstrap a working directory
onion_tunnel: Caused by: Bad permissions in cache directory
onion_tunnel: Caused by: File or directory /data/user/0/org.torproject.artitoyvpn/cache/arti-cache/dir_blobs/con_microdesc_sha3-256-339e2da5279de87281cfd59f0b3d0f324a15045a8540e9a71a396d68c3e74d54 not found
```
There are a number of issues here (see below).
### What is the expected behavior?
- Bootstrapping should be able to gracefully deal with cache directory problems, without user intervention
- When embedding Arti, this just looks like the entire thing is irreparably broken, when in fact it's a transient issue that could be easily resolved by clearing the cache
- Users can't always do this themselves if Arti is embedded, nor would they necessarily receive indication that they need to.
- The embedding library can't do it without relying on API-unstable error munging tactics, since no machine-readable API is exposed to ascertain that the cache dir is at fault
- The error should be correctly categorized; this doesn't look like a permissions issue
- The top-level error could possibly be renamed, too: I initially read 'working directory' as 'some place to put scratch files' (i.e. the Git 'working directory'), which was confusing
- (perhaps "Unable to download a Tor network directory" or similar)
- (more opinionated, but) We should strongly consider rethinking the `Error::source` idea
- A 'normal' embedder (who didn't work on the Arti team for a year) would have no idea how to get more information out of the error, and would assume the nondescript `Unable to bootstrap a working directory` line was it
- There's no standard way to print an error's causes ([`std::error::Report`](https://doc.rust-lang.org/std/error/struct.Report.html) is still unstable)
- Even if there was, the user might be transforming the error into an `io::Error` or something, or passing it across an FFI boundary; having to thread the error-cause thing throughout the end-user codebase is just a pointless form of make-work
- This might make sense once the rest of the ecosystem has caught up, but right now it's a really obscure user experience
### Environment
- Version: arti-client 0.8.1 from crates.io, embedded inside onionmasq
- Operating system: Android 13Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41676Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth2024-03-26T20:22:16ZTom Rittertom@ritter.vgSet privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depthSee https://bugzilla.mozilla.org/show_bug.cgi?id=1709867#c21 - we're changing how to spoof the timezone to make way for fine-grained control of that aspect of RFP. On Nightly we _by default_ have changed the behavior of RFP. Tor Browse...See https://bugzilla.mozilla.org/show_bug.cgi?id=1709867#c21 - we're changing how to spoof the timezone to make way for fine-grained control of that aspect of RFP. On Nightly we _by default_ have changed the behavior of RFP. Tor Browser should flip this pref to true to keep the old behavior until we are certain their are no leaks. This will be landing on Nightly soon, so eventually it will ride to Release and affect Android.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41672Home button appears and never goes away if you set a custom home2023-03-10T16:44:49ZhenryHome button appears and never goes away if you set a custom home## Steps to reproduce
1. Go to Preference, Home.
2. Select and fill "Custom URLs..." for the Homepage.
3. Set Homepage back to "About Tor".
## Result
The Home icon appears in the toolbar next to Reload.
## Expect
The Home icon shoul...## Steps to reproduce
1. Go to Preference, Home.
2. Select and fill "Custom URLs..." for the Homepage.
3. Set Homepage back to "About Tor".
## Result
The Home icon appears in the toolbar next to Reload.
## Expect
The Home icon should disappear again when we reset "About Tor", which is the same as the initial state of the browser.
## Cause
~~I think [these lines](https://searchfox.org/mozilla-esr102/rev/8e27e3391ba095a23937fc83d6690cf42cf427ba/browser/modules/HomePage.jsm#331-332) need modifying to include "about:tor".~~
EDIT: This is actually the same behaviour as in firefox. And it may be intentional in case the user manually added the home button or likes it.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41666Request a bridge tells the captcha is wrong in case of 5002023-11-27T09:36:50ZPier Angelo VendrameRequest a bridge tells the captcha is wrong in case of 500I just got some Internal Server Errors while trying to get bridges with Moat.
But the error presented to the user was that the CAPTCHA solution was wrong. I got to know about the real error only by looking at them in the console.
![Scr...I just got some Internal Server Errors while trying to get bridges with Moat.
But the error presented to the user was that the CAPTCHA solution was wrong. I got to know about the real error only by looking at them in the console.
![Screenshot_from_2023-03-06_15-27-00](/uploads/02cdafe7bf65fa3be6c908ceb77188ce/Screenshot_from_2023-03-06_15-27-00.png)
I think we should add a different error (either something generic, or something that says unexpected error, with a placeholder for the real error, so that users can reach out to us and report the error, if that's the case).
Sadly, it seems that there's a [bug in bridgedb](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/119) for which it can get stuck to a broken state (not public, because it has sensible logs, so I don't know the exact details, either).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41665Migrate browser-colors.css colors to whatever updated color theme we actually...2023-08-18T22:23:58ZrichardMigrate browser-colors.css colors to whatever updated color theme we actually want to useFor reference: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-102.8.0esr-12.5-1/browser/themes/shared/browser-colors.css
So this started out as `photon` colors some time back because no-where in Firefox's ...For reference: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-102.8.0esr-12.5-1/browser/themes/shared/browser-colors.css
So this started out as `photon` colors some time back because no-where in Firefox's code (at the time) were all of the `photon` colors fully defined. We added a single canonical file with all the colors you could want and things were good.
Meanwhile, some time has passed and there are now at least 3 different color systems in use in Firefox:
- photon: https://github.com/FirefoxUX/photon-colors/blob/master/photon-colors.css
- protocol: https://protocol.mozilla.org/docs/fundamentals/color.html
- acorn: https://acorn.firefox.com/latest/styles/color.html
So the UX team is always very nice and gives us hex codes to work with when dealing with colors as well as the css vars (eg `--yellow-50` / `#ffa436`). The problem is that (most recently) the color/name combos seem to coincide with the `protocol` colors rather than our existing `photon` colors in css. Obviously hexcode is king but we should all agree on *which* colour system we're using and update `browser-colors.css` to the actual system we are using to avoid confusion in the future.