1. Can you provide better documentation for your customers about what Tor is, and reasons for/against white/blacklisting Tor? For example, when a customer selects to Block or Captcha Tor, a tiny link could show up somewhere that says something like "This affects users who seek privacy, find out more."
I'll make sure the product team sees that suggestion.
2. In addition to better docs, can you setup something that lets site operators view the site as a Tor user?
That seems like an enormous amount of work when anyone can just get the Tor Browser and test it out.
3. The latest CloudFlare blog post on Tor says "you can do a lot of harm just with GETs." I wish you would give more thought to the idea of a read-only option for non-whitelisted Tor users. If GET requests are harmful (I'm skeptical), reducing the harm of GET requests seems like a much easier problem than the overall problem.
If you read the Trac thread you'll see that I've answered that. In short, I don't want to do it because that diverts engineering resource away from the right thing to work on (which is reduce the need for CAPTCHA).
> If you read the Trac thread you'll see that I've answered that. In short, I don't want to do it because that diverts engineering resource away from the right thing to work on (which is reduce the need for CAPTCHA).
I agree, but thinking about GET-only requests is one approach to reducing the need for CAPTCHA. For example, maybe CloudFlare could have better Tor defaults for sites that are serving only static content, and default to Captcha for sites that are POST-heavy (just a high level idea).
Basically, most of the time, GETs have nice properties: idempotent, pure, etc. I think a solution to the captcha problem could take these into account.
I do not think the other solution proposed in the CF blog post, using proof of work with some sort of blinded tokens, is going to work well. A hashcash style proof-of-work is easily defeated with a botnet or FPGA, and reputation-based systems are an ongoing research area.
It's possible there is a silver bullet that we haven't found yet. Have Tor or CloudFlare considered putting out a call for research into the problem?
I agree, but thinking about GET-only requests is one approach to reducing the need for CAPTCHA. For example, maybe CloudFlare could have better Tor defaults for sites that are serving only static content, and default to Captcha for sites that are POST-heavy (just a high level idea).
To be honest I'm not interested in solving the CAPTCHA problem just for Tor. That doesn't make a lot of sense. What I am working on is an overall solution so that the need for CAPTCHAs at all is diminished.
> What I am working on is an overall solution so that the need for CAPTCHAs at all is diminished.
I like that idea, but my worry is it will take years to reach that point, and in the meantime Tor/VPN users will just have to suffer. I'd rather see some short-term fixes now and long-term solutions on the horizon.
I admit: I have not read the entire Trac thread, so I'm not sure what your current roadmap is.
>> 2. In addition to better docs, can you setup something that lets site operators view the site as a Tor user?
>
> That seems like an enormous amount of work when anyone can just get the Tor Browser and test it out.
Sure, but most site operators aren't going to get the Tor browser to test it out -- especially if they don't realize that that is something they should do.
By "view site as Tor user" I simply meant having a way for site operators to interact with the captcha page that CloudFlare presents users. That should be easy to setup; it can even be just a static HTML page that's linked from the documentation on Tor. I didn't mean that you should display the page through Tor.
But Tor users are complaining about the specific situation where the Tor Browser is used. I don't think that's easy to simulate (or at least I think it's easier for people just to get the Tor Browser).
Tor users are complaining about the captchas. I'm not sure why you think it's so hard to create a sample captcha page to demonstrate the experience. You just need two pages: one with JS-enabled captchas and one with JS-disabled captchas. Do you need me to do this for you?
Alternatively, you can create a dummy CloudFlare instance with /0 under Captcha, and put the URL to this in the docs, but this wont let users try the JS-disabled captchas.
The only difference between this demo and the actual Tor experience is that over Tor, these pages load more slowly. But people are more annoyed at seeing the captcha in the first place, not the fact that they sometimes load slowly...
Tor users are complaining about the captchas. I'm not sure why you think it's so hard to create a sample captcha page to demonstrate the experience. You just need two pages: one with JS-enabled captchas and one with JS-disabled captchas. Do you need me to do this for you?
It's not that simple.
reCAPTCHA makes an on the fly decision about the strength of the CAPTCHA served depending on the visitor. In the case of Tor there's no visitor information other than IP address (and whatever the browser gives as User-Agent etc.).
So, I can dummy up a CAPTCHA page trivially, what I can't do is dummy up the experience of a Tor Browser user hitting a reCAPTCHA. The way to do that is run the Tor Browser.
I'll make sure the product team sees that suggestion.
2. In addition to better docs, can you setup something that lets site operators view the site as a Tor user?
That seems like an enormous amount of work when anyone can just get the Tor Browser and test it out.
3. The latest CloudFlare blog post on Tor says "you can do a lot of harm just with GETs." I wish you would give more thought to the idea of a read-only option for non-whitelisted Tor users. If GET requests are harmful (I'm skeptical), reducing the harm of GET requests seems like a much easier problem than the overall problem.
If you read the Trac thread you'll see that I've answered that. In short, I don't want to do it because that diverts engineering resource away from the right thing to work on (which is reduce the need for CAPTCHA).