Delivery-Date: Sat, 25 Apr 2015 13:16:23 -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 1A1FE1E0ABB
	for <archiver@seul.org>; Sat, 25 Apr 2015 13:16:21 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 33A1534E69;
	Sat, 25 Apr 2015 17:16:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C0F7B34D38
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 17:16:13 +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 r4xyf6qFhD7L for <tor-talk@lists.torproject.org>;
 Sat, 25 Apr 2015 17:16:13 +0000 (UTC)
Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134])
 (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 42E1934B61
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 17:16:13 +0000 (UTC)
Received: from smtp2.hushmail.com (localhost [127.0.0.1])
 by smtp2.hushmail.com (Postfix) with SMTP id 0F624A01DA
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 17:16:10 +0000 (UTC)
Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32])
 by smtp2.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 17:16:09 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id EC5C240C08; Sat, 25 Apr 2015 17:16:09 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 25 Apr 2015 13:16:09 -0400
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <79B84641-96E9-4712-89F0-803065D67139@gmail.com>
References: <mailman.1792.1429863964.6921.tor-talk@lists.torproject.org>
 <79B84641-96E9-4712-89F0-803065D67139@gmail.com> 
Message-Id: <20150425171609.EC5C240C08@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk]
	=?utf-8?q?TorBirdy_seems_to_connect_to_the_same_exit?=
	=?utf-8?q?=09node=09again_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 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

