Delivery-Date: Fri, 25 Mar 2016 07:12:38 -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.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 EE9551E0456;
	Fri, 25 Mar 2016 07:12:36 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 434CD392EC;
	Fri, 25 Mar 2016 11:12:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6760039378
 for <tor-talk@lists.torproject.org>; Fri, 25 Mar 2016 11:12:27 +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 JaHieWdbTJ-f for <tor-talk@lists.torproject.org>;
 Fri, 25 Mar 2016 11:12:27 +0000 (UTC)
Received: from nm20-vm5.bullet.mail.ir2.yahoo.com
 (nm20-vm5.bullet.mail.ir2.yahoo.com [212.82.96.247])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 0B1FA32CF7
 for <tor-talk@lists.torproject.org>; Fri, 25 Mar 2016 11:12:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048;
 t=1458904342; bh=YY3PaUwc1H43n/pxZBRVPoHVkWymy7UnPmCT0M4mgsw=;
 h=From:To:Date:Subject:From:Subject;
 b=huHF9DpQxsbgyLHu37hLMCKW9QMlBcx7SzJjOn9nXO3swinKFgD5+TabB5OWOMM2wboOlu1q1X4H4xF0IYs7vYTqsi4PCS39LkuDW+v2/O8URxtme9phTQYKJlcBQD7RCGDJ3dbsZb321tmFufm/KWMN3ICzUOEI+Gyg3M/k4Hdo6vGxALAOE3ThQbxk2wWVgqKCDYE80i5sah7MDzJkW9ssMu14C6ySvSZgm6+WLQkzYU96Rrsw/0X6OAAi9nOR2N0QP2lJD3Xz9JOvnsV+y4lpUxTx5OwRsixHkJyn0doVmM5Iu2V32vKnISpwWix+8BMqZ7jxlgW2jtL5sl6whw==
Received: from [212.82.98.48] by nm20.bullet.mail.ir2.yahoo.com with NNFMP;
 25 Mar 2016 11:12:22 -0000
Received: from [46.228.39.80] by tm1.bullet.mail.ir2.yahoo.com with NNFMP;
 25 Mar 2016 11:12:22 -0000
Received: from [127.0.0.1] by smtp117.mail.ir2.yahoo.com with NNFMP;
 25 Mar 2016 11:12:22 -0000
X-Yahoo-Newman-Id: 194344.4560.bm@smtp117.mail.ir2.yahoo.com
Message-ID: <194344.4560.bm@smtp117.mail.ir2.yahoo.com>
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: cGR3hikVM1miCueh5L36KHcRgWaH1BHt8Vn0ILPPyCeM4bl
 4f7OGEOaJ2VyM4Kf0owLHnjy8dsCU1K2kMzgdQoWGqsxSrhEpbakibuU_S9P
 NCQjUJYH188BIA0HL6_jnmRz_BTDfwBInA6jOI08NwyuiXkToLJdcc8R83a0
 r3y9CV0b2NkKiSW4wVTO6EftrC0i9siHaGsiY70kYNShNCyCcFBy6tkcnm3V
 LZITDhj1fCEG8iRuhSuWBRib0u.dIQ5ttEdbQhD4yp8bqCx6EVN.ScFTvUqt
 tONp2XR_f08M5Ia93trqDLH27nGr_QiMJ2YS50bZ428o6YZhl7_C06idNdGm
 KImkG_liOIFcYpe6PTd.FzxGrKl8NtnLlcga4OQGr4XRdA1VWYPE2C_mH.MZ
 STI.rI5vsAK1ARNyatvgE66COMQuARxqo44coFxsSCvPKt9G02skE6k4tkmn
 3hT.1vQc41egy5CTFf1KVH7rGpXU7AX566TegG216NTDw_YW_kC11HjWLTYH
 XcBF9tbwbP7t_tiENrtT9N6MVyciRgl4-
X-Yahoo-SMTP: g8zEfr2swBBGx8tLQhnvE9ArcfYX
From: "Ben Stover" <bxstover@yahoo.co.uk>
To: "TorTalk" <tor-talk@lists.torproject.org>
Date: Fri, 25 Mar 2016 12:12:07 +0100
Priority: Normal
X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (6.1.7601;1)
MIME-Version: 1.0
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>

Hello Paul (and others),

the problem is for example when I login into a remote mailbox through TorBrowser then the mail box provider
see my IP (=IP of ExitNode).

Since I often stay longer than 10 minutes in my remote mailbox an IP switch happens during my mailbox login session.
Unfortunately a lot of mailbox provider setup smart "security session procedures".
As soon as they detect an IP switch they force the user to re-login again (at minimum).

Even worse: Some mail providers consider an account and password break and force the user to "verify" that
they are really to owner of the account with a long-winded confirmation procedure.
This could happen when only changing the country as well.
Very annoying.

So the easiest way to prevent these situation would be to keep the current Tor circuit (or at least the ExitNode).

From what I read so far a "keep-circuit-instruction" is currently not possible.

Why not offering the user such a (torrc) option? So its up to him if he wants an extended circuit-session-time or not.

Ben

>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

