Cloudflare blocking Pale Moon and other browsers
theregister.com
theregister.com
Seeing https://news.ycombinator.com/item?id=43321145 and https://news.ycombinator.com/item?id=43322922 also showing up in a close timespan to this makes me really suspicious that there was some part of a hidden plan to close off the Internet which suddenly took a significant step.
a kludge might be better than none. And it's an easy kludge (for the site owner - a checkbox in cloudflare).
The fault lies with cloudflare implementing a lazy bot detector.
WTF?
Building a WAF that has zero false positives and zero false negatives is impossible. All we can ask is that the companies that build WAFs be responsive, but they also need accurate bug reports with sufficient information to identify the variable.
> Designing a site to not be affected by bots is fixing the problem.
Bots footprint is minimal and shouldn't affect your site performance.
- scraping & content theft
- spam & fake engagement
- DDoS attacks
- Ad fraud
It is definitely always possible.
> may not be affordable
You hired the wrong person / people, then.
> may degrade the overall user experience
Which is exactly what Cloudflare does, although most people would make a distinction between degrading an experience and outright causing something to not work at all.
Care to provide details or source?
If you add additional piece to chain, chain becomes weaker, not stronger
> get AI-DoSed
Thats not that common. There are specific industries prone to DDoS, like gaming, but your average site don't get DDoS-ed. Then again CF free service really don't protect your site from DDoS. I have seen several times CF becoming source of DoS (not caching or denying malicious requests) and if back-end is on shared infra, CF goes to firewall.
> will have an expired cert.
Your back-end still needs certificate
Show site owners cloudflare isn't doing the job they are paid to do.
If it is advantagious to lie about the client, the client will lie, and the server will know this and not trust the client's headers.
Blocking or restricting based on other metrics should be the way to go - for example, shape traffic based on the speed and frequency, such that bots gets shaped but users' dont (because they're slower etc). It aligns properly with the desire to stop bots.
In the past it was definitely useful for some things. To use as an example something I was involved with, many years ago: if you were deploying software via ClickOnce and needed a particular version of .NET installed, that information was exposed in the user-agent string, so you could tell the user “you need to go install this other thing first”, rather than saying “try this, and if it doesn’t work in one of these ways, check if you’ve installed this”.
These days, it’s not often useful, and feature detection is highly preferable where possible, but platform detection (whether via user-agent string or properties like navigator.platform) is still definitely useful, for things that should be tied to what the platform actually is. For example, on a download page you want to know what the OS and architecture are in order to recommend the appropriate file to download for that machine. Or, when implementing keyboard shortcuts, Apple platforms use metaKey (⌘) instead of ctrlKey (⌃), and visually present the shortcuts differently too, such as ⌘⌥⇧⌫ or Command-Option-Shift-Delete, compared with Ctrl+Alt+Shift+Backspace for everyone else.
see: https://blog.castle.io/anti-detect-browser-analysis-how-to-d...
Wait, what? Were they not submitting a fake agent before? What's the benefit to the user or the browser of submitting a novel user agent string?
25 years ago it was necessary to pretend to be MSIE. Then IceBrowser, a Java based browser, was doing that. But one of the customers for the company asked to provide a way to test for IceBrowser as the browser did not emulated MSIE properly in some cases so they wanted to provide a workaround. So a JavaScript-based test was provided. Then in couple of years a common JS library for browser detection had started to include that test and the test has to be disabled.
Then there was a story about Vivaldi browser from 5 years ago. Due to a bug in keyboard-only navigation there was an issue on google.com and apparently Google has implemented a workaround based on user-agent sniffing before the bug was fixed. Then, when Vivaldi fixed the issue, the fix broke google.com as Google was unaware that it should disable their workaround. That was the last straw forcing Vivaldi to fake the user agent by default.
For a company that has so many of their employees on this site, they sure do seem to be clueless when their supposedly amazing tech marginalizes people or otherwise creates issues. Even when they respond in these threads, it takes ages for them to address things, and often the problems are never permanently fixed and come up again after some time.
It reminds me of this fortune(6):
As far as we know, our computer has never had an undetected error.
-- Weisert
Perhaps fans of Cloudflare will downvote instead of engage, but that's almost a given these days. Let's be real - Cloudflare has been given a free pass for far too long. If you disagree and REALLY believe that there're technically valid reasons for punishing people who use non-mainstream browsers, try to actually engage and discuss. I'm truly interested in someone's take about why we're doing something wrong by not using what everyone else is using.The real issue isn't just Cloudflare - it's the centralization of web infrastructure that creates these single points of failure for browser diversity. Alternative browsers aren't just about personal preference - they're essential for innovation and preventing technological monoculture. We should be demanding transparent criteria for what constitutes "suspicious" behavior rather than accepting black-box filtering.
[1] https://developers.cloudflare.com/bots/plans/biz-and-ent/#he...
I get the fastly transient every time I use it.
That's what'll trigger the CF captcha as well: if you don't give up client data. Run a site on Chrome bundled with your Anroid? Never going to get captcha, since Google will gladly serve any of your data when it's asked.
"According to some in the Hacker News discussion of the problem, something else that can count as suspicious – other than using niche browsers or OSes – is something as simple as asking for a URL unaccompanied by any referrer IDs. To us, that sounds like a user with good security measures that block tracking, but it seems that, to the CDN merchant, this looks like an alert to an action that isn't operated by a human."
The one about Pale Moon from 2015 suggests the user did something custom and it was seen by CloudFlare (which is acting as a WAF) as something like an SQL Injection[1].
All of the CloudFlare hate on this site is tiresome and borders on Crying Wolf.
Websites aren’t forced to use it. It’s affordable and gives DDoS protection. If reducing false positives for bot/malicious traffic detection were more reliable, this would already be solved.
Google's still got it in their search results:
https://www.google.com/search?q=https%3A%2F%2Fcommunity.clou...
The math doesn't care about our freedom of choice. Tech savvy users making alternative choices on their web experience are an extreme minority in the sum total of HTTP requests. But the outcome is the same: a narrowing web where only mainstream options function reliably.
The ironic part, as everyone here understands, is that those who actually understand technology enough to use alternative browsers or privacy tools are the ones getting locked out. We're punishing ourselves for our technical literacy by implementing these strategies at these companies. And it really does help the average person who does not think about their browser choices.
What I'm saying is that there are more people (who are not tech savvy) not using Chrome than you may think. But you'd never know from the statistics. The collection method for the statistics is inherently biased.