Opened 4 years ago

Closed 21 months ago

#10400 closed enhancement (wontfix)

Provide "New Identity" option that uses session restore

Reported by: mikeperry Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-newnym, tbb-torbutton
Cc: gk, intrigeri Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (21)

comment:1 Changed 4 years ago by cypherpunks

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.

comment:2 Changed 4 years ago by gk

Cc: gk added

comment:3 in reply to:  description ; Changed 4 years ago by 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?

comment:4 in reply to:  3 ; Changed 4 years ago by 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?

comment:5 Changed 4 years ago by arma

Keywords: tbb-newnym added

comment:6 Changed 4 years ago by Butcer

why not, if tor is supposed to be usuabul this is a feature you must have, else tor will go down and be yet another dead open source program

comment:7 in reply to:  4 ; Changed 4 years ago by 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.

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).

comment:8 Changed 4 years ago by cypherpunks

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.

comment:9 in reply to:  7 Changed 4 years ago by cypherpunks

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.

comment:10 in reply to:  7 Changed 4 years ago by gk

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")?

comment:11 Changed 4 years ago by gk

FWIW getting rid of identifiers in the URL might be pretty hard depending on how they are encoded. But that does not imply that we should make our requirements as outlined in the design document less strict, though.

comment:12 Changed 4 years ago by mikeperry

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.

comment:13 Changed 4 years ago by zyan

Hi all, I made a patch for this issue and #9906 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

comment:14 Changed 4 years ago by mrphs

I just opened a ticket, found about this one and closed it right away (#10766). 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! :)


Last edited 4 years ago by mrphs (previous) (diff)

comment:15 in reply to:  14 Changed 4 years ago by gk

Replying to mrphs:

I just opened a ticket, found about this one and closed it right away (#10766).

You probably want #9442, though.

comment:16 in reply to:  13 Changed 4 years ago by mikeperry

Replying to zyan:

Hi all, I made a patch for this issue and #9906 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.

comment:17 Changed 3 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added
Owner: changed from mikeperry to tbb-team

comment:18 Changed 3 years ago by intrigeri

Cc: intrigeri added

comment:19 Changed 21 months ago by bugzilla

Severity: Normal

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.

comment:20 Changed 21 months ago by mrphs

I think having the "new tor circuit for this site" option has fixed this.

Last edited 21 months ago by mrphs (previous) (diff)

comment:21 Changed 21 months ago by gk

Resolution: wontfix
Status: newclosed

I tend to agree. I don't like the idea of introducing yet another option with similar functionality where the user needs to get properly educared etc. Closing this as WONTFIX.

Note: See TracTickets for help on using tickets.