Delivery-Date: Fri, 16 Jan 2015 20:33: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.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	FROM_LOCAL_NOVOWEL,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,URIBL_BLOCKED
	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 578AF1E0A4D
	for <archiver@seul.org>; Fri, 16 Jan 2015 20:33:14 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 1370C32C3E;
	Sat, 17 Jan 2015 01:33:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id D34CA32AE2
 for <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 01:33: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 A09RANseqrvw for <tor-talk@lists.torproject.org>;
 Sat, 17 Jan 2015 01:33:05 +0000 (UTC)
Received: from mout.gmx.com (mout.gmx.com [74.208.4.201])
 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id AE94432ADE
 for <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 01:33:05 +0000 (UTC)
Received: from [127.0.0.1] ([99.190.181.188]) by mail.gmx.com (mrgmxus002)
 with ESMTPSA (Nemesis) id 0MgtK2-1YPXn41BLM-00M3k7 for
 <tor-talk@lists.torproject.org>; Sat, 17 Jan 2015 02:33:02 +0100
Message-ID: <54B9BBD2.9030505@gmx.com>
Date: Fri, 16 Jan 2015 19:33:06 -0600
From: Joe Btfsplk <joebtfsplk@gmx.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <327062943.20150115130813@denstarfarm.us>
 <54B82BB9.6090306@torservers.net>
 <20150115214248.2333BC0390@smtp.hushmail.com>
 <344955553.20150116064103@denstarfarm.us> <54B9676F.1050804@gmx.com>
 <20150116232821.60511C0106@smtp.hushmail.com>
In-Reply-To: <20150116232821.60511C0106@smtp.hushmail.com>
X-Provags-ID: V03:K0:6M9hGDoIHqmDGgLkraXv7QJISkprBpSKqv/3DBQD1dIvT1j9E06
 +tBsIGzgQ7YI23qTgmi/7zHEwgAYsz5BO1xO8O45YNTO8S9x1PPv4CHjkX/FVajzFpjeIyU
 3JEU7AwsdunJkMcegAKBmosLiGIapAMa4pThVywZ7IGnVo0C15ZwPwUP6sWYmb1JB7lI2rI
 ik48rD4E5bPML5tmD7pwg==
X-UI-Out-Filterresults: notjunk:1;
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Fox News bans my Tor Browser
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 1/16/2015 5:28 PM, l.m wrote:
> TBB's new identity feature is considered more anonymity safe [1].
> Vidalia's new identity doesn't consider how inter-tab traffic can
> identify you. It also doesn't consider how changes to the browser
> window make you unique (and trackable) across changed identities. TBB
> will close open tabs and shutdown any traffic that may cross
> identities. It also resets the browser window to some common size
> within Tor's user-base.
Yes, I'm sure Torbuttons' New Identity is more anonymous (safer) than 
Vidalia.
And I use it.  But what I find happens - more than a few times, when a 
site doesn't like an Tor exit (it's IP, or it's location), using New 
Identity often selects another circuit *very* similar to the previous; 
often definitely in the same country & similar IPa to previous one.  
When that happens, site still block Tor (fairly often).

UPSHOT:  When sites block or require captcha (captchas often don't work) 
from a geo-location or from a range of IPa's, clicking the New Identity 
button often doesn't fix anything.  But, I've found dozens or hundreds 
of times, it's not because the sites "block all Tor." It's because they 
block specific countries, IPs - or ranges of them.  Torbutton "New 
Identity" doesn't handle this very well, - from the aspect - of getting 
you connected to a site that blocked exits from specific countries.
I'm not sure of a better solution for this.

Just one example:  Say,  https://ixquick.com/ (or Startpage), requires a 
captcha.  Getting a new identity *often* doesn't remove the captcha 
requirement - but sometimes does.
I started looking at possible reasons why.  Using Vidalia (*ONLY* so I 
could see the circuit locations, IPa's, etc.).

It became clear, at times, that simply closing the existing circuit, 
then watching (in Vidalia)  the new circuit & exits - OFTEN in the same 
country, or had similar IPa,  still caused Ixquick (and MANY other 
sites) to still block or require captcha.  Captchas that may / may not work.

I notice the same thing using  "New Identity" button (while observing 
countries, relay names, IPs, etc. of the old & New Identity).
Repeatedly getting a New Identity often doesn't fix the blocking or 
presenting captchas.  On many sites.  I'm guessing it's often because 
the exit relay locations (countries) and / or IPa ranges, etc., are too 
close to the last one.

Often, if I Torbutton  new identities enough times in a row, that 
through ? luck of the draw?,  the exit relay geo-location and / or IPa 
range changes significantly, the sites then work fine.  Five successive, 
new identities - all w/ exits in "XYZ-stan(s)" countries may never allow 
access to a site.  Then work  immediately on getting an exit in Germany, 
US.  (Note:  I'm not biased against relays base on their country - but 
the sites blocking them are.)

Thanks for link / info on TrackHostExits & AllowDotExit.
Reading those command descriptions, sounds like they're useful mainly if 
you "must" access a site w/ Tor, but don't care so much about anonymity?
Which may be acceptable, depending on one's reason for Tor - on a given 
site.  Just as long as a user knows the risks.
>
> TrackHostExits host -- try to reuse exits for the host [2]
> AllowDotExit -- specify an exit to use with an address using dot
> notation [2]
>
>

-- 
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

