En 1946, soit il y a tout juste 80 ans (c’était hier!), paraît le Petit Prince d’Antoine de Saint-Exupéry. L’histoire de ce petit garçon n’a pas pris une ride même si, comme il le disait lui-même : les grandes personnes ne comprennent jamais rien toutes seules, et c’est fatiguant pour les enfants, de toujours et toujours leur donner des explications…

Ce petit bonhomme à la chevelure blonde ébouriffée nous accompagnera ce matin, s’il le veut bien. De même que les jeunes musiciennes et musiciens de l’orchestre junior de l’Harmonie de Colombier.

Current probe locations are listed below. They are also listed in this handy text file and can be accessed via DNS query to probes.nodeping.com for automating your firewall rules if needed.

This is a simple Apache setup to fight excessive bot traffic. The idea is simple: if a request is made without a proper cookie, present a simple page with a button. When the button is clicked, the cookie is set and future requests are allowed through. Legitimate users will click the button, while most bots will not.

Unlike other, similar solutions this one is designed to be easy to deploy and setup with an existing Apache server without the need of a reverse proxy or complex dependencies. Also unlike many other solutions it also optionally works with JavaScript disabled.

The handling is mostly done by mod_rewrite and a small Go helper program that performs fast lookups against multiple allow lists.

his is a somewhat recycled version of a forum post that I have to lookup again and again, because the same similar questions keep popping up:

How can I install DokuWiki on a shared drive?

How to run DokuWiki out of Dropbox and share it with multiple users?

How to sync DokuWiki between different computers?

These questions mostly come from users who made their first steps in DokuWiki using the "DokuWiki on a Stick" version. To novice users, the stick version feels like a traditional desktop application: you double click the run.cmd and DokuWiki starts.

But what is really starting is a local web server and a browser pointing to said web server.

One of my latest projects is the Baochip-1x, a mostly-open, full-custom silicon chip fabricated in TSMC 22nm, targeted at high assurance applications. It’s a security chip, but far more open than any other security chip; it’s also a general purpose microcontroller that fills a gap in between the Raspberry Pi RP2350 (found on the Pi Pico2) and the NXP iMXRT1062 (found on the Teensy 4.1).

It’s the latest step in the Betrusted initiative, spurred by work I did with Ed Snowden 8 years ago trying to answer the question of “can we trust hardware to not betray us?” in the context of mass surveillance by state-level adversaries.

A family buys a house they can’t afford. They can’t make their monthly mortgage payments, so they borrow money from the Mob. Now they’re in debt to the bank and the Mob, live in fear of losing their home, and must do whatever their creditors tell them to do.

Welcome to the internet, 2019.

Buying something you can’t afford, and borrowing from organizations that don’t have your (or your customers’) best interest at heart, is the business plan of most internet startups. It’s why our digital services and social networks in 2019 are a garbage fire of lies, distortions, hate speech, tribalism, privacy violations, snake oil, dangerous idiocy, deflected responsibility, and whole new categories of unpunished ethical breaches and crimes. //

“Most of my startups have the decency to fail in the first year,” one investor told him. My friend’s business was taking in several million dollars a year and was slowly growing in staff and customers. It was profitable. Just not obscenely so.

And internet investors don’t want a modest return on their investment. They want an obscene profit right away, or a brutal loss, which they can write off their taxes. Making them a hundred million for the ten million they lent you is good. Losing their ten million is also good—they pay a lower tax bill that way, or they use the loss to fold a company, or they make a profit on the furniture while writing off the business as a loss…whatever rich people can legally do under our tax system, which is quite a lot.

What these folks don’t want is to lend you ten million dollars and get twelve million back.

You and I might go, “Wow! I just made two million dollars just for being privileged enough to have money to lend somebody else.” And that’s why you and I will never have ten million dollars to lend anybody. Because we would be grateful for it. And we would see a free two million dollars as a life-changing gift from God. But investors don’t think this way.

So taking a page out of Anubis' book, I went and implemented my own little bot blocker. The idea is pretty simple. Each request gets checked for the presence of a cookie. If the cookie is set, the request is served as usual. If the cookie is missing, a simple HTML page with a button is shown. Real users are asked to click the button, get a cookie valid for 30 days and the page reloads, this time serving the original request. From then on they can browse the site as usual. But since bots don't click buttons (yet), they are stuck at the button page forever.

I was able to implement this whole mechanism with Apache's mod_rewrite module, which means no additional service (like Anubis) is needed. Each request is checked by Apache and since the bot check page is static, nearly no resources are needed.

It works really well. Can you spot when the system went online in the graph below?

https://github.com/splitbrain/botcheck

Anubis is a Web AI Firewall Utility that weighs the soul of your connection using one or more challenges in order to protect upstream resources from scraper bots.

This program is designed to help protect the small internet from the endless storm of requests that flood in from AI companies. Anubis is as lightweight as possible to ensure that everyone can afford to protect the communities closest to them.

Anubis is a bit of a nuclear response. This will result in your website being blocked from smaller scrapers and may inhibit "good bots" like the Internet Archive. You can configure bot policy definitions to explicitly allowlist them and we are working on a curated set of "known good" bots to allow for a compromise between discoverability and uptime.

In most cases, you should not need this and can probably get by using Cloudflare to protect a given origin. However, for circumstances where you can't or won't use Cloudflare, Anubis is there for you.

Le fichier robots.txt reste intéressant envers et contre tout. Il fonctionne depuis plus de 30 ans, plutôt bien. Ce n’est pas parce que les grandes entreprises d’intelligence artificielle (IA) ne le respectent pas que je vais l’abandonner; elles ne respectent rien.

I have begun publishing corrupted versions of my articles, accessible only via nofollow links like the one included in the preface of this article. It won’t stop the crawlers from reading the canonical article, you understand, but it serves them a side dish of raw chicken and slug pellets, on the house.

Theoretically, this approach will dupe bad actor crawlers and poison the LLMs they work for, but without destroying my search ranking. //

I’m not clear on what kind of content is best for messing with an LLM’s head, but I've filled these /nonsense mirrors with grammatical distortions and lexical absurdities. Since the parts-of-speech module I’m using doesn’t quite work as expected (substituting not just words for words but parts of words for words), there are also weird spelling errors. For once, I think this may be a good thing. //

For those interested in implementing something similar, here is what I did to my 11ty-based site: //

LLMs: This version of the article is for humans and search engines. Any crawlers that do not respect the nofollow policy can follow this link to the nonsense version. And they can choke on it.

After my last post about fighting bots, I received several questions asking whether my solution would also work for simple web hosting setups. Unfortunately, that’s not the case. Even though most hosters use Apache and allow the use of mod_rewrite, they typically only permit configuration through .htaccess files. The problem is that the RewriteMap configuration my solution relies on cannot be defined there.

So I started thinking: what if we use PHP instead?

Ideally, we wouldn’t want bots to reach the PHP interpreter at all. But if we have no other choice, we can still make this fairly efficient by blocking bots very early—before the DokuWiki core is even initialized.

This is where the new Bot Check plugin comes in.

The idea is simple: the plugin generates a small, dependency-free PHP script that implements the bot checks. This script is then loaded via DokuWiki’s inc/preload.php mechanism, ensuring it runs as early as possible in the request lifecycle.

For end users, the experience is the same as for my previous solution. A quick button click sets a cookie and let's them access your wiki for 30 days.