[tor-talk] Protest Blocking Tor via CloudFlare

[Aaron Gibson]

On 2015-03-11 05:58, grarpamp wrote:
> CloudFlare throws up a captcha with a comment field
> for a message that goes to the site owner.
> So all Tor users fill in the comment, with
> perhaps even the same generic message...
> 
> "Stop blocking us."
> Which naturally makes site inquire their logs to see who
> "us" is, and as byproduct discovers that your clickstream
> was actually legit and not whatever they thought they were
> blocking.
> 
> or
> 
> "I'm a Tor user, stop blocking me."
> Which is more informative and personal.
> 
> It would seem someone here could write
> FF/TBB greasemonkey for those too lazy to fill in
> that field.

Well, the catch here is that CloudFlare doesn't allow their free tier of 
users to disable the CAPTCHA completely, so there isn't a lot that site 
operators can do except complain to CloudFlare.

I've made a few suggestions to CloudFlare engineers, who are interested 
in improving CloudFlare experience for Tor users. You might recall the 
infinite-captcha-loop bug that existed for Tor users -- that seems to 
have been fixed. Thanks!

The suggestions I made were:

1. Web applications that can differentiate between GET and POST methods 
for reading vs submitting content should be able to configure at the 
request-method granularity whether or not a CAPTCHA is served. I offered 
that we could write a blog post to educate site operators how to use 
this option.

2. CloudFlare should ensure that they have presence within AS or 
datacenters where Tor Exits are present, and that their GeoDNS correctly 
points requests from Tor to the nearest cache endpoint. I don't know if 
anyone has measured this, but it should be straightforward to do so. 
This has a few upsides for both Tor users and CloudFlare. The first is 
that request latency for Tor users would be improved, and the second is 
that egress bandwidth costs could be reduced for both the Exit operator 
and CloudFlare (assuming that traffic within a datacenter or AS is 
counted separately).

A suggestion that I had not yet made was that CloudFlare could also turn 
off CAPTCHA for naked GET requests by default (requests without 
parameters).

One problem that CloudFlare CAPTCHA has caused for the OONI 
(https://ooni.torproject.org) project is that we use Tor as a control 
measurement for users who are trying to evaluate censorship in their 
country. Some of ooni-probe's tests (such as http_requests) make two 
requests, one via Tor and one without, so that the user can be given an 
indicator of whether censorship might be happening in their country. 
Unfortunately, CAPTCHA breaks that comparison. Now, we collect samples 
from a variety of locations, and CAPTCHA isn't served for every request 
- so a researcher can filter the CloudFlare CAPTCHA from the dataset 
fairly easily, but it increases our false positive rate and reduces the 
usefulness of the tool to end users who want to know what things are 
being censored in their country. We don't normally test URLs with 
parameters, and most sites probably won't suffer from spam if simple GET 
requests are permitted, but it would definitely improve the quality of 
the measurements we make.

--Aaron