Tor Browser New Identity differs from restarting Tor Browser in Whonix

I stand corrected. :slight_smile:

I am wondering/about to create a Tor Browser bug report, make closing and restart of Tor Browser as good as New Identity. Any input?

1 Like


make closing and restart of Tor Browser as good as New Identity

When using Tor Browser New Identity, it sends signal newnym and restarts the browser.

Manually terminating the browser and restarting it however does not result in sending signal newnym.

I would suggest to make make the shutdown / restart of Tor Browser as similar as it can get. I.e. when Tor Browser gets closed or started, why not send signal newnym?

Are there any other differences between Tor Browser New Identity and Tor Browser restart that could be sorted out?


This is Whonix specific though. With stock TBB the bundled Tor instance shutdown with the browser and so a new circuit is built on a restart. Not so with Whonix because it’s a system Tor daemon on the GW that keeps running.

I think this is a very important failsafe feature - but iyou should mention its for designs like Whonix.


It’s a very good point!

Ticket posted:

1 Like

Indeed a good point. I see now why I thought this is the case. I even remember that it was recommended to restart tor browser rather than click the new id button but that was a long time ago.

Otherwise thanks for the responses.
entr0py, you are saying that actually only the periodical change of circuit would be able to stop linking my tor profile, given the second reason is not correct? So what if I changed ‘identities’ withing 10 minutes, then the identities are linked?
What I’m asking is - Does restarting the tor browser in whonix do exactly the same thing as opening a new tab in a current session i.e. nothing? If the answer is yes, then theoretically my profiles should be linked, right?

Here’s what I think you’re asking:

Within a 10 minute timeframe,

  1. You connected to gmail.com as Joe.
  2. You restarted Tor Browser.
  3. You connected to gmail.com as Mary.

In this case, both Joe and Mary would have connected to gmail.com over the same Tor circuit.

Restarting Tor Browser deleted all application-level data so, for example, Joe and Mary would have had different cookies.

You can watch this process yourself by installing onioncircuits. It’s a great tool to learn about stream isolation.

This is a very concerning issue. I can imagine someone creating a bitcoin wallet at blockchain.info. Then, transferring bitcoins from wallet1 to wallet2 via some anonymizing service. Then, closing Tor Browser and logging into wallet2. While the bitcoin trail might have been obfuscated, both wallets would have been accessed from the same source.

[This example is complicated because blockchain.info doesn’t allow clearnet connections from Tor exit nodes. But I confirmed that the connection to the hidden service occurs over the same Tor circuit as well. However, I don’t know enough about hidden services to know what identifying metadata can be collected regarding the source of the connection - meaning IP addresses aren’t used, but can the relay be identified as being the same by it’s fingerprint?]


Just to add, Whonix has always advised against using the same Tor Browser for multiple identities:


But the more failsafes, the better.


Yes, this is what I was asking. I assume it applies if joe logs into a different website than marry within those 10 minutes? Would this be enough to conclude that joe and marry are the same person?
Can this analysys be done only in real time or can it be backtracked?
Say if an adversary decided to look into marry’s activity now?

As a stopgap Whonix’s tb-starter /usr/bin/torbrowser could request newnym before starting Tor Browser and/or after Tor Browser has terminated. Does automation of that sound sane or can you imagine any ill effects?


https://phabricator.whonix.org/T567 is somewhat similar / related.

1 Like

No, it doesn’t. That’s why I specifically mentioned gmail.com. You asked the following earlier:

If “second reason” is referring to:

why would that not be correct? The only way that Tor Browser would not isolate different websites is if you used some type of proxy after Tor, in which case, all of your browsing would occur over a single circuit until a relay died.

The fact that 2 connections originate from the same Tor exit node within a short timeframe would constitute some circumstantial evidence. People are free to draw whatever conclusions they want.

Depends on logging.

1 Like

Can’t imagine any situation in which user would want to reuse circuits from a prior Tor Browser session - reauthentication with websites would be required anyway because cookies are destroyed.

Probably safer to issue newnym on termination, just because I don’t understand how SOCKSAuth is constructed and whether or not it’s possible for another application to issue the same SOCKSAuth.

1 Like

Thanks for the replies and patience, entr0py. I think I’m getting there.
As you say, you think the first-party domain is incorrect because it does show the same IP for every checked tab within one session. I have no idea what the SOCKSAuth does, but if the tabs use the same IP, how does that help keeping profiles apart?

And why is it different if it’s not logging into the the same website?
If joe logs into say an onion website, then restarts Tor Browser and logs into a clearnet website as marry, then both should be connected the same way as if they would have logged in one website?

Can you please elaborate on what you mean by “Depends on logging”? The logs that the websites keep or something else?

I do appreciate this.

No problem. We have found the source of the confusion!

I never said or implied this. What I said was that every checked tab showed the same IP for the same website. This proved that Tor Browser doesn’t automatically create a new circuit for every tab.

In fact, Tor Browser creates a new circuit for every new first-party base domain URL. That means mail.google.com and accounts.google.com will stream over the same circuit but mail.facebook.com will generate a new circuit. All the additional URLs that are generated from the initial request will also stream over the respective initial (first-party) circuit. This is Tor Browser’s default behavior - like unused circuits dying at 10 mins - it has nothing to do with restarting the browser or clicking “New Identity”. (Also don’t worry about SOCKSAuth. That’s just the mechanism that Tor Browser uses to differentiate websites).

Whatever logs websites keep, whatever logs ISPs keep, whatever logs the NSA keeps… Basically, I don’t know.

1 Like

@winibub To be absolutely certain that activities from your last session are not detectable in your new one - you should create a snapshot of a freshly installed GW after Tor is initially started up and rollback to it along with your WS clean state.

Want to run multi-WSs same time? You must have a separate GW assigned for every WS. Be sure to apply the advice above here too.


After restarting Tor Browser, connections should be stream isolated. Even to same domain. This is because Tor Browser sets a socks user name that contains a random string per first level domain the is different after a browser restart.

We are discussing multiple vs single gateway here at the moment btw:


My caution is related to worsening the fingerprint of any other application that may be running in parallel while sending newnym.

Learning the socks username can be done by running torbutton in debug mode. Just now documented here:

The socks username consists of the the first level domain name as well as a random string. Example:

torproject.org:<random string >

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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]