Xkeeper

It's just C-C, and solely because I noticed that it appears (a) to do its networking from the user's local network instead of a cloud server, and (b) it typically identifies itself as claude-code. It also showed up enough in my logs to be noticed; I don't go proactively searching or testing these things.

Other tools either run off of a central cloud provider, in which case they get the standard anti-AI page, or mask as a "legitimate" user agent, in which case I leave it up to the captcha/challenge.

Tor is one of those things that is nice in theory but, in my experience, tends to consist of about 20% legitimate users, 30% garbage traffic, and (most importantly) 50% specific, persistent, ban-dodging personas non grata.

There are only so many days one wants to wake up and click "delete user" 20 times for the latest batch of slur-filled trash from tor-exit-48012480.r0ck3t.ballz.

Hi, TCRF operator here! (*she)

This story has been escalating for over a year at this point. Originally, identified bots were given a generic "access denied" message. Then a special generic "LLM poison"-type page (some joke misinformation). Once I noticed that Claude-Code bots, specifically, were evading those blocks -- making one request, then changing their user-agent and trying again -- I started adding the persistent ban for bot misbehavior.

That you didn't know any of this until now suggests, I think, that there isn't really much of a problem. After all, this only affects agents reporting as Claude-Code.

The primary goal my side of this has been to interrupt and annoy LLM/AI users, and to that it has been working incredibly well.

My previous blog post, written before this DDoS attack, went into some of the challenges of being an independent website that avoided using third-party services (outside of Linode, our host). Cloudflare was always my "last resort" — I actually signed up for an account there a bit over a year ago, during an earlier attack — and it finally became time to use that last resort.

As for "terminally online", I guess you could say guilty as charged. I've been running communities for over 20 years and TCRF specifically for nearly 17, longer than a lot of our users have been alive. It certainly gets results.

If you mean the block page, yes, that's just the YouTube embed. You'll see the same results on any wiki page that has a YouTube embed for the same reason; it's not tracking or anything I have control over (other than outright not having YouTube embeds). But I think if anyone has concerns over that, they're better addressed at the local-user level by disabling all unauthorized iframes.

Unfortunately true. I wrote about it early last year here: https://blog.xkeeper.net/uncategorized/tcrf-has-been-getting...

The story has not changed much. Every so often I will remove most of the blocks put in place, and within a few hours I'm back to having to block them. Many of the cheaper VPNs are also hosted on AWS / Google Cloud / Azure (or other cloud providers), which are also unilaterally blocked.

I would much prefer we did not have to do this, but it is what it is.

This is fascinating to me, because you just said you can't see it, but also that there are "trackers from multiple big corporations". Can you tell me what those are?

I ask primarily because we explicitly don't use any trackers, to a degree I actually pride myself on running a website that doesn't contact anything else: https://mini.xkeeper.net/private/C58L77azpY.png

The sole exceptions are YouTube embeds, afaik. I even switched out the MediaWiki and CC badges to be local.

From my logging, most people can access it just fine.

As for "what gives", I have no idea. The article itself isn't interesting and doesn't contain much of value; the "game" itself is what is interesting, but that's not what the article is there to cover.

So my guess is it's just only the people who can't see it, because for others there's not really much to discuss. I don't know why this was even posted here, to be honest.