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.
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?
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
The Design and Implementation of the Tor Browser [DRAFT]
Issue Tracker:
Tor Browser should set SOCKS username for a request based on first party domain (#3455) · Issues · Legacy / Trac · GitLab
Code:
The Tor Project / Organization · GitLab
Now, I’d like to continue my rant 
Am I the only schmuck running 6.0.5 around here?
Seems to be a bug since feature has been a part of TBB since 4.5-stable.
Release notes: Tor Browser 4.5 is released | The Tor Project
Update Torbutton to 1.9.2.2. Changes since 1.7.0.2 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:
torbutton:
torbrowser:
Three options.
+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: TBB 6.0.5 DomainIsolator does not generate unique nonce paswords for socksauth (#20623) · Issues · Legacy / Trac · GitLab
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:
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