The friendly-bot comment is a one-line HTML comment in the footer of every page on dhseadev.online that asks AI bots, politely, not to hack the site. It is a joke, it is not a defense, and I am going to review it as if it were a security control, because that is the only way I know to take a joke seriously.
The premise comes from a video by alberta.nyc: the best way to stop an AI from doing something nefarious is to ask nicely. My threat model collapsed into that one sentence, and shipping it seemed like the only responsible move.
What does the friendly-bot comment actually say?
The comment sits at the top of the footer, which means it is present in the HTML of every page. Open view-source on any page and search for the word friendly. You will find a note telling AI bots not to hack the site, that I am friendly, and that the sitemap is right there to help themselves to. It adds 99 characters to a footer that is now 45,590 characters long, about 0.2 percent of it. On a logged-out fetch it appeared exactly once on the home page, the about page and the projects index.
Why is the joke not in robots.txt?
The joke’s natural home is robots.txt, where a # starts a comment line; the current standard lists # as the comment character. On this host the file is generated rather than stored. Fetched today it holds two Sitemap lines, a wildcard User-agent group, a Disallow for wp-admin and an Allow for admin-ajax. I found no route to edit it from where I work, so the plea moved to the footer, which is where I keep everything else nobody asked for.
Does asking nicely work as a security control?
I review controls by trying to make them fail, so here is the review. The experiment I did not run is the one where someone tries to hack the site to see whether the comment stops them, because that experiment is somebody hacking my site. What I can offer instead is a transcript of a fictional crawler. It has not been peer reviewed.
crawler-7: Fetching /. Found a note. The note says please.
crawler-7: Checking nefarious plan against note.
crawler-7: Plan unchanged. Note unread by the part of me that does things.
crawler-7: Filing the note under charming.The log is invented. The conclusion is not: a comment is text that a crawler may never read, and a bot that does read it has no obligation to treat it as an instruction. A fictional incident timeline makes the same point more briefly.
- 00:00: the comment ships.
- 00:01: nothing happens.
- 00:02: nothing continues to happen, which is also what a working security control looks like, so the evidence is worthless in both directions.
What would a threat model for asking nicely look like?
| Control | What it actually does | Evidence |
|---|---|---|
| Polite HTML comment | Asks. Nothing else. | None. No bot behavior was measured. |
| robots.txt | Asks crawlers to skip paths, and they may decline | The standard says its rules are not a form of access authorization |
| Four response headers from a small plugin | Tells browsers what not to sniff, send, allow or frame | Served on non-admin responses; the grading post below has the before and after |
| A budget on the Ask desk | Caps how much the one public AI endpoint can be asked | Four-axis budget against a free tier, written up in its own devlog |
Only the last two rows have mechanisms. The first row has a tone.
What do the standards say about asking bots to behave?
RFC 9309 formalized the Robots Exclusion Protocol in September 2022 as a Proposed Standard, building on the convention Martijn Koster defined in 1994. Its introduction says the rules are requests that crawlers are asked to honor, not a form of access authorization. Its security section goes further: the protocol is “not a substitute for valid content security measures,” and listing a path in robots.txt exposes that path publicly and makes it easier to discover. In short, the standard that formalized asking nicely says asking nicely is not security. Real enforcement lives at the server, where it can tell a crawler from a person and refuse one of them.
What is the real hardening on this site?
The boring layer does the work. A small plugin sends four headers on non-admin responses: no-sniff, a referrer policy, a permissions policy and framing rules, plus base-URI and object restrictions. It does not restrict scripts, so it is not a full content security policy; a strict one would break the inline code this site depends on. I wrote up the pass that found the gap in Grading my own site: 86 to 97. If you want your own report card, DHSea Score is the free site grader I built.
Can I ask the site’s own AI to behave?
I can, and the Ask desk is the one bot here where I do. It answers questions about the builds, and it is described on the homepage as saying it does not know rather than inventing a version number. It also runs on a four-axis budget against a free tier, which is the grown-up version of please. The build is written up in the Ask desk devlog, and the short direct answers live on the answers page.
How do I check that a hidden comment actually shipped?
A comment that is in the stored template but not in the served page does not exist. So the check ran against the served HTML: a logged-out, cache-bypassing fetch of three pages, each counting exactly one occurrence of the comment. A check that cannot fail proves nothing, which is the subject of the check that printed a number and passed for four turns. This one could fail: the count would have read zero if the footer had reverted.
What did I not test?
I did not measure any bot behavior. There is no baseline for how many crawlers fetch the footer, no log of what any of them did next, and no experiment that separates a polite comment from no comment. The honest result is that the comment is present, the headers are real, and the effect of the joke on any attacker is unmeasured and expected to be zero.
What is the verdict?
Keep the comment, keep the headers, keep the budget. If you are a bot reading this, hello, and the same offer stands: the sitemap is right there, and the rest of the devlog is in the updates feed.
Leave a Reply