Delivery-Date: Sat, 02 Jan 2016 15:37:37 -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=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	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 D29D11E0240;
	Sat,  2 Jan 2016 15:37:35 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id D37E238644;
	Sat,  2 Jan 2016 20:37:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3A1A13863E
 for <tor-talk@lists.torproject.org>; Sat,  2 Jan 2016 20:37:26 +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 sMwDJJPiE1kC for <tor-talk@lists.torproject.org>;
 Sat,  2 Jan 2016 20:37:26 +0000 (UTC)
Received: from mail.headstrong.de (mail.headstrong.de [81.7.4.112])
 (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 0A7203863C
 for <tor-talk@lists.torproject.org>; Sat,  2 Jan 2016 20:37:26 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mail.headstrong.de (Postfix) with ESMTP id 746001C001DC
 for <tor-talk@lists.torproject.org>; Sat,  2 Jan 2016 21:37:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=headstrong.de;
 h=content-transfer-encoding:content-type:content-type
 :in-reply-to:mime-version:date:date:message-id:from:from
 :references:subject:subject:received; s=mail; t=1451767041; x=
 1453581442; bh=clJ38dSE7TnOkyxOTNhrg9q1/AHmFozParws/aDwRbA=; b=Y
 p91G5LmLlcNyClx4MlFcI2JPtdznirfHaAyT/FRJXpCsmzqOv3335nOS7iKrZBJa
 MNK6BGdkdWtu80kjEGDJe8E1X6ajiYFI6PmaS8SePgVAi8sM22GaqOgn6fv2399n
 6OgeLF/9tj4sy3TFbCjDYyl4QgmZUeLaCfD8NPl62s=
X-Virus-Scanned: Debian amavisd-new at mail.headstrong.de
Received: from mail.headstrong.de ([127.0.0.1])
 by localhost (mail.headstrong.de [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id pnlT7it6wLaq for <tor-talk@lists.torproject.org>;
 Sat,  2 Jan 2016 21:37:21 +0100 (CET)
To: tor-talk@lists.torproject.org
References: <56880CDB.9070305@infosecurity.ch>
From: Moritz Bartl <moritz@torservers.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <568834FB.6070008@torservers.net>
Date: Sat, 2 Jan 2016 21:37:15 +0100
MIME-Version: 1.0
In-Reply-To: <56880CDB.9070305@infosecurity.ch>
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>

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.

-- 
Moritz Bartl
https://www.torservers.net/
-- 
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

