Tor Browser New Identity differs from restarting Tor Browser in Whonix

I’ve been listening in on that convo. One GW per hidden service is reasonable but for client use, it’s a usability nightmare. And how would it be implemented to cover the dispVM use-case?

Just tested using your instructions in a Whonix-WS dispVM. My <random string> is always 0.

1 Like

That is strange! To make sure we are on the same side…

For me, I see:

Torbutton INFO: tor SOCKS: https://check.torproject.org/ via torproject.org:xxx

vs after restart

Torbutton INFO: tor SOCKS: https://check.torproject.org/ via torproject.org:yyy

For you it is always 0?

1 Like

Finally figured it out! The culprit is Tor Browser VERSION.

I tested using a dispVM with a fresh installation of Tor Browser, a regular appVM, and a Virtualbox VM - all of them running TB 6.0.5. They all showed domain:0 for socks user:pass. Even after clicking New Identity, the password continued to be 0.

6.5a3 and 6.5a3-hardened both showed random strings for the password, which changed after pressing New Identity. Closing and restarting the browser does indeed generate a new password - so the submitted ticket should be updated to differentiate between Tor Browser versions.

I can’t tell if this is a bug with 6.0.5 or a feature of the alpha browsers. I can’t find my way around trac.torproject so if someone wants to take a look, here are some relevant links:

Tor Browser design doc: 4.5. Cross-Origin Identifier Unlinkability
Issue Tracker:

Now, I’d like to continue my rant :slight_smile: Am I the only schmuck running 6.0.5 around here?

1 Like

Seems to be a bug since feature has been a part of TBB since 4.5-stable.
Release notes: https://blog.torproject.org/blog/tor-browser-45-released

Update Torbutton to Changes since in 4.0.8:

  • Bug 3455: Use SOCKS user+pass to isolate all requests from the same url domain

trac.torproject is really non-newb friendly (keeps idiots like me away so guess that offers some benefits…) I couldn’t find any existing tickets mentioning this “bug” but ymmv:



1 Like

Three options.

  • ask on Tor IRC
  • ask on tor-talk
  • report a new bug (I guess you effort well justifies the risk of adding a duplicate)

+1 as it will get noticed at some point. On IRC people can be unavailable. On tor-talk no one that matters reads there anymore.

filed against tbb: https://trac.torproject.org/projects/tor/ticket/20623

Go figure. I just got around to subscribing couple days ago.

EDIT: Actually, I’m thinking that this might be expected behavior. I think the original design of TBB 4.5 was to have a socks password of 0 that incremented for each new circuit. The random passwords may be a new alpha feature. If this is the case, then the previous submitted ticket #20479 is still relevant for TBB 6.0.5 + system Tor.

Now that we all do understand random socks user names better… And imagine 20623 was fixed or 6.5 was blessed the stable version already… What do you think about my original above question in this posting?

Just updated 20623. Bug is indeed invalid IIUC.

20479 will persist as an issue (only for stable TBB - alpha should be unaffected) unless:

  1. Whonix tb-starter issues newnym (before or after) or
  2. Random password feature is backported to TBB-stable by TBB

Just now, while testing Android, I see that connections to Google Cloud Messaging (port 5228) persist for 30? minutes after the Android VM is shut down. (I don’t even understand how that’s possible unless somehow Whonix-Gateway is keeping the connection alive in place of the Android VM.) I wonder if there are scenarios where connections can stay alive after TBB shutdown.

If yes, then newnym should happen after TBB close. The other thing that New Identity does is “close all remaining HTTP keep-alive connections”. Not sure if that’s easy to add.

Random socks user name was introduced later indeed:


Newnym before Tor Browser gets started and after it got closed. This is because you can never be sure the send newnym on close will work (could be killed for some reason). This is why I am considering both to make this more reliable.

Since that is http, there is nothing Whonix need to do about this. That should happen inside the browser.

Please open a separate thread for this and add where/how you can see this.

I’m having this problem too - seems to be a persistent error for me.

The only variable I can identify was an update to my templateVMs

As of TBB-6.5, this should now apply to TBB-stable and not only alpha. https://blog.torproject.org/blog/tor-browser-65-released:

Bug 19206: Avoid SOCKS auth and NEWNYM collisions when sharing a tor client

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]