Cloudflair is making life for TOR contributors unnecessarily hard

Hello!

It’s come to our attention at OpenMW that many of our TOR based contributors are having difficulties with Cloudflair’s draconian security measures with Gitlab.com (SaaS). Even just reading and following up on issues is now a chore in that every 30 minutes they have to solve impossible CAPTCHAs and this really hurts our work-flow.

It’s getting to the point that they are mumbling that we should enable two-way mirroring with Github so they can contribute there, but this still leaves the issue of them being unable to read and contribute to our issue tracker.

Is there a way to ease this back, or are there tricks that can be used? The amount of CAPTCHAs is really rediculous when all the contributor wants to do is contrib anonymously to their passion project.

Cheers,
Bret

I guess they are using TOR because they are worried about their IP address. Could they not use a VPN solution instead? Maybe it would be tolerated more.

A Cloudflare blog article on the troubles with TOR: https://blog.cloudflare.com/the-trouble-with-tor/ explains a bit more why you are most likely experiencing more problems with captchas etc because of the way TOR is used.

The only other thing, is onion routing can be enabled in Cloudflare, to make it easier for TOR users, but that’s a choice for Gitlab to make: https://blog.cloudflare.com/cloudflare-onion-service/ perhaps it is enabled and there are problems from time to time, but I don’t know, pure speculation.

Thanks @iwalker for replying.

It’s much worse than that as CF also does browser fingerprinting and many of our contributors are very privacy minded, with good reason. So many of their browser settings are setup in such a way to be ‘clean’. This of course triggers CF in many other ways as well.

I guess there needs to be a larger discussion about Gitlab’s reliance on Cloudlfare and if it is really necessary.

Quoted from one of our contributors:

My main gripe with the kind of evil techniques employed by CF isn’t that
they’re doing these, I understand this helps with spam and bots and what
not. But they’re doing this indiscriminately to everyone even just wanting
to read the d**n website, and we know of the 95% rule or whatever it was
called stating that only small percentage of citizens will actively
participate in a community. So the majority of citizens will never speak
up, and you don’t tend to hear about them unnecessarily being prevented
“access to the web property” (what a stupid term). In contrast, the logged
in and actively participating users are more likely to have accepted
cookies from Google et cetera, and won’t ever notice anything amiss.

This has been going on years and pointed out by the Tor project ad
infinitum, but CF refuses to take any responsibility. It’s awful.

I use Cloudflare, have onion routing enabled, and my site is still accessible behind cloudflare using TOR. I even disabled onion routing, and it was still working.

Attempting to go to gitlab.com and login I constantly get the 5 seconds “checking your browser” screen and it’s been doing that for minutes now. So it’s not a total problem with Cloudflare. Cloudflare does work with TOR. Obviously there are some other settings that relate to checking browser settings within Cloudflare, that are causing the issue here with them being really sensitive. I expect it to be the User Agent Blocking rules, as I cannot really find anything else in the Cloudflare settings that are obvious for that. Either that or the Bot Fight mode option.

My account has only the defaults set for that, so perhaps Gitlab has more restrictive. They obviously did it for a reason for security. And obviously there is a balance between security and inability to use a system that needs to be chosen carefully.

I believe it is necessary to use Cloudflare, or whichever CDN you prefer, it just needs to be configured properly. The benefits far outweigh the negatives of not using something like Cloudflare.

1 Like

@iwalker I totally agree and I use CF for a number of smaller projects I work on but with very low settings since they are mostly FOSS things and their CDN helps mitigate bandwidth costs. I, thankfully, have not yet had to deal with DDoS and other not so nice things.

Would someone then @gitlab then be able to respond? I understand that a solution would be to self-host, but that seems to be a drastic step in order to just be able to use a project’s issue tracker. Is there a possible way to strike a balance between anonmity and security?

For example, even using an VPN will still trigger CF’s safeguards if the browser is setup to be clean. So it isnt necessarily a TOR issue. Like disabling or spoofing your user-agent field, disabling or intercepting certain javascript calls that would return information about your browser and OS. People who use https://www.whonix.org/ for example are constantly triggering these events on CF protected sites yet these are championed by the likes of: Wired, The Gaurdian, AT&T and Edward Snowden himself.

It shouldn’t have to be this hard or difficult when all you wish to do is donate your time and help a FOSS project.

Today is working in Tor Browser. I expect a lot of this to do with issues Cloudflare were experiencing yesterday in certain regions. Their status page does show some re-routing in some areas https://www.cloudflarestatus.com/

We have a web application which has experienced problems in the past, and when I find issues trying to access it, I use a VPN to switch to a region without issues and check again. If access is working, then I know there is an outage. Since no-one can guarantee outages, they have to be accepted. Cloudflare are generally very good at resolving their issues quickly, but some issues do take a bit of time and is to be expected.

2 Likes

Awesome! Thx for sharing! :slight_smile:

@gitlab-team this issue has been persist for last 2 weeks. Using Tor Browser and new Tor circuit many times still cycle of “Checking your browser before accessing gitlab.com