Delivery-Date: Sun, 07 Feb 2016 08:02:16 -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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY 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 731A61E0313;
	Sun,  7 Feb 2016 08:02:14 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2968D39926;
	Sun,  7 Feb 2016 13:02:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id CD24A398D7
 for <tor-talk@lists.torproject.org>; Sun,  7 Feb 2016 13:02:05 +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 aGDiZM406ZFK for <tor-talk@lists.torproject.org>;
 Sun,  7 Feb 2016 13:02:05 +0000 (UTC)
Received: from mail.potager.org (quatre.potager.org [91.194.60.100])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.potager.org",
 Issuer "StartCom Class 2 Primary Intermediate Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 9F7673957C
 for <tor-talk@lists.torproject.org>; Sun,  7 Feb 2016 13:02:05 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) with ESMTPSA id BACE2C311D6
To: tor-talk@lists.torproject.org
References: <5685200D.4020405@pimienta.org> <568850DD.9010601@whonix.org>
 <858u2xsa81.fsf@boum.org>
From: sajolida <sajolida@pimienta.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <56B74045.6020302@pimienta.org>
Date: Sun, 7 Feb 2016 13:01:57 +0000
MIME-Version: 1.0
In-Reply-To: <858u2xsa81.fsf@boum.org>
Subject: Re: [tor-talk] [Tails-dev] Persistent Tor start in Tails vs
 location aware Tor entry guards (LATEG)
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>

intrigeri:
> [can you please decide what mailing-list this discussion should happen
> on, and then we can stop cross-posting over 4 mailing-list?]

We're in a quite abstract cross-distro Tor discussion, so let's go for
[tor-talk].

> Patrick Schleizer wrote (02 Jan 2016 22:36:13 GMT) :
>> The documentation advice for advanced users caring about AdvGoalTracking
>> could be to use obfuscated [private] bridges and to alternate
>> them per travel location.
> 
> Right, I think it's important that people who what more control can
> get it this way, and IIRC our current best proposal does not prevent
> anyone from doing this.
> 
>> Or perhaps you might be able to explain in tor-launcher /
>> anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue.
> 
> If the configuration GUI has good facilities to document a broad and
> complex problem, yay, bringing the doc closer to the software is
> probably a winning strategy.

Unless I missed something, right now the entry guard concept is not
explained nor advertised to the user at all. As a user of Tor Browser or
Tails, the only wait to learn about entry guards is, first to be aware
of this behavior of Tor, and then to infer its status from the Tor
Browser circuit view or Vidalia in Tails.

If we think that the relationship between location and entry guard is a
meaningful information, for the mobile user for example, maybe the name
of the entry guard could at least be fed back somehow before the
connection takes place, in Tor Launcher or whatever connection process
will might come up with in Tails.

I'll keep this idea in mind while working on
https://tails.boum.org/blueprint/network_connection/. Thanks for the point!
-- 
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

