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 -- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk