Provide "New Identity" option that uses session restore
People routinely request a New Identity option that doesn't close all of their tabs. Unfortunately, this is not really possible to implement while still clearing all of the tracking-related browser state.
However, what we can do is store a memory-only instance of the session restore data prior to New Identity and then restore it afterwords. This might be rather klunky in terms of responsiveness and load delay, but it would give people who really don't want to lose their current tabs a way to still keep them without quite so much tracking data persisting across the "New Identity" invocation.
Activity
People routinely request a New Identity option that doesn't close all of their tabs.
I think, many asks such so to change circuit. No need to clear anything for this, need yet one button with different name that will close connections per tab(s) and will send NEWNYM signal. Such enhancement very actual for TBB without Vidalia.
Replying to mikeperry:
People routinely request a New Identity option that doesn't close all of their tabs. Unfortunately, this is not really possible to implement while still clearing all of the tracking-related browser state.
What blockers do you have in mind if one tries to take that road?
-
Replying to gk:
Replying to mikeperry:
People routinely request a New Identity option that doesn't close all of their tabs. Unfortunately, this is not really possible to implement while still clearing all of the tracking-related browser state.
What blockers do you have in mind if one tries to take that road?
After thinking a while about it I suppose I should be more precise with my question: What issues do you have in mind that are solvable by the session restore approach but not by leaving tabs open after clearing tracking-related browser state?
Replying to gk:
Replying to gk:
Replying to mikeperry:
People routinely request a New Identity option that doesn't close all of their tabs. Unfortunately, this is not really possible to implement while still clearing all of the tracking-related browser state.
What blockers do you have in mind if one tries to take that road?
After thinking a while about it I suppose I should be more precise with my question: What issues do you have in mind that are solvable by the session restore approach but not by leaving tabs open after clearing tracking-related browser state?
The session restore approach defends against invisible tracking. If we left tabs live and fully open while clearing the cache, cookies, HTTP auth, etc, then javascript and other dynamic elements (CSS) are still present and still have access to any dynamically generated identifiers, and these identifiers will easily find their way back into the cache, and have a number of other vectors to embed persistent tracking identifiers that are invisible to the user.
In theory, adversaries could encode identifiers in the first party urls stored in the session store. However, if we only allow url bar urls to be stored (and no cache, DOM storage, etc), then such tracking is at least limited to what is visible, and only to first party tracking (and hopefully that will be rare, due to its visibility and cumbersome nature).
If you implement this feature then please don't call it "new identity".
It should be clear to users that simply creating a new circuit via NEWNYM without clearing session information will allow personally identifying information to persist.
I suspect what users really want is an option to create a circuit with a different exit node (IP address), rather than a new circuit per se. Sometimes just issuing NEWNYM can result in a new circuit that uses the same exit node as before.
Replying to mikeperry:
In theory, adversaries could encode identifiers in the first party urls stored in the session store.
"In theory"? It's very common to put user identifiers in URLs (session IDs a la PHPSESSIONID, user names, user ids etc.).
Restoring these after "new identity" would immediately link the old session/identity to the new one.
-
Replying to mikeperry:
Replying to gk:
Replying to gk:
Replying to mikeperry:
People routinely request a New Identity option that doesn't close all of their tabs. Unfortunately, this is not really possible to implement while still clearing all of the tracking-related browser state.
What blockers do you have in mind if one tries to take that road?
After thinking a while about it I suppose I should be more precise with my question: What issues do you have in mind that are solvable by the session restore approach but not by leaving tabs open after clearing tracking-related browser state?
The session restore approach defends against invisible tracking. If we left tabs live and fully open while clearing the cache, cookies, HTTP auth, etc, then javascript and other dynamic elements (CSS) are still present and still have access to any dynamically generated identifiers, and these identifiers will easily find their way back into the cache, and have a number of other vectors to embed persistent tracking identifiers that are invisible to the user.
Indeed. What I had in mind was something which avoids that but keeps the tabs with the visited domains/web pages open (or better: reloads them?) (without any identifiers in them). The user would then be kicked out of, say, a forum but would not loose the tab with the landing page loaded or the news in another one. Not sure if that is even more confusing to users though (they might ask "Hey, why am I not logged into Google anymore but still on its webpage??") but it sounds reasonable to me as "New Identity" means you can't be logged into a forum anymore after clicking on that button but should not have a huge impact on your open news sites.
In theory, adversaries could encode identifiers in the first party urls stored in the session store. However, if we only allow url bar urls to be stored (and no cache, DOM storage, etc), then such tracking is at least limited to what is visible, and only to first party tracking (and hopefully that will be rare, due to its visibility and cumbersome nature).
Hmm... I am not happy with that. The spec says "All linkable identifiers and browser state MUST be cleared by this feature." Implementing what you have in mind would be a regression in this regard, then, compared to today. While the spec could be changed to something less strict I'd be especially cautious here as this feature is necessary to avoid tracking which is usually hard to avoid. What about the idea above (regardless whether it is implemented via session restore or something like "keep the tabs open but reload the web pages without identifiers in them")?
-
Well, if any URL contains something sensitive, because of the lazy-loading introduced in the session restore in FF24, that tab can be closed and new identity could be run again.
But gk might be right, still. It's rather crazy to expect anyone to actually do that. I'm going to leave this ticket open as an idea to mull over, but I don't think we should rush into implementing this.
Hi all, I made a patch for this issue and #9906 (moved) that creates an in-memory array of the open tabs if the user chooses to after clicking on New Identity, and then restores these tabs after New Identity. Please review: https://github.com/diracdeltas/torbutton/tree/fix/9906
-Yan
I just opened a ticket, found about this one and closed it right away (#10766 (closed)). However, for the record, I'm going to copy the description here:
There are times that I really need to get a new circuit but don't want/need to do the "new identity" (e.g: need the open tabs and current session cookies). Every time I get stuck in this situation I wish we had a NEWNYM or New Circuit button on torbutton, something like what "new identity" in Vidalia used to do.
And I thought when a user clicks on this button should get warned and explained about the differences between "New Identity" and "New Circuit". With a "Don't show me again" checkbox of course! :)
-
Replying to mrphs:
I just opened a ticket, found about this one and closed it right away (#10766 (closed)).
You probably want #9442 (moved), though.
-
Replying to zyan:
Hi all, I made a patch for this issue and #9906 (moved) that creates an in-memory array of the open tabs if the user chooses to after clicking on New Identity, and then restores these tabs after New Identity. Please review: https://github.com/diracdeltas/torbutton/tree/fix/9906
I replied to Yan in private email, but for the record, we want to improve this to preserve window layout. It is also my estimation that these URLs should not auto-load when restored, but that could also be an option we provide.
Please, close this as INVALID, because new (and clear!) identity (session, in fact) means no traces of the current session. It is impossible to remove all encrypted (sometimes) traces from the current session to transit this "washed" result to the new one. Users must be warned when clicking "New Identity" that it is intended behavior (to stop mailing you). A brief description might be added in a dialog window, and a recommendation to Bookmark All Tabs (Ctrl-Shift-D) as a solution, but with warning that users must inspect saved URLs thoroughly because of the security risk. To shoot in leg users can always use unsafe "save/restore session" add-ons.
Trac:
Sponsor: N/A to N/A
Severity: N/A to Normalmentioned in issue #10766 (closed)
mentioned in issue #11520 (closed)
mentioned in issue #16132 (moved)
mentioned in issue #18382 (moved)
mentioned in issue #18382 (moved)
mentioned in issue #18382 (moved)
mentioned in issue tpo/applications/tor-browser#16132 (closed)
