thufie's personal blog - usually about technology

I'm an administrator on the fediverse instance,

In the spirit of cooperating with other administrator teams I am sharing a list of silenced and suspended instances as of January 12, 2019 on Special thanks to for sharing their's as well which was a fantastic reference but we have a few more too.

I'm not going to list the reasons for them each being blocked as for most it should be immediately obvious. However on a few I will clarify. By necessity some explanations will include content which could go under any number of content warnings, so consider yourself warned in advance.

So here we go:

  • – admin posting loli, garbage feed
  • – yeouch
  • – silenced, very spammy, too much activity, hard to judge
  • – lol it is a parody of itself
  • – lol another commercialization attempt
  • – still being held, may be resurrected, keep on list
  • – notorious stalking bots
  • – user instance – advocates “playful” use of f*gg*t

Whether on matrix, the fediverse, or wherever else you know me, you've probably seen me ranting about CloudFlare for one reason or another and advocating for its abandonment by server administrators. CloudFlare has issues on quite a few fronts, which depending on your ideals, may only amount to one or two. This post is an attempt to enumerate all of the different, often unrelated, issues with CloudFlare, in a single place for reference purposes. In fact I plan on keeping this updated as CloudFlare pulls-off crazier and crazier bullshit and continues to become the norm among administrators. Odds are if you are reading this you are somebody I or somebody else referred here, so to expedite your visit here is an outline of the post by headings:

NOTE: Throughout this article Cloudflare is spelled “CloudFlare” for accessibility purposes, I would encourage you to do the same for similar names to help e-readers.

Outline: 1. The immediate problem with CloudFlare, with a fix for lazy admins. 2. The fundamental issue with CloudFlare and similar services. 3. CloudFlare as a threat to federation. 4. CloudFlare's expansion into the decentralized web and beyond.

Other similar/related posts: 1. CloudFlare, We Have A Problem (joepie91) 2. The Trouble with CloudFlare (Tor blog) 3. CloudFlare's Captcha Deanonymizes Tor Users (cryptome) 4. CloudFlare and RIAA Agree on Tailored Site Blocking Process (torrentfreak) 4. Why CloudFlare is Probably a Honeypot ( 5. The Great CloudWall ( 6. iSucker: Big Brother Internet Culture (

The immediate problem with CloudFlare, with a fix for lazy admins.

So here is where I'll cut to the chase for all you CloudFlare sellouts who aren't interested in the future of the internet or the threats that CloudFlare poses to it, but instead worry about “User Experience” and want more people to be able to access your website by offloading the basic work onto somebody else (yeah, I'm mad at you, stop being lazy).

The Problem:

CloudFlare's “protection” has a massive issue which blocks an entire demographic of users from accessing your site because it will consistently have “false-positives” about threats, and this demographic is Tor users (Who uses tor?). Basically, any tor user is systematically blocked from viewing not only your websites behind CloudFlare, but also any resources like media hosted behind CloudFlare. For more details from the tor project about how this makes the average user's experience on the modern internet completely unusable because of admin incompetence (looking at you, admin) you can read more here. Something to note is that CloudFlare has a bunch of highly skilled PR people who train their support employees and marketing department to avoid the word “block” and instead say newspeak like “challenged” or “flagged due to threat score”, which are all the same thing in practice.

The Lazy Workaround:

CloudFlare allows its useds (the administrators being used to dragnet its user's data) to allow for an exception to the prohibitive blocking which harasses tor users. CloudFlare treats Tor exit-relays like a “country” under its UI (Tor (T1)), and to allow them to visit go to the IP Firewall > Access Rules panel and select the Whitelist option for Tor.


Notice how I hosted this media on my site which doesn't have CloudFlare to make it accessible rather than linking to CloudFlare.

And then if that's all you are here for, that's it. I would invite you to read on though.

The fundamental issue with CloudFlare and similar services.

A couple of years ago the web started becoming incredibly bloated with redundant technologies, adverts, trackers, and such which all went beyond displaying the content the user asked for using open, standardized technologies. As a result of this, CDNs (Content Delivery Networks), which had previously been relegated to hosting media content like videos and images which they can cache and serve faster for larger audiences began hosting javascript frameworks and applets embedded in webpages along with various forms of tracking and social media connections. Once this started happening, and web design stopped being about how to make your content compatible with as many browsers as possible using the features from web standards (HTML+CSS), and more about unnecessarily mimicking much of that functionality with javascript frameworks (which take quadruple the time to load and create a bottleneck for the user's browsing experience). It was inevitable that a lazy solution would come presenting itself as the solution to a lazy problem (relevant talk and relevant article). Nowadays CloudFlare is far more, its the ultimate laziness bundle for web administrators who won't properly configure a server to use caching, retain a valid SSL certificate, perform load balancing, and more. Its the reverse proxy for people too lazy to know what that even means plus a bunch of shiny bits on top. It is common to hear CloudFlare being used for the purpose of “DDOS protection”, sure, making all your traffic go through foreign servers does have that as a side effect, but it seems like most hosting services these days offer that regardless, and self-hosters probably only need to setup some basic DDOS mitigation on a private server. But enough of reviewing what CloudFlare already is with my extremely sarcastic tone, what's the problem here with CloudFlare in particular?

Aside from the web becoming a bloated mess and needing all this stuff in the first place, one way or another, CloudFlare represents a model web-service which negates all the privacy and security benefits of independent hosting. User connections to sites configured with CloudFlare are decrypted not at the site itself, but at CloudFlare's servers, allowing them to snoop like teenagers fiddling around with Wireshark in 2004 before HTTPS was being used by most websites. Even worse, traffic passed between two servers each configured to use CloudFlare is owned by CloudFlare at both ends. This comes with extreme privacy and security implications which are at least partially explored here, but have otherwise not received any attention whatsoever. As services like CloudFlare become more and more “Comprehensive”, and more and more security responsibilities are passed off to them by administrators, the purpose for these privacy and security features to begin with is being negated. I'm not the type who is interested in doing a full security analysis, but there is definitely one that deserves to be done concerning services like CloudFlare and I think I have made clear the fundamental issue at the very least. I urge administrators to take back the responsibilities of their jobs and quit handing off their duties to companies like CloudFlare or else we are in for serious trouble in the future.

CloudFlare as a threat to federation.

Whether you are talking about the fediverse (mastodon/pleroma), or any other federated network the motivations behind such projects as of late can be clearly outlined:

  • Decentralization of Power (Not beholden to any single administration and its policies)
  • Privacy (Anti-Mass surveillance)
  • Interoperability (Anyone can run a node following the specification and expect it to work with the rest of the network)

These have been, and remain, the appeals of federated networks for social networking.

However, the increasing and alarming trend of administrators in these federated networks to use CloudFlare threatens all three of these.

Decentralization of Power

CloudFlare threatens decentralization of power by being in a position to deny service to nodes in the federated network by its own policies. Any portion of the network running on CloudFlare is not subject to the policies of a diverse selection of hosting services, but a singular entity's conditions and terms of service which are subject to change at any point in time. Using CloudFlare is re-centralizing power.


I will not get into too many specifics, but above in the “Fundamental issue” section I outlined the general security issue presented by having major nodes on CloudFlare's network. The threat described above applies only to HTTPS and secure web connections, but the degree of this issue can vary from more mild to extremely concerning based on how nodes in a federated network communicate with each other.


One of the benefits of federated networks is that nodes can provide entry points from different networks altogether which once connected allow users who prefer to browse, message, or interact on one service to keep in touch with users anywhere else. In principle, any server which implements of the specifications of a federated network and begins federating with peers on other networks can participate. CloudFlare's policy of blocking Tor connections, and presumably other anonymization overlay networks in the future threatens this key accessibility feature. Nodes running on CloudFlare are cut-off from nodes running via Tor (as hidden services, for example) by default. I would also suspect that CloudFlare may have the potential of limiting interoperability between networks and undercutting this accessibility property in other ways which have yet to be seen.

Any one of these on its own should be enough for a keen observer to have concerns about how CloudFlare usage may effect the future of federated networks, but all three of these have been the case for quite some time now. I think it is time to ring the alarm bells.

CloudFlare's expansion into the decentralized web and beyond.

CloudFlare's business model, surprise surprise, keeps finding new ways to coincidentally end up as an intermediary for internet traffic. Here I will outline the new and innovative ways in which CloudFlare is commercializing alternative and traditional networks while simultaneously deononymizing users and recentering trust towards their proprietary infrastructure:

There are many admins out there with no regard for the future of the internet as it becomes hypercentralized, and as few megacorporations accumulate absolute power. An example would be /r/selfhosted and all the people behind sites which rely on ad-revenue.

And so what if you don't too?

Fuck you and Fuck CloudFlare.

The writefreely software depends on a javascript plugin called highlight.js to support syntax-highlighting for code-blocks in your blog posts. This guide will outline how to effectively integrate this feature into your blog and customize it to best suit your blog's style. Syntax highlighting isn't possible for inline code, but you can still make it look fairly nice as well if you reference my custom CSS. Preemptive disclaimer: I'm not a web-dev so I don't actually know the proper terminology for some javascript and CSS stuff so let me know on the fediverse if I made any mistakes in that regard.

Here's the general outline: 1. Use the correct markdown spec to specify your coding language 2. Avoid using hashtags in the code block (octothorpes if you are a nerd) since they break with the code block plugin 3. Add a fix to your blog's custom CSS to disable line-wrapping and add a horizontal scrollbar to the code block 4. (Optional) Setup a custom code block color theme to match your blog

Making a code block which specifies the coding language

To specify the coding language in your code-block so the plugin can do fancy syntax-highlighting you need to specify the name of the coding language right after you begin the code block like in this picture: css_codeblock

This code block is specifying that the code inside of it is CSS so the plugin can correctly highlight it. If you do not know what the name for a language might be you can browse the languages supported by the highlight.js plugin here.

By default the plugin on write-freely instances only actually has support for a small subset of these languages downloaded. You can tell which languages are supported by your instance by viewing the source of your blog page when it has a code block on it and searching for “var langs” which has a list of all the languages your particular instance supports next to it. If your language is not in this list, but it is in the list above, consider contacting your admin and asking them to download a version of highlight.js with your language supported.

Avoid using hashtags in the code block

“How can we move forward here? This is probably less trivial than it looks.” – mrvdb on github

Unfortunately writefreely has a known bug that causes hashtags inside of codeblocks to be parsed incorrectly. Until this is fixed, any code blocks containing one will be horribly mangled by an ugly html tag that appears in place of the hashtag. If you are using a language which has syntactically meaningful hashtags (not just for comments, which can be done with the blog post itself), it may be worth substituting hashtags with this character “⋕” and just letting your reader know since if they copy-paste it and get syntax errors they will be very confused.

Fixing your custom-CSS with a scrollbar

By default, writefreely's highlight.js theme has line-breaks enabled which can lead to ugly messes like this: linewrapped_code To avoid this, you can add this CSS to your blog's custom CSS:

/* custom line-wrapping fix for highlight.js */
.hljs {
    white-space: pre !important;
    overflow-x: auto !important;

Once this has been added, line-wrapping will no longer occur, and a scrollbar will be added to the bottom of the codeblock view which allows readers to scroll horizontally and reach any code which was previously out of sight.

Setup a custom code block color scheme

The highlight.js project has a large variety of CSS themes to choose from here and installing one of them is almost as simple as copying and pasting. I say almost as simple, because you will have to do a bit of slightly-tedious correction work that anyone should be able to figure out even if you don't know CSS syntax.

Since your writefreely instance has a preset syntax-highlighting color scheme set for highlight.js for default, that means that your custom theme CSS has to override the defaults, which in practice just means adding !important after every single property. The code block with the fix for line-wrapping does this above, but for reference here is my blog's custom CSS with the a11y-dark theme at the bottom of the file using !important on every CSS property. I recommend editing a custom CSS file in your own editor rather than just pasting it straight into the custom-css box on your blog's settings page since the box on your settings page does not let you copy text out of it with your clipboard (at least in my experience).

With all that done, you should have fairly-functional and aesthetically appealing code-blocks for all of your blog posts.

Federation testing! Mastodon