Cloudflare’s policy gap lets gore sites stay up

I break down how Cloudflare keeps a gore forum online and what teams can copy from the ADL’s critique.

I’ve been watching infrastructure companies talk about “neutrality” for years, and honestly, it still bugs me when the argument gets used like a shield. If you only look at the logo on the homepage, Cloudflare looks like plumbing: DNS, CDN, DDoS protection, security, the boring stuff that keeps sites alive. But boring infrastructure turns into a moral decision fast when the customer is a gore forum tied to real-world violence. That’s the part that never sits right with me. Not because moderation is easy. It isn’t. I’ve built systems where one bad blocklist rule can take down half a product. But this is not a typo in a filter. This is a company deciding whether to keep providing core services to a site that researchers say helped radicalize a school shooter. That’s a very different conversation.

The Denver Post story by Shelly Bradbury on May 21, 2026 is the trigger here, and it points back to an Anti-Defamation League report that argues Cloudflare could cut off services and materially disrupt the site. The report doesn’t claim this is a simple content-moderation problem. It’s about infrastructure providers deciding how much abuse they’ll tolerate before they stop being “neutral” and start being complicit. That’s the part I wanted to unpack for developers, because this is the kind of policy argument that eventually becomes product architecture.

Cloudflare’s real product is permission, not just protection

“Internet infrastructure company Cloudflare provides a suite of services to the online gore forum that allows the website to keep operating for its 5 million users.”

What this actually means is Cloudflare isn’t just caching images or speeding up traffic. It’s helping the site stay reachable, stable, and harder to knock offline. That matters because infrastructure is not a neutral layer in practice. If you remove enough of it, the site becomes expensive and fragile to run. If you keep it in place, you’re making a business choice that has downstream social effects.

I’ve seen teams wave this away with the classic “we don’t own the content” line. Sure. But when your service is the thing keeping the lights on, pretending you’re only a passive pipe is a little too convenient. The ADL report, as summarized in the Denver Post piece, says Cloudflare could withdraw services and cripple the forum. That’s the key technical claim. Not that Cloudflare wrote the content. Not that it hosts the database. Just that it gives the site enough infrastructure to survive.

How to apply it: if you build infrastructure, stop describing your service only in terms of protocol nouns. Write down the actual dependency you create. Are you only accelerating traffic? Are you absorbing attacks? Are you making takedown harder? Those are different responsibilities, and your policy should name them separately.

The “neutral pass-through” argument is doing a lot of work

Cloudflare has said it is a neutral “pass-through” service, rather than a website host or owner.

That line sounds clean until you try to use it in a real incident review. Then it gets messy fast. “Pass-through” is a nice phrase, but it hides the fact that infrastructure providers choose who gets resilience and who doesn’t. That choice is the whole story.

The Denver Post article says Cloudflare has used a phone-utility analogy before, arguing it shouldn’t disconnect someone just because they say awful things. I get why that analogy is tempting. It gives executives a simple moral frame. But I think it breaks down because internet infrastructure isn’t just a telephone line. The service can be used to amplify, harden, and obscure harmful operations in ways a phone network doesn’t. The analogy is comforting, not accurate.

I ran into this exact failure mode when reviewing abuse policies for a platform product. The policy said “we don’t moderate content.” Fine. But the product still had ranking, distribution, trust scoring, and abuse controls. In practice, it absolutely moderated behavior. It just did so indirectly and inconsistently. Infrastructure companies do the same thing when they pretend they’re not making editorial choices. They are. They just prefer the choices to stay invisible.

• “Neutral” is often shorthand for “we haven’t agreed on a line yet.”
• If you can terminate service, you already have a moderation policy, even if it’s undocumented.

How to apply it: audit your own policy language. If your docs say you’re neutral, ask what happens when a customer is tied to violence, harassment, or exploitation. If the answer is “we’ll decide later,” then you don’t have a policy. You have a delay tactic.

Why the 8chan and Kiwi Farms precedents matter

Cloudflare cut off its services to 8chan in 2019 after three mass shooters posted there, and in 2022 it ended services for Kiwi Farms after public pressure.

What this actually means is Cloudflare already knows how to pull the plug when the pressure is high enough. That’s important because it kills the “we can’t possibly do this” excuse. The company has done it before. It just seems to treat each case as exceptional, which is convenient if you want discretion and bad if you want a stable rule.

The Denver Post piece notes that Cloudflare said Kiwi Farms posed an “immediate threat to human life.” That’s the kind of threshold that sounds obvious only after the fact. Before that, companies usually hide behind process, legal review, and a lot of hand-waving. I’ve been in enough incident rooms to know how that goes. Everyone agrees something is bad. Nobody wants to be the person who sets the precedent. So the bad thing stays up until the public pressure gets loud enough to make inaction look worse than action.

That’s not governance. That’s reactive risk management.

How to apply it: if you run a platform or infrastructure service, define a repeatable escalation path before the headline hits. Name the triggers. Name who can approve suspension. Name how fast the decision happens. If you only have a “special cases” folder, you’re going to make the same messy decision over and over.

The ADL is arguing for a higher bar, not a lower one

Daniel Kelley said, “There should be a high bar for cutting off access, but sites like WatchPeopleDie meet that mark.”

This is the part I think gets flattened in a lot of debate. The ADL is not saying every ugly site should be unplugged. It’s saying sites dedicated to gore, violent extremism, and the celebration of violence are not gray-area cases. That distinction matters. If every moderation debate turns into “free speech versus censorship,” you end up with no usable policy at all.

The article also says the ADL found Cloudflare’s approach is more lax than Amazon Web Services, which has explicit prohibitions and termination mechanisms for content that incites violence or terrorism. That’s not a small detail. It means policy can be written in a way that is both enforceable and narrower than people assume. You do not need to boil the ocean. You need to say what kind of abuse crosses the line and what happens next.

I like that framing because it’s practical. It doesn’t ask every company to become a moral tribunal. It asks them to stop pretending they have no standards while still benefiting from the appearance of restraint.

• High bar does not mean no bar.
• Specific policy beats vague “trust and safety” language every time.
• Comparing yourself to a phone company is not a substitute for a threat model.

How to apply it: write a narrow policy for infrastructure abuse. Focus on categories like direct incitement, operational support for extremist violence, and repeated hosting of content that clearly celebrates or facilitates harm. Then make the enforcement path boring and documented. Boring is good here.

All-or-nothing infrastructure changes the math

“With internet infrastructure, it is a giant on/off switch. You are either providing services or you are not.”

That quote from Kelley is the cleanest technical explanation in the whole story. Social platforms can remove posts, accounts, or groups. Infrastructure providers usually can’t surgically remove one bad post. They either keep serving the customer or they don’t. That makes the decision heavier, but it also makes the policy easier to reason about once you stop pretending it’s the same as content moderation.

I’ve worked around enough infra to know why this feels uncomfortable. Turning off service can hit innocent users, mirror sites, or unrelated parts of a customer’s stack. It can also create a whack-a-mole problem where the site just moves elsewhere. The Denver Post article even notes that websites can return with new providers. So yes, deplatforming is blunt. But blunt doesn’t mean useless. Sometimes blunt is the only tool that actually changes operating cost.

The trick is to stop thinking in absolutes. You don’t need a perfect permanent fix. You need enough friction that abuse stops being trivial. If a site dedicated to gore can keep running with a mainstream provider’s help, then the provider is part of the abuse surface whether it likes that label or not.

How to apply it: model your service as a dependency chain. Ask what happens if you remove DNS, CDN, TLS termination, WAF, or DDoS protection. Then decide which layers you are willing to provide to customers who cross your abuse threshold. That gives you a real policy instead of a slogan.

What developers should copy from this mess

Cloudflare says it is not responsible for vetting customers because it is a neutral service.

Here’s my blunt take: the problem is not that Cloudflare lacks intelligence. The problem is that its policy appears to be built to preserve discretion, not clarity. That’s a classic enterprise failure mode. The company wants room to act when the public pressure gets unbearable, but not so much policy that it has to explain why one abusive customer gets cut off and another doesn’t.

If you’re building products, especially platforms or infrastructure, this story is a reminder to write rules you can actually defend before the crisis. I’m not talking about a 40-page legal memo. I’m talking about a decision tree your team can use without inventing the policy on the fly.

Here’s the version I’d want in an internal handbook:

• Define the abuse categories that trigger review.
• Define the services that can be suspended.
• Define who decides and how fast.
• Define whether the customer gets warning, appeal, or immediate suspension.
• Define what evidence you need before action.

That sounds dry, but dry is what keeps you from improvising under pressure. And when the case involves a site tied to violence, improvisation is a luxury nobody should want.

The template you can copy

# Infrastructure abuse policy template

## Purpose
We provide infrastructure services, not editorial approval. But if a customer uses our services to materially support violence, extremism, or organized abuse, we will review and may suspend service.

## Review triggers
We open a review when credible evidence shows a customer is:
- Dedicated to celebrating, facilitating, or coordinating violent harm
- Hosting or distributing content that directly incites violence or terrorism
- Using our services to materially support harassment, stalking, exploitation, or extremist recruitment
- Repeatedly evading prior enforcement through new domains or accounts

## Services in scope
This policy applies to:
- DNS
- CDN
- TLS termination
- WAF / bot protection
- DDoS mitigation
- Security and performance services

## Decision standard
We do not require perfect certainty. We require credible evidence, documented review, and a decision proportional to the risk of harm.

## Escalation path
1. Abuse report or internal detection
2. Security / trust review
3. Legal review if needed
4. Executive approval for suspension
5. Enforcement and documentation

## Enforcement options
- Warning
- Partial service restriction
- Full suspension
- Permanent termination for repeated or severe abuse

## Timing
If the risk indicates imminent danger to human life, we may act immediately and review after suspension.

## Appeals
Customers may appeal once. Appeals must include specific evidence, not general disagreement.

## Transparency
We log every enforcement action, the services affected, the evidence reviewed, and the final decision.

## Public guidance
We publish a plain-language version of this policy so customers know where the line is before they cross it.

## Internal checklist
- Is the customer dedicated to violent or extremist content?
- Are our services materially helping them stay online?
- Would suspension reduce harm or just create theater?
- Can we explain this decision consistently to another customer in the same situation?
- Have we documented the rationale and the evidence?

## Copy-ready enforcement note
Customer services suspended due to credible evidence that our infrastructure is materially supporting violent/extremist content. Decision made after documented review under the abuse policy, with services limited to reduce harm and prevent continued misuse.

If I were adapting this for a real team, I’d keep the language plain and the categories narrow. No grand theory. No “we value safety” fluff. Just the actual decision points you need when a customer crosses the line.

And yes, I’d make legal and security sign off on it together. If those teams only meet after something goes viral, you’re already behind.

Source attribution: this breakdown is based on Shelly Bradbury’s Denver Post article at https://www.denverpost.com/2026/05/21/cloudflare-evergreen-school-shooting-gore-internet/ and the ADL report linked above. My template is original, but the policy problem and factual reporting come from those sources.