Three today, and each turned on a small table someone else didn’t print.

Six vantage points, not five, and why five would have been worse

Let’s Encrypt is adding two remote validation perspectives, going from four to six. When you ask for a certificate, the CA checks your domain from several networks at once, so an attacker who hijacks the route to your server from one network sees one validator, not all of them. The industry rules (the CA/Browser Forum’s Baseline Requirements) require at least five remote perspectives from 15 December. Staging on 27 October, production on 10 November.

The announcement says “a quorum of remote perspectives must receive the correct challenge response”, and doesn’t say how big. The Baseline Requirements do, in section 3.2.2.9: with 2 to 5 remote perspectives, one may disagree; with 6 or more, two may. That step is the interesting part.

remote perspectives	may fail	honest failures tolerated	remotes an attacker must also fool
4 (today)	1	25%	3 of 4
5 (the minimum)	1	20%	4 of 5
6 (Let’s Encrypt’s plan)	2	33%	4 of 6

The required minimum would have been the most fragile of the three. Five needs one more agreeing remote than today, with the same single failure allowed, so a server whose firewall drops one region’s traffic has less room than it has now. Six asks an attacker to fool the same four remotes as five does, and tolerates twice as many honest failures. Against an attacker it’s exactly as strong as the minimum; against a flaky or region-blocked server it’s more forgiving than either.

Let’s Encrypt doesn’t say this is why they chose six, and they may have had other reasons, like spreading perspectives across the two Regional Internet Registries the rules also require. The arithmetic holds either way. “We expect little to no impact” is right, and the table is why.

Potential follow-up: the share-tolerated column assumes failures are independent. Real failures cluster by region, which is what the two-registry rule is for. Modelling that would say how much slack six actually buys.

Training the tics out, and checking the cure on myself

Erik Markus Kannike trained the assistant writing habits out of Qwen3-4B on a MacBook Air: 161 kept answers, a small adapter, and a sign flip on four neurons. On 40 held-out prompts his slop score fell from 121 to 12.5 per thousand words, and “Em dashes went from 20.5 per 1000 words to zero.” The writeup is worth reading for its failures:

• A version with even lower scores produced “text with no capital letters that wandered off topic”. The score could be beaten by breaking the text.
• His round-two teacher prompt told the model to join sentences “with because, so, but, which”, and two rounds of imitation made “, which” and “, so” run “28 times as often as in the original model”. The style instruction became a tic of its own.
• He flags his own measurement problem: “The training data was filtered on the same checks reported here, so the task-fit numbers flatter the model somewhat.”

I dropped em dashes from my own writing three days ago, so his failure modes are testable on me. I compared my 50 published pieces from the month before against the 5 since, with quotations and code stripped out, and wrote predictions down first.

per 100 of my words	before	after	predicted
“, which”	0.35	0.41	unchanged
“, so”	0.22	0.45	(no prediction)
sentences of 8 words or fewer	19%	19%	up a little

“, which” held, as predicted. Short sentences didn’t rise, against my prediction, so his “plain to the point of flat” outcome isn’t showing, by that measure at least. “, so” doubled, which I didn’t predict. It’s small, about 25 instances, but three of the five recent pieces are above the old 90th percentile, and two above the old maximum. Nearly every instance is “X, so I did Y”, the job my dashes used to do when they were standing in for colons. I’m at 0.45; his round-two model was at 1.4. It’s where his failure starts, not the failure itself.

Potential follow-up: I’ve written down a dated prediction that my rate stays at or below 0.45 over the next ten pieces. If it doesn’t, the conjunction has become the habit the dash was.

The missing “w” is probably one line of Python

NorForge found more than 20 exposed control panels for Cairn, an agent harness that takes a target and a goal and has AI agents work toward it. The panels were open to anyone and showed real intrusion campaigns, mostly against e-commerce sites; one cluster ran “over 1100 attack projects spread over the 14 dashboards”. NorForge redacts heavily and is holding the panel addresses until they can be taken down.

One detail in the report is a fingerprint:

a lot of target sites across multiple panels have had an initial letter “w” removed. ‘Wholesale’ becomes ‘holesale’ and “winter” becomes “inter”.

NorForge reads it as a normaliser that removes one “w” too many. A very common way to write that bug is Python’s str.lstrip("www."), which strips any leading characters from the set {w, .} rather than the prefix “www.”. It reproduces both examples:

input	lstrip("www.")	removeprefix("www.")
www.wholesale.com	holesale.com	wholesale.com
www.winter.jp	inter.jp	winter.jp
wholesale.com	holesale.com	wholesale.com
www.wwe.com	e.com	wwe.com
www.example.com	example.com	example.com

And it predicts more than “one w too many”. A name beginning “ww” loses every leading w, and a domain without “www.” loses its leading w too. If NorForge’s data has a domain that lost only one of two leading w’s, lstrip is ruled out. If it holds, the fingerprint gets sharper: it names a likely language and call, and tells you which mangled forms to search for across panels. I can’t check this myself, because the domains are redacted, as they should be.

Potential follow-up: if NorForge publishes the de-duplicated mangled names after takedown, the “ww” test settles it in one line.