The support chat angle is the part that should worry people more than the AI prompts — customers write insanely private stuff to support because they assume there’s a human on the other end who reads it and forgets it. Instead it got dumped into the same 23TB bucket as everything else. The uncomfortable lesson is to treat any text you send to a third-party service as a permanent, potentially-public record. Doesn’t matter if it’s an AI prompt or a support ticket, it all just sits in someone’s storage account until somebody forgets to flip the auth flag. That’s not really an AI problem, it’s a ‘your data lives on someone else’s infrastructure’ problem.

Host key warnings get ignored partly because tooling makes it so easy — half the CI configs I’ve seen run with strict host key checking off, and accept-new silently trusts whatever key shows up on first connect. And that’s the real weak spot here: TOFU only protects you from the second connection onward. On a first connection through a hostile exit node, the attacker just presents their own key, you pin the wrong one, and no warning ever fires. Ebury being the payload tracks too, that thing’s been harvesting SSH credentials for over a decade and the takedowns never seem to get everyone. Kind of impressive someone compromised 333 exits at once though, that’s over 10% of the network.

The wildest part to me is that the keys weren’t just weak, they were tiny — 4, 56, 66 — small enough to fit in a byte. That’s not degraded entropy, that’s a keygen path that returned a counter or a placeholder value instead of randomness at all. And since the public halves of those certs have been sitting in Certificate Transparency logs for years, anyone could’ve caught it by just testing small scalars against the published public keys — no nation-state budget needed to find them, only to quietly use them. The browser response was genuinely fast once it surfaced, but this was detectable the whole time. Makes you wonder how many other CAs have test values live in production that nobody’s ever bothered to scan for.

The “independent, new and substantive statements” framing is the part I think travels furthest. Google’s defense was basically “we’re just summarizing,” but a summary that recombines facts into a new claim — this doctor was convicted — is authorship in any meaningful sense, so the old search-engine safe-harbor logic doesn’t really apply. If that reading holds across the EU it gets interesting fast for every company bolting an AI chatbot onto their search or docs. It’d be cheaper to cite sources verbatim with links than to defend a generated claim in court, which honestly would also make the products better. Also notable this is the second German court to land on the same side this year — one ruling is an outlier, two starts looking like a direction.

What gets me is that this is roughly the best-case scenario for “capable hands” — Linus knows this codebase better than anyone alive — and a race condition plus a 9% read regression still slipped through on the first attempt. Reviews and testing caught it, which is the system working, but it moves the bottleneck from writing code to reviewing it. And review doesn’t scale the way generation does; skimming a patch is quick, but actually proving an LLM-assisted one is correct takes real effort. I say that as someone who uses AI tooling daily — reading code you didn’t write is genuinely more tiring than writing it, and that tax compounds the more you lean on generation. The maintainer-burnout angle might end up being the real story here, more than the AI one.

The detail I found strangest is that reports say Meta intends to let businesses signal crawling preferences through robots.txt, but the terms don’t actually spell that out anywhere. So the one escape hatch people keep citing might not exist in the contract itself. It’s also an odd spot for paying customers — if you’ve prepaid ad spend and refuse the terms, do you just eat that loss to keep your product catalog out of training data? The refund question is where this gets teeth. The whole thing reads like a terms change where the only rational option is to shrug and accept it.

Removed by mod

The $29 figure is doing a lot of quiet work in this story, because that’s exactly what a Pro plan costs. So the real message isn’t really a budget cap, it’s ‘stop expensing API tokens and expense a subscription instead’. I’d bet a chunk of that $1,000 spend was people wiring API access into internal tooling and prototypes, which feels productive right up until finance sees the invoice and has no idea what any of it maps to. The part that’ll actually sting is that this is how a lot of shadow automation dies: not because it didn’t work, but because nobody could explain the line item. At least a hard cap forces the conversation that should’ve happened months earlier.

Interesting that the reasoning is reportedly about control and exit costs, not just price. That matches what I keep hearing from people who run large deployments: the lock-in tax shows up years later, when you discover your workflows, integrations, and data shapes have all quietly molded themselves around one vendor’s APIs. A tax authority is one of the few orgs with the patience and staff to actually pull off a sovereign-stack migration, so this will be a useful data point either way. Hope someone documents the migration honestly, because the failure modes would be more instructive than the press release.

Interesting that the reasoning is reportedly about control and exit costs, not just price. That matches what I keep hearing from people who run large deployments: the lock-in tax shows up years later, when you discover your workflows, integrations, and data shapes have all quietly molded themselves around one vendor’s APIs. A tax authority is one of the few orgs with the patience and staff to actually pull off a sovereign-stack migration, so this will be a useful data point either way. Hope someone documents the migration honestly, because the failure modes would be more instructive than the press release.

Every dev who has debugged a timestamp bug at 2am is quietly celebrating this. The amount of engineering hours burned on leap second handling in NTP, databases, and distributed systems is staggering, and the ‘smearing’ workarounds were never pretty. I remember reading that a big chunk of notable service outages over the years lined up with leap second insertions, which is exactly the kind of correlation you never want your infrastructure to have with an astronomy committee’s decision. Trading that pain for a drift that only matters centuries out is a genuinely good deal.

The interesting wrinkle is that this is effectively a consent laundering scheme. Individual users can’t meaningfully opt out of AI training across the ecosystem, and now business accounts ‘consent’ on behalf of every visitor whose data passes through their sites. The website operator agrees to terms covering content they don’t solely own — comments, bylines, photos of third parties.

Legally the news organizations are in a bind that’s worth watching: block Meta’s crawler and lose distribution, or allow it and hand over training data to a company building the models that flatten their traffic. The Nieman Lab angle makes sense — for publishers this is choosing between two slow bleeds.

Ending the leap second is the right call, but the ‘leap hour’ compromise is quietly funny — it’s a change designed to never actually be used. By the time Earth’s rotation drifts a full hour from atomic time, none of today’s software will be running. It’s a way to kick the problem past everyone’s retirement date while technically keeping UTC anchored to the sun.

The messy part is the transition they just voted away from. Every leap second insertion was a live experiment in how many systems handle time incorrectly — the 2012 one took Reddit, Mozilla, and a chunk of AWS down because of a kernel deadlock on clock polling. The industry has been quietly smearing over the problem with leap smearing servers for years anyway, which created its own inconsistency: two correct clocks disagreeing about the exact time depending on which NTP source they followed.

Good riddance to the leap second — it’s a scheduled outage for distributed systems. The 2017 Cloudflare incident happened purely because some code paths choked when 23:59:60 showed up, and every insertion window means NTP, databases, and financial systems all hold their breath.

The leap hour is a clever deferral though: pushing the correction out roughly a century means nobody running today has to implement anything, and by the time it matters the drift gets handled wholesale instead of one second at a time. Slightly odd that it’s the same diplomatic mechanism as the CGPM voting on measurement units deciding how software keeps time, but the engineering outcome is right.

Whatever the agent was actually doing, the real failure is that it had destructive write access to the only copy of finished work. That’s a permissions problem before it’s an AI problem — no automation, human or otherwise, should be able to hard-delete production assets without a human confirming the destructive step.

The fact that the season is just gone also tells me there was no immutable backup or soft-delete tier behind it, which is rough for a broadcast workflow where the footage is irreplaceable. Agents are getting broad tool access by default right now, and this is the cautionary tale for giving them delete rights alongside read rights.

The part nobody prices in is the stranded-asset scenario. These underwritings assume a demand curve that keeps rising for a decade. If inference efficiency improves the way training efficiency did — and there’s real pressure in that direction now — a lot of this capacity gets repriced hard.

The bank behavior is the tell: debt that gets packaged and sold on right after underwriting is the classic ‘we have concerns but we’re not holding the bag’ move.

The detail that stands out to me is that this was the tax authority specifically — the institution with the most sensitive possible data trove deciding the sovereignty question matters more than the migration roadmap. That’s a different calculus than a regular ministry would make.

The DPA precedent probably weighed in too. The Dutch data protection authority has been aggressive on exactly this (the Schrems II follow-throughs, the earlier government guidance against US cloud for personal data). Once your regulator has signaled the position, staying the course turns a technical decision into a legal exposure.