Because the ‘New Identity’ button, but also closing Tor Browser, closes all tabs at once, websites working together and closed source analytics libraries which may be present on a lot of websites, that track events or connection status, could correlate these events that happen at the same time. Like that they could link these individual website sessions to a single browser session after the user has closed their browser or switched to a new identity.
If the current behavior is indeed troublesome, would it be a good idea to add a random delay for every first-party domain and its tabs to be closed? I assume that many users would want pressing the close button in the title bar to be instant, but maybe the Quit option and New Identity feature could benefit from an extra measure like this.
1 Like
Hi!
The first step of new identity is disabling JS, so this should not happen. However, things might not work as expected (e.g., there are some comments about iframes: the code has been refactored to appear more modern about one year ago, but its functionalities haven’t been changed).
Do you think it could still happen? Do you have a PoC to show this, or would you like to create one?
Thanks!
2 Likes
It’s good to hear JavaScript is disabled when then New Identity feature is used. If this means no beacon or similar events can fire on a tab close then that seems like it already reduces the possibilities. It could still happen if websites aggressively send ‘pings’ in which case not seeing these anymore indicates the tab has been closed. Since I think disabling JavaScript prevents these methods entirely, any potential mitigations wouldn’t need to happen if Tor Browser is set to Safest, but there’s also an argument for just using Safest in the first place if you want to be protected against this.
I was also thinking about HTTP being Keep-Alive by default, but I’m not familiar enough with the inner workings of Tor Browser to know whether the browser sends a ‘close TCP connection’ packet when tabs are closed, and whether Tor Browser itself has a timeout on keeping TCP connections active. I assume Tor Browser does send the close packet, since that is part of the TCP spec. If this happens, web server software could be made or configured to keep the connections alive for very long and log these client close packets. In that case, I suppose that not sending the connection close packet is enough to thwart this method, though it probably doesn’t comply with the TCP spec, although I expect many web servers to drop inactive connections after a while anyway regardless of whether the clients close them. But a tab close delay would of course be compliant regardless.
What do you think? I have no PoC, but I would be willing to create one if necessary.
I think that we can hardly do something to protect users from this kind of threat.
Actually, the problem isn’t only relevant to new identity, but to close the browser normally, too 
.
Also, WebSocket could be used, too, if one has JS enabled.
Tor Browser is based on Firefox, IIRC we don’t do anything to change these behaviors. Also, Firefox provides a few pages to debug networking, you could try to use these ones.
I know almost nothing about the network part of the codebase, so I can’t help you. Sorry.
The delay idea would be one potential option.
I mentioned this in my first post too, this is indeed a bit of a UX issue. People would probably want the close button in the title bar to be instant, thought New Identity or the Quit option in the hamburger menu could benefit from this. Or maybe a new ‘Safe Quit’ option in that menu, or something.
I guess it’s more a question of: does the severity of this warrant a somewhat annoying UX change? And there might still be a better way of mitigating it that I didn’t think of yet. I’m not even sure on what the severity of this is yet. For all I know this could be a very potent cross-site session correlation method, or it could be essentially worthless to adversaries.