[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tor-talk] Protest Blocking Tor via CloudFlare
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
"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
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
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
A suggestion that I had not yet made was that CloudFlare could also turn
off CAPTCHA for naked GET requests by default (requests without
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.
tor-talk mailing list - email@example.com
To unsubscribe or change other settings go to