Feature #8927

Replicate Vidalia's ability to close arbitrary circuits

Added by intrigeri 2015-02-21 09:37:47 . Updated 2017-07-10 10:58:29 .

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:
User interface design

Affected tool:
Onion Circuits
Deliverable for:


The main goal is to enable users to debug potentially buggy or malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions.

  • For HTTPS, one can already use Torbutton’s New Identity feature to achieve the same result. IIRC the upcoming Torbutton’s per-tab circuits viewer will have a “New circuit for this tab” feature, that will make it even better.
  • For other kinds of connections (ssh, imaps, pop3s, etc.) then there are two ways:
    • either using arm to trigger a New Identity, which is not that crazy: close the software that initiated the connection, open a root terminal (which may be a blocker in itself), run “arm”, type “m”, “down arrow” then “enter”
    • or restarting Tor, e.g. by disconnecting and reconnecting from the network using the NM applet

Also, it would be good if arm directly allowed to close one arbitrary circuit: https://trac.torproject.org/projects/tor/ticket/14979.


Related issues

Related to Tails - Feature #9811: Remove Nyx (arm) Resolved 2015-07-29
Related to Tails - Feature #9001: Onion Circuits should connect via the Tor control port filter Resolved 2015-03-03
Related to Tails - Bug #11214: Vidalia replacement: Users miss 'close circuits' feature Duplicate 2016-03-10
Blocked by Tails - Feature #8915: Document Nyx (arm) Resolved 2015-02-18
Blocked by Tails - Feature #6841: Replace Vidalia Resolved 2015-03-03


#1 Updated by intrigeri 2015-02-21 09:38:26

#2 Updated by intrigeri 2015-02-21 09:39:18

  • Description updated

#3 Updated by intrigeri 2015-02-21 09:44:12

  • Description updated

#4 Updated by sajolida 2015-02-21 11:33:46

Another use case would be to try to get pass connection failures on chat servers or websites which might ban an IP but not all exit nodes. Like OFTC does for me lately…

#5 Updated by intrigeri 2015-02-21 12:02:18

> Another use case would be to try to get pass connection failures on chat servers or websites which might ban an IP but not all exit nodes. Like OFTC does for me lately…

Right! Please mention this on the upstream ticket :)

#6 Updated by sajolida 2015-02-22 17:23:15


#7 Updated by sajolida 2015-07-29 10:25:12

#8 Updated by sajolida 2015-09-07 10:49:00

  • Target version changed from Sustainability_M1 to 2016

#9 Updated by sajolida 2015-11-08 02:11:04

  • Affected tool set to Tor Monitor

#10 Updated by intrigeri 2016-02-18 20:34:35

  • Affected tool changed from Tor Monitor to Onion Circuits

#11 Updated by intrigeri 2016-02-19 15:42:11

  • Assignee set to sajolida
  • QA Check set to Info Needed

FTR, I’ve now accepted that Feature #9001 is not going to block Feature #6841, and will likely never happen, so it cannot reasonably block anything. Sorry it took me so long to do this move. And apparently I was the only one insisting on having Feature #9001, which was the only blocker to implement what this ticket is about in Onion Circuits (as opposed as implementing it in Nyx). So let’s implement it in Onion Circuits, right?

So I have a few questions.


  • do you want to implement this feature? Any ETA?
  • how long do you think it would take me to do it? I wonder if I could do this in the next few days, perhaps.

sajolida: do you feel that this is a blocker for Feature #6841? See the ticket description for how users could do this outside of Onion Circuits, until Onion Circuits supports this feature. Sorry if we already have had this discussion and I’m rehashing it, I don’t mean to insist endlessly (the ML discussion was not summed up in the end, and I won’t re-read it now). Let’s keep in mind, though, that removing Vidalia might partly or entirely fix Bug #10576, so one needs to balance the drawbacks of (temporarily) losing this feature (for those who use it) against the corresponding potential advantages (for everyone). As you have guessed, I’m personally not convinced we should block on this, especially if not blocking on it allows us to fix Feature #6841 in 2.2 instead of 3 months later in 2.4, but I don’t care that much and can live with blocking on it.

#12 Updated by intrigeri 2016-02-20 12:13:22

  • Assignee changed from sajolida to alant
  • Parent task deleted (Feature #6841)
  • QA Check deleted (Info Needed)

sajolida says “i don’t have the whole story in mind but moving on with Onion Circuits without Feature #8927 as a first step looks good” => unparenting so that it doesn’t block Feature #6841 anymore. We’ll see how users react.

#13 Updated by intrigeri 2016-02-20 12:13:57

#14 Updated by sajolida 2016-02-21 20:00:11

Maybe when doing things like this (removing features that people might or not miss) we should explicitely ask for feedback in the release notes.

#15 Updated by sajolida 2016-02-27 12:23:39

  • related to Feature #9001: Onion Circuits should connect via the Tor control port filter added

#16 Updated by sajolida 2016-03-11 12:27:40

  • related to Bug #11214: Vidalia replacement: Users miss 'close circuits' feature added

#17 Updated by intrigeri 2016-04-01 16:27:19

  • Assignee changed from alant to sajolida
  • Target version deleted (2016)
  • Type of work changed from Research to User interface design

Alan is OK to review the code someone else will have implemented after the UI has been designed.

#18 Updated by sajolida 2017-06-13 10:24:02

  • Assignee deleted (sajolida)
  • Priority changed from Normal to Low
  • Starter set to Yes

Next step is to propose a UI design but I don’t want to have this on my plate right now.

It could probably be an “Easy” task for some new contributor wanting to do som UI design.

#19 Updated by Anonymous 2017-07-10 10:58:29

  • Subject changed from Replace Vidalia's ability to close arbitrary circuits to Replicate Vidalia's ability to close arbitrary circuits