SoylentNews is people
SoylentNews
For the third time in recent memory, CloudFlare has blocked large swaths of niche browsers and their users from accessing web sites that CloudFlare gate-keeps. In the past these issues have been resolved quickly (within a week) and apologies issued with promises to do better:
2024-03-11: Cloudflare checks broken again?
2024-07-08: Cloudflare checks broken yet AGAIN?
2025-01-30: Cloudflare Verification Loop issues
This time around it has been over 6 weeks and CloudFlare has been unable or unwilling to fix the problem on their end, effectively stalling any progress on the matter with various tactics including asking browser developers to sign overarching NDAs:
Re: CloudFlare: summary and status
Some of the affected browsers:
• Pale Moon
• Basilisk
• Waterfox
• Falkon
• SeaMonkey
• Various Firefox ESR flavors
• Thorium (on some systems)
• Ungoogled Chromium
From the main developer of Pale Moon:
Our current situation remains unchanged: CloudFlare is still blocking our access to websites through the challenges, and the captcha/turnstile continues to hang the browser until our watchdog terminates the hung script after which it reloads and hangs again after a short pause (but allowing users to close the tab in that pause, at least). To say that this upsets me is an understatement. Other than deliberate intent or absolute incompetence, I see no reason for this to endure. Neither of those options are very flattering for CloudFlare.
I wish I had better news.
(Score: 1, Interesting) by Anonymous Coward on Monday March 17, @09:09PM (5 children)
And archive.org (and its various other instantiations, e.g., archive.ph, etc.) hits me with a CAPTCHA every single time now.
I don't think it's Firefox though. I expect it's the ad/tracking blockers, including the pi-hole on my home network.
What a shame.
Although IIUC, how heavy-handed a site might be is a function of how strict Cloudflare's *customers* want to be WRT verification. Which doesn't excuse the bugs in Cloudflare's tools.
(Score: 0) by Anonymous Coward on Tuesday March 18, @12:02AM (4 children)
archive.ph (and the other aliases for archive.today like archive.is, archive.ph, etc.) will give you a fake cloudflare captcha screen if you use cloudflare's public recursive dns resolver, 1.1.1.1 aka one.one.one.one. It is setup to be an infinite loop, to piss off visitors and generate complaints (incorrectly) to cloudflare.
It's believable since cloudflare captcha/turnstile is so damn broken already.
E.g., firefox DoH setting defaults to using cloudflare.
(Score: 0) by Anonymous Coward on Tuesday March 18, @04:40AM (3 children)
I don't use Cloudflare's DNS or anyone else's. I use my own, local (on hardware in my physical possession) recursive resolver. As such, I query Archive's authoritative name servers, not cloudflare's, not google's. Just the root servers, then the authoritative servers for the various archive sites.
It's possible that the archive sites are doing this themselves, but the captchas started around the same time lots of folks were making noise about Cloudflare's heavy-handed tactics. As such, it seems that archive may well be behind Cloudflare's "Anti-DOS" wall.
I'll be years dead before any system of mine uses DoH. Whether from Cloudflare, Google or anyone else. It's just another way for Cloudflare, Google, et. al to gather even more data on their users^W product. No thanks.
(Score: 1, Troll) by datapharmer on Tuesday March 18, @10:33AM (2 children)
Which is why I as your evilcorp isp operator I have added some very special routing rules for your connection that send your root server requests to some alternative servers I control to make sure you get the very “best” answers for who is authoritative for the domains you are interested in.
Thank you for choosing evilcorp.
(Score: 0) by Anonymous Coward on Wednesday March 19, @12:13AM (1 child)
AC you replied to here.
My ISP (AS131279) doesn't do any of those things. They are good stewards of privacy and use freedom.
So fuck off, whitey!
(Score: 2) by janrinok on Wednesday March 19, @08:33AM
Perhaps you don't realise but AS131072 - AS132095 (all quoted as being in the block used by your ISP) are shared by multiple VPN providers. They don't each have their own privately owned network of VPNs. Rather, they pay for VPSs as they need them. They can be allocated dynamically. This passes the hardware management task to another company and enables the original ISP to minimise running costs by only paying for what they need. kolie has a much better knowledge of this sort of thing than I do (it is part of his business) and this is only my description based on limited knowledge. Our own SN servers must be peered to other (multiple) servers to ensure that the internet can route around 'damage'.
Your chosen ISP might be the paragon of virtue, but the others you know nothing about. The administration of your chosen provider may be wonderful. It will probably secure your personal data if it holds anything at all, but there will at least be an account identifier, a hashed password, and a date that the account currently lapses otherwise they cannot identify who has paid to use their services. But the chances are that it will also have the records/logs of whoever it is peered to.
if you do a "whois AS131279" for the provider you quoted you should then read down the page:
North Korea - a well know provider of safe and secure internet services. They are actually managing the VPS that your connection goes through. Of course this will probably not be who you are paying as your ISP. The unfortunate thing is that you don't get to choose which VPN server your connection goes to, you can only choose your ISP and request a VPN in a given region. Your ISP will have decided the peering to suit itself. Your request will be routed to a VPS that is managed by someone else entirely.
AS131279 may have many thousands of IP addresses available to it, but they are all managed by the same company.
[nostyle RIP 06 May 2025]