The developer in me hates what #CloudFlare's anti-bot checks are turning the web into. As a blind person, I'm occasionally frustrated at having to obtain an accessibility cookie to bypass the CAPTCHA. My inclusive design/accessibility professional side hates that those cookies have to be obtained in a way that doesn't fully respect privacy.
But simply as a human, what I find most objectional of all is CloudFlare's "Checking if the site connection is secure" messaging. That sounds like a good thing; how nice that this site is looking out for my protection as a humble web user! When in fact, my activity and circumstances are being checked against an arbitrary set of requirements and baseline-level metrics, to determine if I have the right to go where I want to go. It has nothing to do with security, and everything to do with information lockdown.
Of course, CloudFlare's lawyers probably signed off on this copy as being just close enough to the truth. They are checking that the site connection is secure... against bad actors. Which they may very well find to be you if they can't prove your human nature beyond reasonable doubt, so watch out.
With recent events, i have taken the decision to drop #cloudflare with the transition to new servers, i'll have to figure out what CDN (likely fastly ill try to apply for the foss program) to use and what DNS service to use also we'll have to move to a different S3 provider
During the transition to new servers TransFem.social, and all other TransFem.org services including the Sharkey repo's may experience a down time of up to 48 hours due to DNS nameserver changes
The original decision for using Cloudflare was to prevent spam and ddos attack, and while Cloudflare has done shit in the past the assumption was that they're neutrality would go both ways, this seems to not be the truth, their "neutrality" seems to only apply to harassment sites like kiwifarms.
our new setup is not only a lot more powerful but also comes with a firewall setup and DDOS protection directly from the Colocation provider severely reducing the need for Cloudflares ddos protection
I'm targeting next weekend as deployment date for the new servers, but this is highly depended on the RMA's arriving on time
For a very small instance with only a couple of concurrent users a CDN might not make much difference. But if you take a look at your web server logs you’ll quickly notice that every post / like / vote triggers a storm of requests from other instances to yours, looking up lots of different things. It’s easy to imagine how quickly this would overwhelm an instance once it gets even a little busy.
One of the first web performance tools people reach for is to use a CDN, like Cloudflare. But how much difference will it make? In this video I show you my web server logs before and after and compare them.
The short answer is – before CDN: 720 requests. After CDN: 100 requests.
Usually just turning on a CDN with default settings will not help very much, you’ll need to configure some caching rules or settings. By watching your server logs for a while you’ll get a sense for what needs to be cached but check out mine for a starting point:
Beware of caching by URI Path because often fediverse software will return different data depending on the Accept header that the requester sets. For example, on PieFed and Lemmy instances a request by a web browser to /post/123 will return HTML to show the post to someone. But when that same URL is requested with the Accept: application/ld+json header set, the response will be an ActivityPub representation of the post! You don’t want people getting activitypub data in their browser and you don’t want to be serving HTML to other instances. Once you spot a URL you want to cache, use a tool like Postman to set the Accept header and make a fake ActivityPub request to your instance and see if you get back HTML or JSON.
Another problem that can happen is that often a response will vary depending on whether the viewer is logged in, or who is logged in. If you can figure out how to configure the CDN to pay attention to cookies or whatever headers are used for Authentication by your platform then you might be able to cache things like /post/*… I couldn’t.
The things I’ve chosen to cache by URI Path above are ones that I know don’t vary by HTTP header or by authentication.
Although we can’t use URI Path a lot of the time, we can cache ActivityPub requests by detecting the Accept: allocation/ld+json header:
https://join.piefed.social/wp-content/uploads/2024/02/caching_activity2-1024x811.pngThis will cache all ActivityPub requests, regardless of URL. People browsing the same URLs as those used by ActivityPub will be unaffected as their requests won’t have the special HTTP header. I used a short TTL to avoid serving stale data when someone quickly edits a post straight after creating it.
There seems to be a deep vein of optimization here which I’ve only just started to dig into. These changes have made a huge difference already and for now my instance is under very little load so I’ll leave it there for now…
Post Mortem on Cloudflare Control Plane and Analytics Outage
This post mortem reads like the timeline of the Chernobyl disaster. It’s incredible how much had to go wrong for this to happen, and yet it happened. A great write-up.
#Cloudflare used to welcome us #Tor users (and not just!) with captchas. Now it’s a spinner; it gives hope initially, but it’s deceitful: it just keeps spinning.
Among the vast parts of the Web stuck behind Cloudflare is w3.org. Thanks for showing the way!
We have two new speakers. One of them will be talking about #Drupal and #CloudFlare and the other oneis the creator of a $NodeJS behavior driven automation testing tool based on #Cucumber and #puppeteer
Got some time off this week, so I’m really hoping to get my #selfhosted#Peertube instance up and running. I just hope that it’ll work behind a #Cloudflare tunnel as long as the videos are hosted on a cloud service. Anyone happen to know if it’ll work?
Huhhuh. Muutama kävijä käynyt tuolla #Mastopoet issa.
Minut yllätti myös top maat!
Nimittäin ensimmäisen sijan on napannut Australia! En olisi uskonut. Seuraavana tulee Yhdysvallat, ja sitten Saksa. Me suomalaiset olemme vasta viidentenä!
So, #GitLab has decided to become completely unusable, by showing this #Cloudflare "prove that you're human" screen and then redirecting back to it in an infinite loop.
It is stunning with how #enshittification does nothing to convince me to change my habits (it's probably due to the pi.hole), and I just decide not to use that site ever again.
Can say that my #Cloudflare#R2 block storage for #Mastodon is massively growing. A year ago it was stable at ~80-89Gb, but lately it's heading to 200Gb+ #Mastoadmin
How do I get my home IP (via Spectrum) off of the #CloudFlare bad list?
The soccer program my oldest is a part of has a website that uses cloudflare and every time I try to use it from home I'm blocked. My cell phone connection is fine (as are any coffee shop wifi connections).
Help?
Edit: for the record, I do have a OpenVPN connection going at times. Would be a pain if that was the culprit.