[tbb-bugs] #9442 [Tor Browser]: Add New Circuit button to TorButton for TBB alpha 3.x
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Jul 31 19:32:49 UTC 2014
#9442: Add New Circuit button to TorButton for TBB alpha 3.x
Reporter: | Owner: tbb-team
cypherpunks | Status: new
Type: | Milestone:
enhancement | Version:
Priority: normal | Keywords: tbb-newnym, tbb-easy, tbb-
Component: Tor | usability, extdev-interview, tbb-torbutton
Browser | Parent ID:
Actual Points: |
Comment (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
> 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
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
- 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
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'
- 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.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9442#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs