Delivery-Date: Mon, 13 Apr 2015 14:57:29 -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,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 E32871E104F
	for <archiver@seul.org>; Mon, 13 Apr 2015 14:57:27 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A786333EED;
	Mon, 13 Apr 2015 18:57:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4C7B233ECF
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 18:57:19 +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 Rk1dLlWhQt3V for <tor-talk@lists.torproject.org>;
 Mon, 13 Apr 2015 18:57:19 +0000 (UTC)
Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42])
 by eugeni.torproject.org (Postfix) with ESMTP id 1D6B033B12
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 18:57:19 +0000 (UTC)
Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net
 [50.184.63.128]) (authenticated bits=0)
 by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3DIvEaF026624
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
 for <tor-talk@lists.torproject.org>; Mon, 13 Apr 2015 11:57:15 -0700 (PDT)
 (envelope-from yuri@rawbw.com)
X-Authentication-Warning: shell1.rawbw.com: Host
 c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be
 yuri.doctorlan.com
Message-ID: <552C1189.2050501@rawbw.com>
Date: Mon, 13 Apr 2015 11:57:13 -0700
From: Yuri <yuri@rawbw.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
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>
In-Reply-To: <20150413171551.E4E4BE042D@smtp.hushmail.com>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 04/13/2015 10:15, l.m wrote:
> Explicitly closing circuits completely would break third-party
> applications in unpredictable ways. It would generate errors that
> would lead to posts to tor support describing weird application
> behaviour. On the other hand explicitly closing application related
> streams requires tor to be aware of the processes using it. Which
> means additional logic to handle not just source port per application
> stream but also source address (for the shared tor instance). If
> you've seen the backlog of tickets you would understand why a major
> change like this is not ideal.
>
> If there's a problem. Either of applications not closing the
> connection, or a server not closing the connection. These are problems
> that should be fixed--not hidden by tor. That isn't to say what you
> propose isn't a good idea, just it might be better left to custom
> controllers. I think tor-devs might prefer to avoid feature creep.

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.

Also, tolerance to the broken connections is supposed to be built into 
most modern well-behaved apps. At least that is what is reasonably 
expected from the apps in the world when poor connections, ex. barely 
functioning WiFi, is a commonplace.

So I would say that the users should be given such option, provided they 
are informed of what it actually does.

Yuri
-- 
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

