Bug overview description.
favoriting, voting on posts, and add to set have all been busted for me in Tor Browser

What part(s) of the site page(s) are affected?
The up/downvote, favorite, Add to Set, and Add to Pool links on any post page.

What is the expected behavior?

• Vote: show "updating posts" banner, then "posts updated" banner, with "up" or "down" colored.

*Favorite: "Adding post#12345", then "Added to favorites" banner

• Add to Set / Add to Pool: the list of eligible sets or pools should display.

What actual behavior is given instead?

• Vote: "updating posts" displays, then very shortly afterard "posts updated". However the up / down links remain neutral, and refreshing the page shows it was unsuccessful.
• Favorite: "Adding post#12345" appears, but it never proceeds from there.
• Add to Set / Add to Pool: A partial rendering of the Cloudflare "Please complete the security check to access e621.net" appears in place of the list.

Time of incident (if applicable).
Any time since about the last 2 months.

Can you reproduce the bug every time?
Yes, using Tor Browser 6.5.2.
I can also reproduce a workaround every time for Favorite and Vote
What steps did you take to replicate this bug?
Click on vote, favorite, or add set/pool links.
For reproducing the workaround for Favorite and Vote:

• Go to a post page
• Open Tor Browser's Network developer tool from menu button->Developer or ctl+shift+q
• Click favorite or up/downvote
• Click on the resulting "403" response in the Network developer tool's list.
• In its details pane, click "Edit and Resend"; the pane changes to "New Request" with text boxes showing the contents of the previous request.
• In the Request Headers textbox, replace the "Accept" line with

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

• click "Send"
• The response should be 200. No "adding post#12345" or other banner appears.

Refreshing the page should show up/down or favorite highlighted as when successful.

Errors or other messages returned (if any).
In all cases when the bug occurs, the response header is 403 Forbidden.

This is a Cloudflare thing. We can't fix all of it. High risk endpoints(endpoints that have exhibited abusive behavior in the recent past) may be prompted for verification before performing actions that it considers suspicious. Updating the browser used away from Firefox 45 in the tor browser bundle often resolves this issue. Hiding the referrer on background requests, omitting cookies, or trying to spoof the source IP through HTTP headers can also cause this to happen, as it considers them out of band requests, and highly suspicious.

Changing the accept headers to something invalid for the request is a temporary solution, it will switch to blocking the new pattern quickly enough.

Let's look at this from the moon, the same way CloudFlare does. It knows nothing about the site or the requests involved. The site receives a few million requests per day, about 5% come from sources that have been notable for breaking rules elsewhere in the system. It notices that specific pages are requested far more frequently, and often abusively(multiple requests per second for sustained periods of time.), and creates an automated fingerprint of the requests and blacklists them for manual verification. Now, say I change the accepts header. Now that 5% of requests is still happening, still from endpoints that are considered high risk and abusive. But now the request fingerprint has changed, just slightly, and the old one is no longer being seen. No other site has this behavior happen. Suddenly, you have a statistically significant portion of requests from known abusive endpoints making requests that bypass the filter. without a change in request behavior or pattern. Red flags everywhere, the filter is adjusted, new fingerprint is blocked. Now you have two fingerprints blocked.

As long as the requests are fairly unique and low volume, you don't run into trouble. When I make the change for everyone, it looks like an abusive crowd is evading the filter. I played with this on F-List and it just went back to being a 403 within a day.

P.S. Randomizing header values is HIGH LIKELY to get you temporarily blocked from accessing things through CloudFlare.

OK then. Thanks for the detailed explanation.

Guess I'll just keep on keeping on.

My personal recommendation would be to use a dedicated VPN instead of Tor for e621. AFAIK we SSL encrypt everything so Tor is really only useful for circumventing censorship or hiding your direct IP, both of which can be done quicker by using a normal VPN service.

KiraNoot said:
[...]

today i learned cloudflare considers me highly suspicious, along with my other programs with odd headers.