Opened 6 years ago

Closed 4 years ago

#9442 closed enhancement (fixed)

Add New Circuit button to TorButton

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-newnym, tbb-easy, tbb-usability, extdev-interview, tbb-torbutton, TorBrowserTeam201502R, MikePerry201502
Cc: gk, mcs, brade, arthuredelstein, mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From the blog:

https://blog.torproject.org/blog/tor-browser-bundle-30alpha3-released#comment-33436

ME:

Can we PLEASE have a NEWNYM function in the alpha TorButton now that Vadalia GUI is gone? The "New Identity" feature in TorButton is not the same thing as NEWNYM, they do not serve the same function, not at all.

I've asked a few times and no one has responded :( I even asked Mike *directly* on Tor-talk . . .

Many times a user doesn't want to clear all their tabs and re-launch, they just want a new exit node.

Please, please, please, add the damn NEWNYM function.

SOMEONE ELSE:

+1 Agree with this comment.

It's too bad to not have that option

Arma:

Hm. Is this because the website you're trying to reach is trying to block Tor, and you're trying to find an exit relay that isn't blocked yet? Or some other issue?

I think a lot of the reasons people click newnym are somewhat harmful to the Tor network (more circuits made), so I'm torn.

ME:

Hi arma,

Thanks for your response :) And I'm very sorry for being a bit rude, it's been a long day and I'm kind of grumpy by nature. You guys are amazing for not being rude back, you're a better man than I.

The reason I like having newnym is:

a.) Try to find faster circuit, which may be "somewhat harmful to the Tor network" even though you guys added the forced delay (grayed out button) for N seconds after it was used.

b.) To prevent cross site traffic, e.g. I clear cookies and cache, then use NEWNYM when on site A, before I open a new tab to visit site B. I'm not sure if this is less 'safe' then clearing all tabs and re-lunching, but it sure is a lot better in terms of usage (being forced to close all tabs really sucks). I really dislike having to close all tabs when I want a new IP address, I often surf multiple sites concurrently, so the New Identity feature in TorButton is not an option for me.

I guess the best option here would be if Mike was able to figure out finer-grained cookie control (IIRC, that he wrote about before), e.g. per tab. Then there would be less of a need to re-launch TorBrowser when someone clicks "New Identity."

As always I defer to TPO's much greater knowledge than my own.

Child Tickets

Change History (24)

comment:1 Changed 6 years ago by cypherpunks

Ugh. "TPO's" when supposed to read "Tor Project's."

comment:2 Changed 6 years ago by cypherpunks

Anothony Georgeo is 'me,' from years ago; I'm bringing back the vbs script in case Tor won't add NEWNYM into TorBrowserButton for TBB 3.xalpha. See here: https://lists.torproject.org/pipermail/tor-talk/2006-August/001738.html.

Here's the code to issue NEWNYM to Tor with vbs, but, it's not working: http://pastebin.com/BT8eXpWh

I'm having trouble with the second line, I'm seeking help[0] to fix the problem. Maybe someone here may want to look at the Pastebin code above? I'm using Toolsack Baseline 1.1 (http://www.toolsack.com/download/)

[0] http://www.vbforums.com/showthread.php?730309-Plz-help-w-code-quot-ActiveX-component-can-t-create-object-quot&p=4481183

comment:3 Changed 6 years ago by cypherpunks

Here's the problem with the code:

error code 800A01AD 

ActiveX component can't create object" 'Toolsack.Socket'

It seems like the problem may be due to issues from x86 vs x64 DLL paths(?). At least that's what I was able to glean from the Internets.

comment:4 Changed 6 years ago by cypherpunks

Line 13 is the problem (http://pastebin.com/BT8eXpWh):

set torsck = CreateObject("Toolsack.Socket")

comment:5 Changed 6 years ago by cypherpunks

It looks like the issue may be from trying to run Toolsack 1.1 basline on Windows 7. Looking into this now. 

I know this isn't going to help the Tor people, but maybe it will help Windows users if the Tor people decide against adding  a default NEWNYM feature in TorButton.

comment:6 Changed 6 years ago by cypherpunks

There should also be the functions to start and stop tor,

I need to stop tor from time to time but all the open tabs on browser should stay there, with vidalia it was easy, now I can't do it.

comment:7 Changed 6 years ago by arma

Keywords: tbb-newnym added

comment:8 Changed 5 years ago by mikeperry

Keywords: tbb-usability extdev-interview added
Summary: Add NEWNYM function to TorButton for TBB alpha 3.xAdd New Circuit button to TorButton for TBB alpha 3.x

I suppose we could burry a "New Circuit" button in the Network Settings window somewhere that does SIGNAL NEWNYM only.

comment:9 Changed 5 years ago by gk

Cc: gk added

comment:10 in reply to:  description Changed 5 years ago by toruser23

Replying to cypherpunks:

From the blog:

I think a lot of the reasons people click newnym are somewhat harmful to the Tor network (more circuits made), so I'm torn.

There are many legitimate reasons too.

Replying to mikeperry:

I suppose we could burry a "New Circuit" button in the Network Settings window somewhere that does SIGNAL NEWNYM only.

Please do not "bury" this somewhere there are so so so SO many times where I'll encounter a webite that decides to either use google recaptchas when you make too many connections from the same IP or decides to use cloudflare which sometimes won't even allow you to try and solve the captcha at all!

Also another horrible aspect of google recaptchas that make me use NEWNYM is that when you're coming from an exit node outside your country the words tend to be even harder to solve cause they're not in your native language.

Please reconsider.

comment:11 Changed 5 years ago by mikeperry

Having this feature in the primary menu will likely confuse normal people who won't abuse the feature for localization or captcha evasion purposes (and who have no idea what a "Tor Circuit" even is). Moreover, our dropdown menu for Torbutton is getting too long already. Users start to get overwhelmed by large context menus with no conceptual breaks. If memory serves, this happens after just 4 or 5 entries without some form of grouping.

If someone can propose a way to organize the Torbutton menu and suggest menu entry text to name this bizarre feature such that the average person (who doesn't understand how Tor works) will actually understand it, then I might reconsider.

It also turns out to be the case that my original suggestion to put it in Network Settings is the wrong place for this though too, in part because that XUL window is displayed during startup, so we're sort of stuck.

comment:12 in reply to:  11 ; Changed 5 years ago by toruser23

Replying to mikeperry:

Having this feature in the primary menu will likely confuse normal people who won't abuse the feature for localization or captcha evasion purposes (and who have no idea what a "Tor Circuit" even is). Moreover, our dropdown menu for Torbutton is getting too long already.

I don't really see it as abuse, minor detail I guess. I do however see a future where people are getting catpchas constantly either leading them to think the website is broken or the tor has problems. When browsing with tor I always encounter captchas far more than any normal connection and it's on the rise.

It also turns out to be the case that my original suggestion to put it in Network Settings is the wrong place for this though too, in part because that XUL window is displayed during startup, so we're sort of stuck.

Is it possible to perhaps have a configuration option that modifies the drop down menu in the first place? Then just have said option off by default?

comment:13 in reply to:  12 ; Changed 5 years ago by mikeperry

Replying to toruser23:

Replying to mikeperry:

Having this feature in the primary menu will likely confuse normal people who won't abuse the feature for localization or captcha evasion purposes (and who have no idea what a "Tor Circuit" even is). Moreover, our dropdown menu for Torbutton is getting too long already.

I don't really see it as abuse, minor detail I guess. I do however see a future where people are getting catpchas constantly either leading them to think the website is broken or the tor has problems. When browsing with tor I always encounter captchas far more than any normal connection and it's on the rise.

I don't think that "Keep trying new circuits if a website presents a captcha or tries to ban you" is something we want to recommend in any official documentation. It's also seems like something that only people who are familiar with the operations of Tor will understand if we don't devote training materials to the idea.

It also turns out to be the case that my original suggestion to put it in Network Settings is the wrong place for this though too, in part because that XUL window is displayed during startup, so we're sort of stuck.

Is it possible to perhaps have a configuration option that modifies the drop down menu in the first place? Then just have said option off by default?

This seems plausible. Is an about:config pref sufficient? It seems like a technical thing that having technical people tweak a pref for is a decent compromise.

Otherwise, where would we put this UI option, and what would it's text be? In the "Preferences Menu"? Is it a Security Setting? "Provide menu option to request a New Tor Circuit"?

comment:14 in reply to:  13 Changed 5 years ago by toruser23

Replying to mikeperry:

This seems plausible. Is an about:config pref sufficient? It seems like a technical thing that having technical people tweak a pref for is a decent compromise.

Otherwise, where would we put this UI option, and what would it's text be? In the "Preferences Menu"? Is it a Security Setting? "Provide menu option to request a New Tor Circuit"?

I'd be sufficiently happy with it being in about:config for the technically inclined tor users. I don't know how others feel about having it there, maybe if others could give some input I don't do much UI design, so I think having some input from others would be a good idea.

comment:15 Changed 5 years ago by mcs

Cc: mcs brade added

comment:16 Changed 5 years ago by mikeperry

Keywords: tbb-easy added

comment:17 Changed 5 years ago by erinn

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

comment:18 Changed 5 years ago by cypherpunks

Having this feature in the primary menu will likely confuse normal people who won't abuse the feature for localization or captcha evasion purposes (and who have no idea what a "Tor Circuit" even is). Moreover, our dropdown menu for Torbutton is getting too long already. Users start to get overwhelmed by large context menus with no conceptual breaks. If memory serves, this happens after just 4 or 5 entries without some form of grouping.

If someone can propose a way to organize the Torbutton menu and suggest menu entry text to name this bizarre feature such that the average person (who doesn't understand how Tor works) will actually understand it, then I might reconsider.

It's not a 'bizarre feature', and it can't be that hard to label items in humanspeak, according to what they do:
e.g., 'New Connection' vs. 'New Identity, clear all data'.
Btw, is it possible to add tooltips to the respective menu items, for briefly explaining their resp. functions & differences?

(While on the (off)topic of the menu: 'Network Settings' could IMHO go under 'Preferences', the 'Cookie Protections' thingie is unintuitive and clunky and would at least need some brief explanation on the interface, and lastly, easy access to Firefox' "Clear Recent History/Clear All Current History" function - which for some reason is grayed out in Firefox' History menu and accessible only via 'Edit>Preferences>Privacy' - would be much appreciated!)

Common use cases for this 'bizarre feature' when it was handily accessible in Vidalia, in my case included:

  • connection to website goes unresponsive, or becomes incredibly slow, for to me completely mysterious reasons (but apparently related to the exit node and/or relay path, as clicking this button often helped!);
  • multi-tab anonymous browsing; clearing browser data & getting new IP without losing all open tabs;
  • some site might have blocked some Tor exit node for an understandable reason, through no fault of the current user i.e. me; In the long term there needs to be more awareness of the fact that IP black/greylisting of single Tor exit nodes IS AN ANTI-SOLUTION FOR ALL PARTIES, but in the short term i just want to access my websites pretty please, preferably without having to essentially restart the browser & retype the address/addresses.
  • solving various issues related to webservice login/IP identification and Tor's automatic ID-switching every 10 minutes, in the context of completely legitimate usage; also related to above points re: multi-tab browsing, etc.

In short, it's a functionality that helps a lot with bridging various gaps between how the 'mainstream internet' works and how Tor works.

Re: "encouraging harmful behavior": IMHO,
providing users with session-only, anonymous IP addresses, and circumventing various forms of network blockage, is what Tor does. Maybe not Tor's be-all and end-all, but clearly an integral part as a means to its ends. I see no point in backpedaling or vacillating about this just because of friction with mainstream webservice management (bad) practices. Instead what needs to happen is that webservice maintainers & developers need to understand how Tor works differently; i.e.

  • blocking a Tor IP address only solves issues of malicious exit nodes, not malicious users.
  • excessive dependency on black/greylisting of IP addresses, Tor or others, is in most cases not a real solution but a symptom of a problem with how the webservice is set up / operated. Particularly anti-spam 'solutions' are often guilty of this.* Basically, 'content-level' problems such as user misbehavior, spam, should be solved on the 'content level'; IP-based access control should be for 'network-level' issues/attacks.
  • blocking all Tor exit nodes is defensible as a temporary emergency stopgap, but not as a default policy 'for good measure'.
  • etc. etc.

Now, obviously this enlightenment process takes time and might even never reach hegemonic levels, so in the meantime (i.e. maybe forever), Tor needs to work around prevailing bad practices so that using Tor doesn't "break the internet" for the end user. That is, any more than necessary for Tor's core purpose, i.e. security/privacy/anonymity; i'm perfectly happy with having to go through 2-3 menus to enable risky things like plugins, or JS the day you guys finally set NoScript's default to what NoScript is supposed to do; i'm not perfectly happy with e.g. navigating to a site only to discover that i have to switch to a non-Tor browser (bad anon practice!!) to actually use the site, or have to lose all my open tabs because some mysterious Tor-node connection has mysteriously died on me, etc.

* ironically, when i tried to register on this very Trac-site today, StopForumSpam thought i was spam and locked me into ReCaptcha limbo (after solving a ReCaptcha, StopForumSpam again thought i was spam and gave me a new ReCaptcha to solve, after solving which etc. etc. etc. forever. This is actually fairly common both with ReCaptcha and with Cloudflare). If my tone is a bit agitated in this comment, blame this.

Sorry for the rant, you Tor Project people are actually terrific! Keep up the amazing great work!! Thanks, over & out.

comment:19 Changed 5 years ago by toruser23

Since this hasn't been going anywhere fast for ages I at least have a way to bring back this functionally in the *nix realm:

Code highlighting:

#!/bin/bash

if [ -z "$(command -v xmessage)" ]; then
        echo "Error: Can't find xmessage"
        exit 1
fi

if [ -z "$(command -v hexdump)" ]; then
        xmsg_responce="$(xmessage -print "Error: Can't find hexdump")"
        echo "Error: Can't find hexdump"
        exit 1
fi

cookie_file="./tor-browser_en-US/Data/Tor/control_auth_cookie"

if [ -r "$cookie_file" ]; then
        auth_cookie=$(hexdump -e '32/1 "%02x""\n"' $cookie_file)
else
        xmsg_responce="$(xmessage -print "Error: Can't find cookie file")"
        echo "Error: Can't find cookie file"
        exit 1
fi


/usr/bin/expect &>/dev/null << EOF
set timeout 20
spawn telnet 127.0.0.1 9151
expect -exact "Trying 127.0.0.1...\r
Connected to 127.0.0.1.\r
Escape character is '^]'.\r
"
send -- "AUTHENTICATE $auth_cookie\r"
expect -exact "250 OK\r"
send -- "signal NEWNYM\r"
expect -exact "250 OK\r"
send -- "quit\r"
expect eof
EOF

exit_code="$?"

if [ "$exit_code" == "0" ]; then
        xmsg_responce="$(xmessage -print -timeout 5 "Using new tor circut")"
        echo "Using new circut"
else
        xmsg_responce="$(xmessage -print "Error: expect failed")"
        echo "Error: expect failed"
fi

comment:20 Changed 4 years ago by mikeperry

Cc: arthuredelstein added
Keywords: TorBrowserTeam201502R MikePerry201502 added
Status: newneeds_review
Summary: Add New Circuit button to TorButton for TBB alpha 3.xAdd New Circuit button to TorButton

Ok, I implemented this in commit 6ba3a3d11bc1fb6a3415aa7363062bec1d6ac964 of mikeperry/1.8-next in my torbutton remote: https://gitweb.torproject.org/mikeperry/torbutton.git/commit/?h=1.8-next&id=d67b6db8409eea440aace24a1be297dcd7bcce4a

However, there appears to be a bug in our SOCKS username+password patch that is causing Tor Browser to always send "0" as the password, even though the SOCKS password is clearly being updated in the nsIProxyInfo. Arthur - can you have a look?

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

comment:21 in reply to:  20 Changed 4 years ago by arthuredelstein

Replying to mikeperry:

Ok, I implemented this in commit 6ba3a3d11bc1fb6a3415aa7363062bec1d6ac964 of mikeperry/1.8-next in my torbutton remote: https://gitweb.torproject.org/mikeperry/torbutton.git/commit/?h=1.8-next&id=d67b6db8409eea440aace24a1be297dcd7bcce4a

However, there appears to be a bug in our SOCKS username+password patch that is causing Tor Browser to always send "0" as the password, even though the SOCKS password is clearly being updated in the nsIProxyInfo. Arthur - can you have a look?

This turned out to be a bad bug where the proxyInfo was being cached for a given URL, even though the username/password had changed. Obviously that's very bad for circuit isolation. I've posted a patch here:
https://github.com/arthuredelstein/tor-browser/commit/981c39e35f07cfa6a4bf934ba463f78d4ab796ce

Another bug shows up once my fix is applied: #14866.

comment:22 Changed 4 years ago by arthuredelstein

I've now posted a fix for #14866.

Also, I think Mike's patch for this ticket looks good. I tested it and also examined the code. The menu item text "New IP Address for this Site" sounds a little odd to me -- maybe "New Tor Circuit for this Site"?

comment:23 Changed 4 years ago by arthuredelstein

Cc: mikeperry added

comment:24 Changed 4 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok, I switched the string to "New Tor Circuit for this Site", and merged the fixed to tor-browser.git and torbutton. Thanks!

Note: See TracTickets for help on using tickets.