Delivery-Date: Mon, 13 Apr 2015 15:13:45 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id E0B271E104F
	for <archiver@seul.org>; Mon, 13 Apr 2015 15:13:43 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 0E6BC33F3B;
	Mon, 13 Apr 2015 19:13:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0910532F49
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 19:13:35 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9tXaZaYOlS7h for <tor-talk@lists.torproject.org>;
 Mon, 13 Apr 2015 19:13:34 +0000 (UTC)
Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id C47E12B2B3
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 19:13:34 +0000 (UTC)
Received: from smtp10.hushmail.com (localhost [127.0.0.1])
 by smtp10.hushmail.com (Postfix) with SMTP id BE6F0C01AF
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 19:13:31 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52])
 by smtp10.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 19:13:31 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id 9AF42E0433; Mon, 13 Apr 2015 19:13:31 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 13 Apr 2015 15:13:31 -0400
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <552C1189.2050501@rawbw.com>
References: <5527BB80.8010708@sophiehassfurther.com>
 <20150410183853.GA32173@riseup.net> <552820C1.8050203@sophiehassfurther.com>
 <20150410215018.F057CC0D3A@smtp.hushmail.com>
 <5528C834.7020305@sophiehassfurther.com> <552AFCCA.6040609@rawbw.com>
 <20150413171551.E4E4BE042D@smtp.hushmail.com> <552C1189.2050501@rawbw.com> 
Message-Id: <20150413191331.9AF42E0433@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] TorBirdy seems to connect to the same exit node
	again and again
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Hi Yuri,

"Yuri"  wrote:
>I understand your concerns. But I would also like to 
>point out that "New Identity" for most implies new 
>identity for everything. This is how, I believe, majority 
>of technically not very savvy mass users thinks.

The new identity feature is documented to make *new* connections
appear to be from a different user. It doesn't say anywhere that it
terminates existing application connections. That's an assumption on
the part of the user. The only application where there's an exception
is Tor Browser which is coded to break those connections. It needs to
do this to deal with web bugs. If some other application has open
connections using tor it stand to reason that application has a
purpose for keeping the connection open. Either that application will
close the connection gracefully or not.

It's a hack to force third-party applications to close their
connections explicitly and call it a feature of tor. In truth it's
something that can already be done. Connect to the tor process using
telnet and close the circuits as you see fit. Alternatively connect
using Vidalia and close the circuit. I'm sure there are other ways.
So, in fact, there's nothing to code to get the feature you want as
it's already there. There's no place for the feature in Tor Browser
since it already explicitly closes connections related to open
tabs--allowing the circuits to close gracefully. It remains the
responsibility of any other third-party application to gracefully
close their own connections. If they don't the circuit stays open.
How's that not a bug you would rather fix in the application itself?
--leeroy
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

