Rusty Bird (c7092a88) at 26 Mar 17:45
Rusty Bird (c7092a88) at 23 Mar 11:54
Bug 41110: Avoid Fontconfig warning about "ambiguous path"
$ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a merge request that adds prefix="cwd"
.
You're right, I had tested this with TOR_SKIP_LAUNCH=1
set in the environment.
With that variable unset, I too can reproduce about:tor
being loaded after about:torconnect
has connected.
- Restart TB.
Do you mean using the New Identity
button / menu item / hotkey? In that case it would be a duplicate of #42172, because selecting Blank Page technically means setting the homepage to chrome://browser/content/blanktab.html
For a full restart - quitting Tor Browser and launching it again - I can't reproduce this.
Ah, thanks for unrestricting the issue.
Would it make sense to allow some browser.startup.homepage
values? In particular
chrome://browser/content/blanktab.html
(the value of Homepage and new windows: Blank Page
in Settings)file://
URLs too, for WhonixMaybe it's intentional? I'm not sure because c62d3405 is referring to a bug #41765 (closed) that doesn't seem to exist
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.
TOR_DEFAULT_HOMEPAGE='https://example.com/' ./start-tor-browser
New Identity
Linux (x86_64)
If sending NEWNYM is really just a remnant
I can answer my own and cypherpunks's question now: It's not, at least not until TB moves to arti.
Here's the main part of tor's NEWNYM implementation:
circuit_mark_all_dirty_circs_as_unusable();
addressmap_clear_transient();
hs_client_purge_state();
purge_vanguards_lite();
addressmap_clear_transient()
for DNS might not be relevant in a TB context.
But hs_client_purge_state()
purges remotely detectable state for the onion-service client. This state isn't circuit isolated (so nonce rotation doesn't invalidate it), see tpo/core/tor#15938 (closed) which was labeled Close in favor of Arti
.
Looks like mainline TB can't get rid of attempting NEWNYM entirely yet. :(
Happy to confirm that this patch (applied to the omni.ja
of 13.0a6) fixes #42160 (closed) for me if TOR_PROVIDER=none
is set. Thank you!
If sending NEWNYM is really just a remnant (from before the development of nonce rotation on New Identity) and no longer benefits the Tor Browser instance that's doing it, then it even seems like system-wide footgun:
Consider e.g. a second Tor Browser instance running in the background connected the same tor, and this second TB has tabs open that are first-party isolated from each other and are polling let's say the same ad network with new TCP connections every few seconds, keeping their respective tab circuits alive due to KeepAliveIsolateSOCKSAuth
. Now the first TB sends NEWNYM, expiring all of the second TB's circuits at once, which correlates (in time) the new circuits of the second TB's tabs when they poll again. Repeat that a couple of times - maybe the user continues browsing on the first TB instance, hitting New Identity every once in a while - and it's a pretty solid correlation, no?
(Hence I also think Whonix Gateway's control port filter should probably drop NEWNYM requests from Workstations. Do any of the Whonix people have an account here to @? @adrelanos)
Edit: Oops, sorry for breaking the thread.
Yes, but I mean that for "normal" connections from Firefox to www.example.com, if socks_remote_dns
is enabled Firefox isn't asking tor to first resolve the hostname so that Firefox then can connect to the IP address. Rather it's telling tor to tell the exit node to connect to www.example.com directly, with DNS handled by the exit node. The tor daemon doesn't ever learn the IP address in this scenario.
In contrast, for transparent torification with TransPort
there really are separate resolve and connect steps (unless AutomapHostsSuffixes .
is configured in torrc), and the tor daemon does learn the IP address. I think the control port spec might be referring to the DNS cache in that context?
That is, unless I'm missing some not-so-"normal" connections where Firefox actually does DNS requests regardless of socks_remote_dns
being enabled.
Having an environment variable to tell Tor Browser that there's intentionally no control port available would be useful for #41708 and maybe #42160 (closed)
In 13.0a6 for Linux, if TOR_SKIP_LAUNCH=1
is set and no control port is available (which may be intentional) then Tor Browser will ignore TOR_SOCKS_PORT
and TOR_SOCKS_HOST
, instead of using them to populate the network.proxy.socks_port
and network.proxy.socks
prefs like in 12.x and before.
For example TOR_SKIP_LAUNCH=1 TOR_SOCKS_HOST=10.152.152.10 ./start-tor-browser
to point Tor Browser to an external tor
daemon does not work.
Linux (x86_64)
But how would a local DNS cache come into play with network.proxy.socks_remote_dns
? Are there still some things that Firefox does DNS queries for (even though that pref is enabled), instead of just connecting to a hostname?
Updated screenshot (Tor Browser 10.0.16 on Linux):
Why not finally toggle this very nice insecure_connection_text
pref? It seems to have fallen through the cracks for years now. But it can be enabled totally independent of ...
I've used it with stable Tor Browser for well over a year without any issues. Best of all, it's really noticeable.