Ask HN: Is your Firefox blocked by Cloudflare in recent weeks? (e.g., Gitlab)
This was merely annoying until now, in a "guess I won't be reading that article or trying their site, after all" way, but I can't log in to an actually important site, GitLab.
Even when I disable both uBlock Origin and Firefox "Advanced Tracking Protection", I'm still blocked from GitLab by CloudFlare.
Testing with Chromium (same residential IP address as Firefox) in a "please violate me in every possible way" configuration, CloudFlare doesn't block me from GitLab.
But I really want to use Firefox for GitLab, and my Firefox doesn't have trouble with non-CloudFlare sites. For example, GitHub works fine with my Firefox. (But I'd really prefer to use GitLab, so long as this problem can be resolved and I'm not going to run into problems like this.)
I see a various complaints about CloudFlare blocking GitLab online, with various explanations. Sometimes, the user is blamed for not figuring out how they're not complying with whatever CloudFlare is trying to do (like the user is some divergent citizen, to be denied rights, in some Kafkaesque authoritarian police state).
I suspect that sites don't know when CloudFlare is false-positive blocking legitimate visitors and costing them customers...
36 comments
[ 3.2 ms ] story [ 79.7 ms ] threadSo let them know. Put a value on it too. Then maybe they’ll be more careful in dismissing “false positives” as a business cost (especially for someone like GitLab competing for business).
There is no way to actually know who is or isn't a bot. The methodology for bot detection changes dramatically, isn't published, often isn't well tested, and fails to fully capture turing tests in any meaningful way. Its all about forcing more requirements on the user, where the more unique the user is, the more likely its a user and counting all blocks as a net win. The only problem is it drives surveillance capitalism, and its a flawed assumption.
Maybe you should start an end-user Firefox extension/platform that aggregates where it checks for these, and allows the user to self-report when it fails (or detect and show repeat failures.
I'm using latest Firefox on Linux, with advanced tracking protection as well as uBlock Origin and uMatrix for good measure. The latter isn't configured to turn itself off on Gitlab.
for instance i have noticed the same on the chatgpt page. I have to "verify" a lot which is just another sign for "we are overloaded at the moment"
At least thats how i interpreted it so far. Im using Ferdium which has integrated firefox
[1] Exceptions being mobile, if I am specifically testing something and certain work situations where I am currently testing a locked-down web browser called "island"[2] which seems to be a chrome fork which gives Enterprise IT control over a bunch of stuff.
[2] https://www.island.io/
I guess it will provide capabilities to add AD's group policy object like mechanisms to the browser.
I don't think the threat model is it's expected to prevent intentional attacks by a hostile, skilled, priviledged insider put it that way.
I'm not recommending it or anything but so far the browser doesn't seem terrible. It seems to work just like chrome, and I haven't had any problems or noticeable examples of it stopping me from doing anything fwvliw. I'm not trying to circumvent anything or do anything that I'm not actually expected to do as part of my work though so I wouldn't expect problems.
You should blame Gitlab too, they configured it.
Why do you use an out-of-date browser?
Something that Chrome is unwilling to support.
Edit: I assume you're using it in the "Good 'ole Firefox" sense?
I have no idea what the problem was, but the “verify you’re human” thing never worked. Pretty annoying…
...odd isn't it?
I did take the rather unprecedented approach to blocking all DNS traffic to anything but our router (because Android was ignoring my DNS settings and using its own... ), breaking my internal dns resolution. Making DNS queries wonder from JS would be new to me... (I didn't think that was possible).
I'll dig more tonight.
I can get on gitlab.com and get to their sign in page (which does the Cloudflare check), but it lets me see the login page. I don't have a GitLab account so that's as far as I can go. My own website uses Cloudflare too, so I put the security to "I'm under attack", and tried it. That works too.
I tried in Firefox (with uBlock Origin) and Edge (without). Same results across all three.
From what I can tell, the site that fails only sends and receives to that domain, ruling out a tracking domain I've blocked. It sends out multiple "rays", with what looks like an encrypted payload (and no I'm not reversing the JS, it's heavily obfuscated). There is no response to any of them, the connection is terminated.
On GitLab, which works, one of the rays fails with a 401, but the rest succeed.
Hopefully someone that works at Cloudflare can figure this out for us...