Since the availability of Private Tabs with Tor was announced I’ve rarely been able to connect using the feature.
When trying to use it, with few exceptions, I have seen the following appear:
“Unable to connect to the TOR network. Brave could not make a connection to the Tor network. Disable Tor to continue private browsing without Tor protection.”
So I disabled TOR and just used a standard Private tab.
However, the result of my last attempt left me wondering whether the error messages may actually have been incorrect.
This time, instead of disabling Tor and continuing in a normal Private tab, I pressed ‘esc’, assuming that would abort. Immediately after that I noticed a message in the URL line informing that a connection was being made and showing the progress toward making the connection (as a percentage).
I then tried to open another Tor tab and this time one opened right away.
Guess I will keep trying this to see whether hitting ‘esc’ has the same result when Tor appears to fail.
Thanks. I haven’t been experiencing that specific issue recently. (I also didn’t “restart the browser” when it happened, I just selected the option for a non-TOR ‘private tab’ & continued using that.)
However, I have experienced TOR private tabs suddenly dying after I’ve been in them.
That is, I see the same error message I had reported seeing when they wouldn’t open, except now it appears at some point after I’m already in the TOR private tab.
Since it’s a private tab that means I ‘lose’ the webpage in whatever state it was in at the time when that happens.
While Brave is running, could you type ps aux|grep brave within the terminal? This will output some information about the Brave process that’s currently running. Could you share the output with us? This will help us narrow down your profiles location. It should look similar to this:
If you look at the --database flag in my example, you’ll notice the /Users/kjozwiak/Library/Application Support/brave/ directory which is the directory where the profile is saved and where you’ll find the logs that @taylor requested above.
There’s two easy ways that you can find the terminal:
1 - Simply search for Terminal using macOS’s search capability
2 - Using macOS’s file menu, click on Go -> Utilities -> Terminal
Thanks. Found it. If the log needs to be copied when the failure actually occurs, let me know & I’ll send it next time the failure occurs.
Aug 13 22:01:55.000 [notice] Tor 0.3.3.8 (git-99f9816efa08ab83) opening new log file.
Aug 13 22:01:55.258 [notice] Tor 0.3.3.8 (git-99f9816efa08ab83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Aug 13 22:01:55.259 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Aug 13 22:01:55.273 [notice] Configuration file “/nonexistent” not present, using reasonable defaults.
Aug 13 22:01:55.279 [notice] Scheduler type KISTLite has been enabled.
Aug 13 22:01:55.279 [notice] Opening Socks listener on 127.0.0.1:9250
Aug 13 22:01:55.280 [notice] Opening Control listener on 127.0.0.1:0
Aug 13 22:01:55.280 [notice] Control listener listening on port 60526.
Aug 13 22:01:55.000 [notice] Bootstrapped 0%: Starting
Aug 13 22:01:56.000 [notice] Starting with guard context “default”
Aug 13 22:01:56.000 [notice] New control connection opened from 127.0.0.1.
Aug 13 22:01:56.000 [notice] Bootstrapped 5%: Connecting to directory server
Aug 13 22:01:57.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Aug 13 22:02:01.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Aug 13 22:02:02.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Aug 13 22:02:04.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Aug 13 22:02:24.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 13 22:02:24.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 3362/6285, and can only build 23% of likely paths. (We have 64% of guards bw, 56% of midpoint bw, and 64% of exit bw = 23% of path bw.)
Aug 13 22:02:24.000 [notice] Bootstrapped 61%: Loading relay descriptors
Aug 13 22:02:39.000 [notice] Bootstrapped 70%: Loading relay descriptors
Aug 13 22:02:39.000 [notice] Bootstrapped 75%: Loading relay descriptors
Aug 13 22:02:39.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 13 22:02:39.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Aug 13 22:02:40.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Aug 13 22:02:40.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 13 22:02:40.000 [notice] Bootstrapped 100%: Done
Aug 14 10:14:27.000 [notice] Your system clock just jumped 34365 seconds forward; assuming established circuits no longer work.
Aug 14 13:33:05.000 [notice] Heartbeat: Tor’s uptime is 5:58 hours, with 0 circuits open. I’ve sent 411 kB and received 1.97 MB.
Aug 14 16:10:42.000 [notice] Your system clock just jumped 2225 seconds forward; assuming established circuits no longer work.
Aug 14 20:09:06.000 [notice] Heartbeat: Tor’s uptime is 11:57 hours, with 0 circuits open. I’ve sent 426 kB and received 2.26 MB.
Aug 14 21:14:42.000 [notice] Your system clock just jumped 2593 seconds forward; assuming established circuits no longer work.
Aug 14 23:04:07.000 [notice] Your system clock just jumped 1303 seconds forward; assuming established circuits no longer work.
Aug 15 07:52:27.000 [notice] Your system clock just jumped 25132 seconds forward; assuming established circuits no longer work.
Aug 15 13:56:13.000 [notice] Your system clock just jumped 15003 seconds forward; assuming established circuits no longer work.
Aug 15 14:18:23.000 [notice] Heartbeat: Tor’s uptime is 17:52 hours, with 0 circuits open. I’ve sent 455 kB and received 2.83 MB.
Aug 15 14:49:30.000 [notice] Your system clock just jumped 231 seconds forward; assuming established circuits no longer work.
Aug 15 19:32:57.000 [notice] Your system clock just jumped 2201 seconds forward; assuming established circuits no longer work.
Aug 15 20:56:59.000 [notice] Heartbeat: Tor’s uptime is 23:50 hours, with 0 circuits open. I’ve sent 475 kB and received 3.18 MB.
Aug 16 08:57:17.000 [notice] Your system clock just jumped 35089 seconds forward; assuming established circuits no longer work.
Aug 16 08:58:33.000 [notice] No circuits are opened. Relaxed timeout for circuit 31 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
Aug 16 12:40:19.000 [notice] Heartbeat: Tor’s uptime is 1 day 5:49 hours, with 0 circuits open. I’ve sent 504 kB and received 3.69 MB.
Aug 16 18:40:19.000 [notice] Heartbeat: Tor’s uptime is 1 day 11:49 hours, with 0 circuits open. I’ve sent 516 kB and received 3.89 MB.
Aug 17 08:44:56.000 [notice] Your system clock just jumped 29669 seconds forward; assuming established circuits no longer work.
Aug 17 08:46:50.000 [notice] Your system clock just jumped 106 seconds forward; assuming established circuits no longer work.
Aug 17 08:53:08.000 [notice] Heartbeat: Tor’s uptime is 1 day 17:45 hours, with 0 circuits open. I’ve sent 537 kB and received 4.34 MB.
Thanks for the info @mk7z! Is your computers date/time off by any chance? Your clock on the machine might be skewed hence the Your system clock just jumped X messages in the log.
Then again, I don’t know… I see these new lines in the log (don’t know what they mean):
Aug 17 12:47:56.000 [notice] Your system clock just jumped 9005 seconds forward; assuming established circuits no longer work.
Aug 17 14:06:09.000 [notice] Your system clock just jumped 637 seconds forward; assuming established circuits no longer work.
If you suspend your machine and resume it a while later, it will seem to software as if the clock jumped the duration the machine was suspended. Tor uses this to infer that existing network connections probably won’t work. And that’s fine – provided the tor daemon notifies Brave when it thinks the network is down or back up, but the notifications have been a little glitchy (e.g., (1), (2), (3)).
The console output from Brave may help to learn what notifications we actually received about the Tor network, in order to determine whether we’re not being notified or we’re just fumbling the notification.
• TOR prefers not to see connections go idle. Presumably that’s related to onion routing wanting to stay active as much as possible, a/o/t being abandoned and later resumed.
• Interruptions won’t necessarily cause a problem (TOR, if run by itself, would just create a new connection), but when BRAVE is in between TOR and the user, glitches can occur.
Is the difference between BRAVE’s native Private Tab and a TOR Private Tab a significant one (meaning considerably greater privacy/security with the latter)?
Also, is the sole advantage of Brave’s TOR Private Tab feature just not having to run TOR as a separate app?
If Brave gets stuck saying Tor is unavailable when it is available, then it’s a bug in Brave or the tor daemon.
That’s what I’m trying to ascertain here: Is it a bug in Brave’s handling of notifications it does receive from the tor daemon, or is the tor daemon failing to notice or to notify us that the network is back?
With standard private tabs, your ISP or network administrator can see what web sites you’re browsing, and web sites can still tell what your IP address is which they can either (a) use to distinguish you from other people, or (b) use with other characteristics like cookies to track you from location to location.
Private tabs with Tor thwart all this by routing your connections through the Tor network.
The Tor Browser is another web browser. It doesn’t aggressively block ads like Brave does, and it doesn’t support Brave Payments for anonymized consensual micropayments to publishers. But the Tor Browser team have also put most of their engineering resources toward plugging anonymity leaks, whereas at Brave we have spread our resources among various other endeavors, so the Tor Browser inspires more confidence in the anonymity it provides against a dedicated adversary.
Both the Tor Browser, and private tabs with Tor in Brave, use the Tor network via an auxiliary program called the tor daemon. In both cases, management of the tor daemon happens behind the scenes. Whether you choose to use the Tor Browser or private tabs in Brave depends on what features you want, and what level of confidence you want against an adversary seeking to deanonymize you.
If Brave gets stuck saying Tor is unavailable when it is available, then it’s a bug in Brave or the tor daemon.
Been trying to test that but it hasn’t happened again.
Whether you choose to use the Tor Browser or private tabs in Brave depends on what features you want, and what level of confidence you want against an adversary seeking to deanonymize you.
I’ve used TOR in a limited way, for anonymity/privacy. It’s useless if/when you need speed, and many websites reject it. Google won’t even let you search without running the CAPTCHA gauntlet, which in my experience is never-ending (I assume intentionally).
I left a Private Tab with Tor tab open without using it (for a long time – many hours).
When I came back to it “Unable to connect” displayed.
Is that normal behavior or abnormal?
TOR (the TOR browser) sometimes disconnects me when I haven’t used it for a while, so I’m assuming it’s to be expected.
However, with TOR tab in BRAVE, so far I’ve never found that “Retry connection” re-establishes a connection. And since once the dialog box appears a selection has to be made, I’m obliged to choose “Disable Tor.”
If you lost your connection to the internet, that might happen. But if that happens when you’re still connected to the internet and there have been no hiccups in connectivity, that shouldn’t happen — i.e., sounds like a bug.
The button is supposed to work. If you can share your tor.log at the time that it happens (note that each time you hit ‘Retry connection’, the log will be cleared and restarted), and the console output from Brave, we may be able to diagnose it. It may take a few seconds for Tor to come back after you hit ‘Retry connection’, FYI.
(That said, our resources for fixing bugs in Brave before Brave 1.0 are a little limited right now.)
It is unfortunate that some web sites insist on tracking their users across the internet and deny users anonymity. The Google captcha is why we use DuckDuckGo by default in private tabs with Tor. If you are willing to identify yourself, you could try contacting the operators of the web site and ask them to allow people to browse their site anonymously.
Many sites are behind Cloudflare with a default configuration that issues a captcha to all Tor users, with no intentional decision by the operators. You might give them links about how to change the Cloudflare configuration:
If you lost your connection to the internet, that might happen. But if that happens when you’re still connected to the internet and there have been no hiccups in connectivity, that shouldn’t happen — i.e., sounds like a bug.
As far as I know I was still connected to the Internet, but hard to say about hiccups since I was away from the computer.
The button is supposed to work. If you can share your tor.log at the time that it happens (note that each time you hit ‘Retry connection’, the log will be cleared and restarted), and the console output from Brave, we may be able to diagnose it. It may take a few seconds for Tor to come back after you hit ‘Retry connection’, FYI.
Should I copy the tor.log as soon as I see the ‘failed TOR connection’ dialog box?
Also, is the console output just a matter of opening the Console app and copying what’s then on-screen there?
I’ll watch ‘Retry connection’ more closely. Reporting failure to connect has occurred many times today, but this thread started with reports of failure that were occurring even though a connection was made, so I’ll check whether that’s still what’s actually happening.
The ‘error message’ (“Unable to connect to the TOR network. Brave could not make a connection to the Tor network. Disable Tor to continue private browsing without Tor protection.”) appears frequently, but not always.
In nearly all instances when it does occur, however, a successful TOR connection is in fact established, either after just waiting or after clicking ‘Retry.’
