[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor and Google error / CAPTCHAs.

Hash: SHA1

This has been a great thread, with many insightful comments. I'm going
to pick some key conversations. One, between grarpamp (GP) and Alec
Muffett (AM) on why websites discriminate broadly against Tor traffic.
For simplicity, I'm not preserving temporal order.

GP> In such circumstances they are not actually looking at you /
GP> what you are searching for. They are looking at the behaviour
GP> of all traffic, of everyone and everything else which emanates
GP> from that exit node.

AM> In my experience the "blocking" that companies do to Tor (and
AM> similar) is 100% grounded in the threats from spam, scraping,
AM> testing phished credentials, and other forms of bad behaviour.

AM> An organisation's response to scraping seems typically the
AM> product of:
AM> 1) the technical resources at its disposal
AM> 2) its ability to distinguish scraping from non-scraping traffic
AM> 3) the benefit to the organisation of sieving-out and handling
AM>    the non-scraping traffic, rather than ignoring it all

GP> And for account based services, I expect far more...
GP> We want the accounts, without phone.
GP> Then I want graduated service enablement based on human
GP> pattern heuristics... participation, length of time, kbd /
GP> click data, backoffed captcha intervals, bitcoin deposit
GP> with automatic return schedule, user realness ratings by
GP> other users, etc.

AM> The issue is that "authentication" and "deanonymisation" are
AM> from many practical perspectives **exactly the same thing**.

GP> But in the nym space we must respect wish not to authenticate
GP> to IRL, that from the user perspective, they have valid use
GP> of the service contexts that do not require it, and for which
GP> it is bad.

Both Seth Schoen (SS) and meejah (MJ) have noted the danger of
collecting and retaining communication data and metadata.

SS> Some of us privacy advocates have felt that it's quite bad
SS> that communications technologies generate location and
SS> association metadata in the first place.

MJ> I think it's kind of dangerous to assume whole classes of
MJ> information will *never* be interesting -- if you don't
MJ> anonymize at the source, they'll be recorded forever
MJ> (approximately)."

It doesn't look good. James Anslow has noted: "Isn't there merit to
the idea of moving as much over tor as possible so as to work towards
dispelling the myth of tor as a network that only transmits
questionable traffic?" That seems unlikely. Maybe media torrents and
streaming will migrate to Tor onion services, driven by increasing
difficulty of hiding in the clearnet, especially as we move to IPv6.
But that won't affect Tor exit traffic. And, as hard as Tor Project
beats its drum, I doubt that there will mass uptake. If for no other
reason, discrimination against Tor users breaks too many sites. So who
would bother, unless they have some strong motivation?

There's also a great thread in tor-relays about a recent request from
a hosting provider for a Tor exit to block malicious traffic with IPS:

There are similar discussions among users of VPN services. Netflix and
other streaming sites are getting better and better at blocking VPN
users. Forums and blogs are getting better and better at blocking
comment spammers who use VPN services. Ditto for market research and
other legitimate business purposes. Bottom line, it's easy to create
lists of VPN exit IPs, and those IPs generally belong to data centers.

DDoS operations all use botnets. Some proxy services do as well. And
then there are "voluntary botnets" like Hola/Luminati. Hola is a
"free" VPN service, that routes users' traffic through other users'
uplinks. The Luminati "Business Proxy Network" sells access to
millions of Hola users' uplinks for $250 to $6000 or more per month,
depending on IP type and traffic limits. I gather that there are other
such proxy networks. Some may also leech off free VPN services. Some
may be driven by other malware, more like traditional botnets. Maybe
some rely on fraudulently obtaining residential ISP services.

Any of that could be grafted to Tor. Maybe not for exit relays,
because they would arguably get banned for malicious behavior. But
there are other ways out of the Tor network. Basically, an onion
service can serve as a clearnet gateway. For example, see my guide for
using an OpenVPN onion VPS to evade discrimination against Tor:

More generally, onion VPS can be linked via OnionCat, and some of them
can serve as disposable VPN exits. There's also the possibility of
routing traffic through I2P, just to add some confusion. For example,
see https://www.reddit.com/r/I2VPN/

But of course, those exits all have data-center IPs. However, if
discrimination against Tor and data-center IPs becomes intense enough,
that will create a niche for anonymity services that route traffic
through residential uplinks. Rent-seeking means that it's criminals
who will exploit that first. Maybe they already are.

And so it's worse than a Catch 22 about increasing Tor use in the face
of blanket discrimination. As users -- and most importantly, criminals
- -- find it harder and harder to use Tor and other proxy networks, they
will move to systems using residential IPs as exits. And as those IPs
are blocked, other IPs will be obtained and exploited. In the end, all
or virtually all IPs will arguably emit malicious stuff. So blanket
blocking will fail as a strategy.

So maybe there is a benefit of blocking behavior, rather than IPs?

Version: GnuPG v2.0.22 (GNU/Linux)

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to