Delivery-Date: Sat, 25 Apr 2015 03:22:45 -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 3719B1E0A89
	for <archiver@seul.org>; Sat, 25 Apr 2015 03:22:44 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4F2F734BCD;
	Sat, 25 Apr 2015 07:22:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3724B34BB8
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 07:22:37 +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 FsYcjdBrT5YI for <tor-talk@lists.torproject.org>;
 Sat, 25 Apr 2015 07:22:37 +0000 (UTC)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com
 [IPv6:2607:f8b0:4001:c05::22c])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 14DBF34B87
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 07:22:37 +0000 (UTC)
Received: by igbyr2 with SMTP id yr2so31359537igb.0
 for <tor-talk@lists.torproject.org>; Sat, 25 Apr 2015 00:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=170VYeflrk+W0ie0elG0rYFJBnLUI1h247Db+DDZChw=;
 b=n50xPvdHQhEBAgE0izF0LNwkbm6ZD3bT+mHKope9QdWrnHrql6fWb2H5j83qYb7tMA
 1t4WWc2HpWY4smo6xF4NFDtXY5dMR6n4H67QI+pEdfgaisO4flAMvSpZj5Pk0u3Tg6N4
 394+BKPA50CeB7ZNlhO3L8GuSwy2jDPFjYRIMmTBYJxnC+CVMoDQpT/0NZ4Jd7pPSh2v
 agJFHUAm9KGlBm4pDskzni/+mDgjSwDrOVGUATfBEw1dhf0CLwrXsne8XRykUbxyowA+
 h9G4o05uE2wyLyH4Ay/sLhONbCmw77wFQC2h0mjfh9jPoLxIX17Sdev32n0DKMKOU5Ww
 MtTg==
MIME-Version: 1.0
X-Received: by 10.43.97.10 with SMTP id ci10mr2772909icc.23.1429946554861;
 Sat, 25 Apr 2015 00:22:34 -0700 (PDT)
Received: by 10.36.51.76 with HTTP; Sat, 25 Apr 2015 00:22:34 -0700 (PDT)
In-Reply-To: <553A7D20.9020102@openmailbox.org>
References: <553A7D20.9020102@openmailbox.org>
Date: Sat, 25 Apr 2015 03:22:34 -0400
Message-ID: <CAD2Ti28JdPk_smcQDGi5rtPBNox6H+OscnvOxakFRRrhY1paRA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] current policy on: giving entire families the
	badexit flag
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>

> if a single or multiple exit relays in a
> declared MyFamily do things that get them the badexit flag. Will other
> relays in that family also get that flag?
>
> One such example is the following family where 2 out of 3 got the bad
> exit flag (the ones that got the flag were probably shutdown since
> they are of no use to the attacker anymore):

A bad exit is a badexit. If someone's operating a bad family, especially
a widely distributed one, and plays quiet when their name is called on
these lists, I'd sink the whole family and ask questions later. An upstream
could be causing the bad exit, affecting some percent of the family from
0-100, so fault might not be the operator if they were narrow, but they're still
systems manager and hopefully able to fix or cancel the bad exit situation.
Probably have to look at the benefit to the net vs the severity of the nature
of the bad exit and its possible relation to the family and upstream.
A HS email contact is not unreasonable even for silent anon operators.
They can cover any issue in public or in private to badexit as desired
or at least receive reports. And are not the top bandwidth operators of
generally known, leading to not much impact if a sub 20% family gets
k-lined? So probably then safer to sink when in doubt.
-- 
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

