Delivery-Date: Tue, 22 Mar 2016 22:40:30 -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 240521E0BF1;
	Tue, 22 Mar 2016 22:40:08 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id AFAA13928D;
	Wed, 23 Mar 2016 02:40:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0BA2639280
 for <tor-talk@lists.torproject.org>; Wed, 23 Mar 2016 02:39:57 +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 E_VsK_dl_Odl for <tor-talk@lists.torproject.org>;
 Wed, 23 Mar 2016 02:39:56 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil
 [IPv6:2001:480:20:118:118::211])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id C5472391F2
 for <tor-talk@lists.torproject.org>; Wed, 23 Mar 2016 02:39:55 +0000 (UTC)
Received: from vpn212046.nrl.navy.mil (vpn212046.nrl.navy.mil [132.250.212.46])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u2N2dotp021345
 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT)
 for <tor-talk@lists.torproject.org>; Tue, 22 Mar 2016 22:39:52 -0400
Date: Tue, 22 Mar 2016 22:39:52 -0400
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <20160323023952.GB17280@vpn212046.nrl.navy.mil>
References: <259387.67882.bm@smtp146.mail.ir2.yahoo.com>
 <20160323000835.GJ15350@torproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20160323000835.GJ15350@torproject.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Subject: Re: [tor-talk] Extend auto-IP-switching-time in TorBrowser (and
 depending from time of inactivity)
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>

On Tue, Mar 22, 2016 at 05:08:35PM -0700, Mike Perry wrote:
> Ben Stover:
> > As far as I know TorBrowser switches automatically every 10 minutes the node chain resp. the IP of the ExitNode.
> > 
> > Can I somehow extend this timeout time to another value e.g. 30 minutes?
> > 
> > Or (even better) can I let Tor auto-switch the IP and chain depending from the time of inactivity (.e.g when 15 minutes no
> > web page is called)?
> 
> We had a long discussion about this in
> https://trac.torproject.org/projects/tor/ticket/15482. Ultimately, a fix
> was merged to Tor, but it did not cause Tor to update its circuit
> discard timeout (the "dirtyness" timeout) upon stream detach.
> 
> I have also noticed worse behavior since Tor Browser switched from the patch I
> wrote in
> https://trac.torproject.org/projects/tor/attachment/ticket/15482/0001-Bug-15482-Don-t-abandon-circuits-that-are-still-in-u.patch
> to the version in Tor today.
> 
> I also agree we should be more aggressive about keeping circuits in use.
> I think we should go back to updating this timeout when streams are
> closed, otherwise we risk the situation where HTTP KeepAlive keeps an
> idle stream open for several minutes, and then when that stream closes,
> it is more likely that a new stream will go on a separate circuit
> because the timeout expired while the stream was open but idle.

I'm confused. What is the situation you are concerned about?  A new
stream would go over a new circuit whether the previous stream is kept
alive or not. Is that not so? And I'm not sure what keeping the idle
stream open has to do with this. I understand the UX issues of
switching circuits, and I get the threat if not allowing a stream to
close causes attaching indefinitely to new circuits.  But I don't
understand why it is bad to have a new stream open on a new circuit
after another stream closes that was artificially kept open for a
while vs. having the new stream open after an initial stream closed
normally.

aloha,
Paul
-- 
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

