Delivery-Date: Sun, 03 Jan 2016 08:53:53 -0500
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=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,URIBL_BLACK 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 BC6011E03B6;
	Sun,  3 Jan 2016 08:53:51 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5D015389C4;
	Sun,  3 Jan 2016 13:53:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 978E1389C0
 for <tor-talk@lists.torproject.org>; Sun,  3 Jan 2016 13:53:43 +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 yc3CE_qOyfwl for <tor-talk@lists.torproject.org>;
 Sun,  3 Jan 2016 13:53:43 +0000 (UTC)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
 [162.222.225.22])
 by eugeni.torproject.org (Postfix) with ESMTP id 7B19C3895A
 for <tor-talk@lists.torproject.org>; Sun,  3 Jan 2016 13:53:43 +0000 (UTC)
X-Greylist: delayed 497 seconds by postgrey-1.34 at eugeni;
 Sun, 03 Jan 2016 13:53:43 UTC
Received: from [0.0.0.0] (tor-exit2.15-cloud.fr [158.69.208.131])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: s7r@sky-ip.org)
 by outbound.mailhostbox.com (Postfix) with ESMTPSA id 41089782F1C
 for <tor-talk@lists.torproject.org>; Sun,  3 Jan 2016 13:45:41 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
 s=20110108; t=1451828743;
 bh=XiF/yJMHCGidzlNybqaxXFOMpi2aN7Wz5/m8mwoR9S4=;
 h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
 b=StfBOnbNQLezudcDtWzCd/8Pbjq4FdoJkAgzsJh0pyiWMc+knnwqcZAqOlaSb1n3A
 dUdtFbrPdr1NXMWb7TWPsP8n/JoZYWHo5lbhr3n24/hdAqYYcSSQO++Er4R3GSFdxI
 jTPOzGhCCTp0VWJ4KXX6z3KYMbIdFD50pI0bpwHY=
References: <56880CDB.9070305@infosecurity.ch>
 <568834FB.6070008@torservers.net>
To: tor-talk@lists.torproject.org
From: s7r <s7r@sky-ip.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <568925EB.1010705@sky-ip.org>
Date: Sun, 3 Jan 2016 15:45:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <568834FB.6070008@torservers.net>
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=W7WYLUik c=1 sm=1 tr=0
 a=php2eewXIlg4HTyvUAxkRA==:117 a=php2eewXIlg4HTyvUAxkRA==:17
 a=N659UExz7-8A:10 a=ZMxV4npNhVtrZ7KrqEEA:9
 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=pILNOxqGKmIA:10
Subject: Re: [tor-talk] On further minimizing harassment for Tor Exit Nodes
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Altering Tor's path selection is something we shouldn't play with
until we have concrete papers that suggest it is wrong. As Moritz
said, having a GeoIP database to make path selection changes is
probably a terrible idea, due that such databases are by design not
100% accurate and subject to constant change. Such a behavior will
also alter anonymity in an unknown (I think bad) way.

Anyway, your suggestion might actually happen automatically along with
a more important fix, which is AS aware path selection. This is non
trivial work and will probably take some time, but it's not unknown
and people are looking into it.


On 1/2/2016 10:37 PM, Moritz Bartl wrote:
> On 01/02/2016 06:46 PM, Fabio Pietrosanti (naif) - lists wrote:
>> The worst risks is usually considered "being waked up at 6.00am
>> in the morning by authorities" but there's no specific provision
>> on reducing that risks.
>> 
>> The guidelines "Tips for Running an Exit Node with Minimal
>> Harassment" 
>> https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment
>>
>> 
does not cover specifically this kind of risk.
> 
> Well, we do have "whois reassignment" and "create an organization"
> and other things like that in the guidelines that are also aimed at
> reducing this risk. 
> https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines
>
> 
>> We could trigger that if a Tor Exit operator would be able to
>> have an ExitPolicy that deny traffic going to the destination IPs
>> of the country where it's located, leading any kind of abuses to
>> be originated because of Tor Exit traffic flowing to a foreign
>> country.
> 
> You can achieve something similar by placing your relay in a
> country other than your own, without the need of complicated
> rulesets.
> 
> The only way I can see to try and achieve this would be GeoIP
> databases. You know as much as I do that geoIP databases are very
> rough at best, and I don't see how you would keep a geoIP database
> current across the whole network. In practice, if you don't want to
> drop certain requests as an exit, you cannot make it more than a
> "wish" of the exit relay that a client may still violate. In many
> cases Tor already comes with or suggests a GeoIP database (Tor
> Browser, relays).
> 
> Another argument for your suggestion would be that some day,
> traffic in or to certain countries will be more troublesome than to
> others. Something like this could also be used to influence your
> peering/transit ratio to arrange cheaper deals.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWiSXrAAoJEIN/pSyBJlsRgZkIALnF59sE8m7BqwF3gpJg3Q+D
EaS91NDftRwF8AJgte074tcPPONvABesmL5gWEs7CaslbQJSg/7cfQ0fekeP9l43
T1mgzAe8+TQS/4Vy9VzVjoh1trnmmzyb1yOzCsozciH/JzZ7kBxVsExh6rqTlZ4C
VDxcspfIv4Db92+acXR0Rk8sZc2SPxbMemHsGYJZWIwDmUv+7ksG1AJH9XAlPsmA
+o3NRn4PzCekxfFHW7Gyy2Ia/BWqL1jlhj1ODSwSyZeipfnBBdBqmgFfkbiOvkcN
VmLKkh6xcFZC8ViT68t9JXVmYivJpO/nwtHOsznsDaJpJrEI8fB3Zs5C3Wu8FvI=
=U024
-----END PGP SIGNATURE-----
-- 
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

