Delivery-Date: Sat, 25 Apr 2015 18:14:40 -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 4B7CC1E0032
	for <archiver@seul.org>; Sat, 25 Apr 2015 18:14:38 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 6C91534BCE;
	Sat, 25 Apr 2015 22:14:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C618934A28
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 22:14:25 +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 bbsLGqfhaomK for <tor-talk@lists.torproject.org>;
 Sat, 25 Apr 2015 22:14:25 +0000 (UTC)
Received: from dd15500.kasserver.com (dd15500.kasserver.com [85.13.136.184])
 (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 95E4934A26
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 22:14:25 +0000 (UTC)
Received: from 127.0.0.1 (tor-exit1.arbitrary.ch [78.46.51.124])
 by dd15500.kasserver.com (Postfix) with ESMTPSA id DDA225CE0137
 for <tor-talk@lists.torproject.org>; Sun, 26 Apr 2015 00:14:20 +0200 (CEST)
Message-ID: <553C11BA.2020208@sophiehassfurther.com>
Date: Sat, 25 Apr 2015 22:14:18 +0000
From: Sophie Hassfurther <sophie@sophiehassfurther.com>
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <mailman.1792.1429863964.6921.tor-talk@lists.torproject.org>
 <79B84641-96E9-4712-89F0-803065D67139@gmail.com>
 <20150425171609.EC5C240C08@smtp.hushmail.com>
In-Reply-To: <20150425171609.EC5C240C08@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-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 guys,

What you explained is a little over my head. Also my capacities are very
limited at the moment. I will look into it, soon!

Thanks
S


l.m:
> Hi teor,
> 
> You could run TorBirdy through its own instance of the tor client
> software, with a separate socks port.
> 
> This  would avoid many of the issues you're trying to work around in
> b) and  c), as TorBirdy could happily send NEWNYM to its own client
> instance all  it liked. There is a slightly increased network load
> involved in  running two instances, and there could be security
> implications of  running separate tor clients - but mainly if their
> connections are  distinguishable.
> 
> teor
> 
> Good point. Then again you can do that with any application and tor.
> The main motivator is the use case for shared tor process. Tor itself
> encourages this use case by supporting multiple socks ports and
> isolation flags. Is it reasonable to expect everyone to run multiple
> tor processes to isolate the NEWNYM signal? It also raises the
> question of *how* they would issue the NEWNYM signal. A patch would
> involve adding a simple controller to TorBirdy. In some use cases it
> probably isn't even a concern to share NEWNYM. That is sometimes just
> a NEWNYM is fine, ignoring the problem of changing exit. So if a patch
> were created it should support both use cases: issue a NEWNYM or
> emulate it for shared use-cases?
> 
> I think it might be too much to ask a tor process to issue NEWNYM to a
> specific isolation context. But given the shared-process use case is
> encouraged--is this a preferable solution?
> 
> --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

