New Identity Button

One of these days it might be nice to add a "New Identity" button to Torbutton to instruct vidalia or the control port itself to choose a new path, in addition to clearing Tor cache+cookies. This may or may not depend on a "Tor Status" check to verify that the tor process is in fact running. Unfortunately, there are lots of usability issues with control port auth, multiple confusing controls and statues, exactly which cookies get cleared, etc that need to be considered.

[Automatically added by flyspray2trac: Operating System: All]

changed milestone to %TorBrowserBundle 2.2.x-stable

added MikePerryIteration20110814 actualpoints::8 component::torbrowserbutton milestone::TorBrowserBundle 2.2.x-stable owner::mikeperry points::8 priority::high resolution::fixed status::closed type::enhancement version::1.1 labels

"new identity" should probably be broken into two separate concerns:

a) "new circuit" - Send a NEWNYM signal to Tor. Useful for bailing out of a set of unresponsive circuits

b) "new identity" - all the browser cleanup to separate your activities on the old set of circuits from your activities on the new set of circuits

(a) is easy. (b) is could get complicated.

a)what if vidalia has already authenticated to tor. I think doing it through vidalia might be a easier solution :). and listen on a local port for vidalia to connect back and report tor status.

b) IMHO just restarting the browser ("destroy old identity") would be ok - once and for all. haha.

Trac:
Username: xtoaster

We probably also want to support Multiple Identities at some point. That would be an outgrowth of this and the fine-grained cookie control code.

It might also be a good idea to put the New Identity button on a timer a-la BetterPrivacy, to address the accumulation of browsing state for long-lived tor-sessions.

See also bug #940 (moved) and #637 (closed): https://bugs.torproject.org/flyspray/index.php?do=details&id=940 https://bugs.torproject.org/flyspray/index.php?do=details&id=637

Bug #1579 (closed) is a dup of this bug. Providing "New Identity" on a timer would give people a way to be safer from cookie and cache identifiers if they use Tor continuously, but would still like to have cookies and cache enabled. This would especially be handy if we could protect certain cookies from deletion from the timer, a-la #637 (closed).

Trac:
Parent: N/A to N/A
Description: One of these days it might be nice to add a "New Identity" button to Torbutton to instruct vidalia or the control port itself to choose a new path, in addition to clearing Tor cache+cookies. This may or may not depend on a "Tor Status" check to verify that the tor process is in fact running. Unfortunately, there are lots of usability issues with control port auth, multiple confusing controls and statues, exactly which cookies get cleared, etc that need to be considered.

[Automatically added by flyspray2trac: Operating System: All]

to

One of these days it might be nice to add a "New Identity" button to Torbutton to instruct vidalia or the control port itself to choose a new path, in addition to clearing Tor cache+cookies. This may or may not depend on a "Tor Status" check to verify that the tor process is in fact running. Unfortunately, there are lots of usability issues with control port auth, multiple confusing controls and statues, exactly which cookies get cleared, etc that need to be considered.

[Automatically added by flyspray2trac: Operating System: All]
Keywords: N/A deleted, N/A added

Trac:
Summary: New Identity Button to New Identity Button and Timer

Explicitly providing the option to close old tabs when this timer goes off is a good idea too, as lots of state can be hidden in a live open page, independent of cookies and cache.

Trac:
Status: new to assigned
Owner: N/A to koryk

Worth reviewing: http://nevercookie.anonymizer.com/

Claims to defeat evercookies. We also defeat evercookies based on both my understanding of how they work and a manual test, but this addon is probably worth a quick look just to see if they do anything extra.

For Tor Browser Bundle, doing a New Identity Button is actually much easier, because Vidalia now launches both Tor and Firefox. It passes a control port password to Tor via the command line. It can pass this same password to Torbutton via an environment variable. This way, Torbutton can connect to Tor's control port to send the SIGNAL NEWNYM itself.

Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A

Replying to mikeperry:

For Tor Browser Bundle, doing a New Identity Button is actually much easier, because Vidalia now launches both Tor and Firefox. It passes a control port password to Tor via the command line. It can pass this same password to Torbutton via an environment variable. This way, Torbutton can connect to Tor's control port to send the SIGNAL NEWNYM itself.

What level of Firefox (or extension) vulnerability would be sufficient to break into and reconfigure your Tor, in this case?

Replying to arma:

Replying to mikeperry:

For Tor Browser Bundle, doing a New Identity Button is actually much easier, because Vidalia now launches both Tor and Firefox. It passes a control port password to Tor via the command line. It can pass this same password to Torbutton via an environment variable. This way, Torbutton can connect to Tor's control port to send the SIGNAL NEWNYM itself.

What level of Firefox (or extension) vulnerability would be sufficient to break into and reconfigure your Tor, in this case?

A vulnerability that enables the full reconfiguration of Tor from Firefox using this password would also allow arbitrary code execution as the Firefox user.

One of the reasons why this ticket is languishing for so long is that it is hard to envision the user story for a browser that auto-clears state without telling them. They are going to wonder why their logins keep breaking..

Is a periodic popup too much for this? How do we prevent it from getting annoying, without having them forget that the browser is doing this for them?

Replying to mikeperry:

For Tor Browser Bundle, doing a New Identity Button is actually much easier, because Vidalia now launches both Tor and Firefox. It passes a control port password to Tor via the command line. It can pass this same password to Torbutton via an environment variable.

The firefox-remote IPC mechanism would most likely be a safer way to send the password to Firefox.

Replying to rransom:

The firefox-remote IPC mechanism would most likely be a safer way to send the password to Firefox.

That is, if we didn't completely disable that IPC mechanism in TBB-Firefox.

2011-03-04 20:50 I think this firefox-ipc idea is out 2011-03-04 20:50 this is all the interface to remoting that we get: 2011-03-04 20:50 http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/interfaces/nsINativeAppSupport

Trac:
Parent: N/A to #2880 (closed)

I think we should go for the env variable option, much like in #2843 (closed).

I'd really love to have something like this implemented in the Torbutton add-on.

In fact I was trying to get it done quickly (and hackishly) myself before I found this post.

What's the status of this particular feature?

Trac:
Username: Hopkey

Hopkey: No one is actively working on it, but a quick hackish way to get it done is to invoke the functions invovled in the toggle codepath without actually toggling proxy settings: https://www.torproject.org/torbutton/en/design/#id2696524

I would accept such a patch if you were interested in working on it.

Trac:
Component: Torbutton to TorBrowserButton

Hopkey: There may be some details with respect to either closing all open tabs, and/or giving them a separate and distinct tab tag, though. Search the design doc for "State Isolation" and "Network Isolation" to see how that comes into play..

Trac:
Cc: mikeperry,squires,arma to mikeperry, squires, arma, Hopkey

HopKey: Are you still here? I think you may have missed a comment before I added you to Cc..

This might be a lot easier to implement if proposal 171 gets implemented. Getting a new identity would be a matter of generating a new random SOCKS username.

Trac:
Cc: mikeperry, squires, arma, Hopkey to mikeperry, squires, arma, Hopkey, lunar@debian.org

Replying to lunar:

This might be a lot easier to implement if proposal 171 gets implemented. Getting a new identity would be a matter of generating a new random SOCKS username.

Lunar: This ticket includes the Torbutton work of clearing all accumulated browser state.

Trac:
Milestone: 1.4 to TorBrowserBundle 2.2.x-stable
Parent: #2880 (closed) to N/A

Trac:
Points: N/A to 6
Summary: New Identity Button and Timer to New Identity Button
Owner: koryk to mikeperry

Forgot about the control port part of this.

Trac:
Points: 6 to 8

Trac:
Keywords: N/A deleted, MikePerryIteration20110814 added

Alright this is finished. Here is the list of things done:

1. Tag all tabs as non-tor
2. Disables Javascript and plugins on all tabs
3. Clears state: a. OCSP b. Cache c. Site-specific zoom d. Cookies+DOM Storage+safe browsing key e. google wifi geolocation token f. http auth g. SSL Session IDs h. last open location url
4. Sends tor the NEWNYM signal to get a new circuit

We still need to do a little better job SSL state, in particular intermediate certificates are not yet properly cleared. See #2739 (moved) for that.

Trac:
Status: assigned to closed
Actualpoints: N/A to 8
Resolution: None to fixed

Oh, it also closes all tabs, in addition to tagging and disabling them.

closed

changed time estimate to 64h

added 64h of time spent

mentioned in issue #637 (closed)

mentioned in issue #1579 (closed)

mentioned in issue #1579 (closed)

mentioned in issue #1968 (closed)

mentioned in issue #2659 (closed)

mentioned in issue #2669 (closed)

mentioned in issue #2739 (moved)

mentioned in issue #2741 (closed)

mentioned in issue #2877 (moved)

mentioned in issue #3546 (moved)

mentioned in issue #3737 (closed)

mentioned in issue tpo/applications/tor-browser#2877 (closed)

mentioned in issue tpo/applications/tor-browser#3546 (closed)