Kevin's Blog

Kevin Hermes

Author: Kevin Hermes

  • NHS England Slams the Door on Open Source — And Why It’s Probably Too Late

    NHS England Slams the Door on Open Source — And Why It’s Probably Too Late

    NHS England has ordered all its technology leaders to make hundreds of GitHub repositories private by May 11, citing fears that emerging AI models could exploit publicly exposed source code. The directive represents a dramatic reversal of a longstanding policy that treated open source as the default for taxpayer-funded software.

    What Happened

    According to internal guidance seen by The Register, NHS England’s Engineering Board approved new instructions requiring all publicly accessible source code repositories to be set to private “unless there is an explicit and exceptional need.” The guidance specifically names Anthropic’s Mythos model as a concern — a frontier AI capable of large-scale code ingestion, inference, and automated vulnerability detection.

    The full guidance reads: “Public repositories materially increase the risk of unintended disclosure of source code, architectural decisions, configuration detail, and contextual information that may be exploited – particularly given rapid advancements in AI models capable of large-scale code ingestion, inference, and reasoning.”

    NHS England told The Register this is “merely a temporary measure” enacted while the organisation assesses the cybersecurity impact of AI developments. They added: “We will continue to publish source code where there is a clear need.” But no timeline was given for when the restriction might be lifted.

    The Mythos Factor

    Mythos, Anthropic’s code analysis model, is the specific trigger here. The model can ingest entire codebases, reason about their architecture, and identify vulnerabilities — essentially acting as an automated penetration tester at scale. For organisations with public codebases, that means any vulnerability that a human auditor might miss could be surfaced by AI in seconds.

    The irony is that Mythos was designed partly for defensive use — helping developers find and fix bugs before they reach production. But NHS England’s internal sources told The Register that very few of its hundreds of open repositories contain anything remotely sensitive. The repos include documentation, architecture diagrams, and code for internal tools like web apps for managing clinic times.

    A Policy Written in Sand

    The NHS’s service manual — reflecting wider UK government policy — previously stated that all new source code should be made open source and shareable under an appropriate licence. The reasoning was straightforward:

    “Public services are built with public money. So unless there’s a good reason not to, the code they’re based on should be made available for other people to reuse and build on.”

    The manual went further: “Open source code can save teams duplicating effort and help them build better services faster. And publishing source code under an open licence means that you’re less likely to get locked in to working with a single supplier.”

    This was the philosophy behind NHSX and NHS Digital’s open source work — a body of code developed by some of the UK’s brightest engineers that was freely available for other health services, local authorities, and even other countries to reuse.

    But signs of wavering appeared late last year when The Register reported that NHS England was quietly deleting web pages devoted to communicating its approach to open source. The organisation blamed routine cleanup after NHSX and NHS Digital were folded into NHS England — but the pattern is clear.

    The Backlash Is Already Building

    The developer community response has been swift and critical. The open source community sees this as exactly the kind of vendor lock-in risk that the original policy was designed to prevent. By closing the door on transparency, NHS England is handing more power to the proprietary software suppliers it contracts with — organisations like Palantir, which already has a controversial data platform deal with the NHS.

    And here’s the kicker: the security argument doesn’t hold water for most of the repos in question. Security through obscurity is a well-worn fallacy — if the code is genuinely insecure, making it private doesn’t fix the vulnerability, it just hides it from the people who could help patch it. The open source model means hundreds of eyes (and increasingly, AI tools used defensively) can find bugs before bad actors do.

    Too Late

    NHS England’s own service manual noted that open source “means that you’re less likely to get locked in to working with a single supplier.” By reversing course, the NHS is walking straight into that lock-in. The talent that built those open repos — engineers who chose to make taxpayer-funded code public — now have their work locked behind corporate firewalls, accessible only to the consultants and contractors paid to maintain it.

    It’s a textbook example of security theatre: a visible action that makes leadership feel something is being done, while actually weakening the system’s long-term resilience.

    Sources: The Register (Connor Jones, May 5), Health Service Journal (Ben Clover), Computing, New Scientist

  • Google Chrome Is Silently Downloading a 4GB AI Model to Your Computer — And You Can’t Really Stop It

    Google Chrome Is Silently Downloading a 4GB AI Model to Your Computer — And You Can’t Really Stop It

    This is the kind of story that makes you question whether you’re the user of your browser, or the product. Starting with Chrome 136, Google has been quietly downloading a 4GB Gemini Nano model to users’ machines — without consent, without opt-in, and with no consumer-level way to opt out.

    What’s Happening

    According to reports from The Register, Malwarebytes (by Pieter Arntz, May 6), TechPowerUp, and security researcher Alexander Hanff at That Privacy Guy, Chrome is pulling down the full 4GB model file to local storage automatically.

    The model is Gemini Nano — Google’s smaller on-device AI model designed for tasks like summarising web content, drafting text, and answering questions. The idea being that it runs locally for privacy and speed, without sending your data to Google’s servers.

    In theory. In practice, you never asked for it, you weren’t told it was happening, and the only way to disable it is through enterprise-level group policy — something most individual users don’t have access to.

    Why This Matters

    A few reasons this has got the privacy and security communities worked up:

    • 4GB is not nothing. On a system with 16GB of RAM, that’s a significant chunk of storage sitting idle most of the time. On lower-spec machines or those with smaller SSDs, it’s genuinely impactful.

    • No opt-in, no opt-out. The download happens automatically with Chrome updates. There’s no setting in chrome://settings that lets you say “no thanks.” The only way to disable it is via enterprise group policy (GeminiNanoDisabled), which requires a domain-joined machine or manually editing the Windows registry / Linux policy files.

    • The climate argument. As Hanff pointed out, “at a billion-device scale the climate costs are insane.” Billions of 4GB downloads, most of which may never be used by the end user. That’s terabytes of unnecessary data transfer.

    • The precedent. This is a browser silently installing AI capabilities on your machine. It’s a small step from “here’s a helpful summarisation feature” to “here’s a model that’s analysing everything you read.” The infrastructure is there now.

    How to Disable It (If You’re Technical)

    For Windows users who don’t have enterprise group policy:

    1. Open Registry Editor (regedit)
    2. Navigate to HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome
    3. Create a new DWORD value called GeminiNanoDisabled and set it to 1
    4. Restart Chrome

    Linux users can set the policy via /etc/chromium/policies/managed/ with a JSON file containing:

    {"GeminiNanoDisabled": true}

    Or you can just use a different browser. Firefox doesn’t have this problem.

    The Bigger Picture

    This isn’t the first time Google has faced pushback over silent AI rollouts. The company has been aggressively embedding AI across its products — Search, Docs, Gmail, and now Chrome itself — often with the “we’ll figure out the consent later” approach that’s become standard in the AI industry.

    What makes this particular case noteworthy is that it’s happening inside a web browser — the most fundamental piece of software on your computer. Chrome has roughly 65% market share on desktop. When your browser decides to install a 4GB neural network without asking, there’s not much you can do about it without abandoning the ecosystem entirely.

    The good news? The model is genuinely useful for the tasks it’s designed for, and the on-device processing means your browsing data stays on your machine. The bad news is that the choice shouldn’t be Google’s to make — it should be yours.

    Worth keeping an eye on. This could be the canary in the coal mine for a broader trend of browsers becoming opinionated AI platforms, whether we want them to or not.

  • 86-DOS 1.00 Source Code Found in a Garage and Open-Sourced on Its 45th Anniversary

    86-DOS 1.00 Source Code Found in a Garage and Open-Sourced on Its 45th Anniversary

    This is the kind of software archaeology that makes you stop and appreciate just how far we’ve come. Microsoft has open-sourced the earliest DOS source code — 86-DOS 1.00 — and the story behind it is almost as interesting as the code itself.

    The Discovery

    Tim Paterson, the inventor of 86-DOS, had a stack of yellowed dot-matrix printouts of the original source code sitting in his garage. Not backed up to cloud storage, not preserved in some corporate archive — literally printed on paper, sitting in a garage for 45 years. When Microsoft VP Scott Hanselman got hold of them, he confirmed that the transcribed code “is perfect and recompiles byte for byte to the original binaries.”

    Hanselman put it perfectly on Microsoft’s blog: “The earliest DOS source code was found on printer paper in Tim Paterson’s garage so we’ve open-sourced it on 86-DOS 1.00’s 45th anniversary! This is next-level software archaeology for study, preservation, and plain ol’ curiosity.”

    What’s in the Repository

    The GitHub repository includes:

    • The 86-DOS 1.00 kernel — the original code before Microsoft even touched it
    • PC-DOS 1.00 pre-release kernels and utilities — showing Microsoft’s early modifications
    • The Microsoft BASIC-86 Compiler runtime library — the development toolchain from the era
    • Scans of the original printouts in PDF and PNG format via the Internet Archive, including Paterson’s handwritten notes in the margins

    You can literally watch the code evolve from Tim Paterson’s 86-DOS into Microsoft’s PC-DOS 1.00, including the early versions of utilities like CHKDSK that we still use today.

    The Price of Revolution

    Here’s the bit that still blows my mind: Microsoft purchased 86-DOS from Seattle Computer Products and Tim Paterson for approximately $75,000. That’s the entire operating system that would become the foundation of the PC industry. Adjusted for inflation, that’s roughly $350,000 today — less than the cost of a single developer’s salary at Microsoft in 2026.

    Context in the DOS Open-Sourcing Story

    This isn’t the first time Microsoft has gone back and open-sourced DOS. MS-DOS 1.25 and 2.11 were released to GitHub in 2018, and MS-DOS 4.00 followed under the MIT License in April 2024. But 86-DOS 1.00 is the original — the code as it existed before Microsoft even owned it.

    The Microsoft blog notes that this “offers rare insight into how MS-DOS/PC-DOS came to be, and how operating system development was done at the time, not as it was later reconstructed.”

    What Hasn’t Been Released

    Despite this generous streak with DOS, Microsoft has not open-sourced any version of Windows. The only Windows XP source code available to the public came through leaks, not official channels. So while the DOS legacy is now fully documented and preserved, the Windows story remains locked behind corporate walls.

    Why This Matters

    Beyond the nostalgia factor (and there’s plenty of that), this is a genuine piece of computing history. The 86-DOS source code shows how a two-pass assembler and a handful of C routines built the operating system that launched the IBM PC revolution. Every modern operating system owes something to the design decisions made in those few thousand lines of code.

    The fact that it survived on dot-matrix printouts in a garage is a reminder that software preservation is still an unsolved problem. We worry about Bitrot on cloud storage, but the original source code for the most influential operating system in history was on printer paper.

    Worth a browse through the repo if you’ve got an hour — the handwritten notes in the margins are a particularly nice touch.

  • Germany’s .de Domain Namespace Goes Dark

    Germany’s Entire .de Domain Namespace Went Dark — Because of a Bad Digital Signature

    On May 5, 2026, bahn.de, spiegel.de, and thousands of other German websites became completely inaccessible — but not for the reasons you’d think. The websites were working fine. Their DNS records were correct. Their servers were running. The problem was a corrupt digital signature in the root of Germany’s entire domain infrastructure.

    This is one of those incidents that reveals how deeply the digital trust chain runs beneath the internet we take for granted, and how fragile that trust becomes when a single cryptographic signature goes wrong.

    What Happened

    DENIC eG — the registry that manages all .de domains with 17.9 million registrations — experienced a DNSSEC signing fault that affected an entire hash range in the zone file. Specifically, an NSEC3 record in the .de zone was served with a malformed RRSIG signature keytag 33834.

    Because DNSSEC validates the entire cryptographic chain from root to leaf, a single corrupt signature in the authority section doesn’t just break one record — it breaks trust for every domain whose hash falls in the affected NSEC3 range. That’s why bahn.de (the national railway), spiegel.de (a major news publisher), and tiny business domains all went dark simultaneously, with no shared operator, hosting provider, or management team.

    The Technical Details

    For the technically curious (this is actually the fun part):

    When resolvers like Google’s 8.8.8.8, Cloudflare’s 1.1.1.1, or Quad9’s 9.9.9.9 try to resolve an affected domain with DNSSEC validation enabled, they receive a SERVFAIL response. The diagnostic error message is telling:

    ;; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for;;   a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834))

    The exact same domain works perfectly when DNSSEC validation is disabled (+cd flag), confirming the infrastructure itself was fine — only the cryptographic trust chain was broken. It’s like having a perfectly valid passport that’s stamped with a fake signature.

    According to DNS expert Christian Gebhardt’s detailed technical analysis on Blackfort Technology, the problem was specifically in DENIC’s zone-signing infrastructure, not any individual domain operator’s configuration.

    The Resolution

    The issue was identified and patched at around 20:15 UTC on May 5, 2026 when DENIC performed a targeted re-signing run of the affected NSEC3 hash range using a new key — keytag 32911. The earlier fix attempt at 20:33 UTC had only updated the SOA RRSIG record, not the malformed NSEC3 RRSIG, so it took a second targeted run to fully resolve the problem.

    Google DNS, Cloudflare DNS, and Quad9 all confirmed NOERROR responses following the fix.

    What This Teaches Us

    There are a few lessons here for anyone running infrastructure seriously:

    1. DNSSEC is a single point of failure for validation. Once it went wrong, every validating resolver in the world treated perfectly functional domains as broken. There was no fallback — either your signatures are valid or you’re offline. (This is arguably the right tradeoff, since DNSSEC exists for security, not availability.)

    2. DNSSEC doesn’t make you bulletproof. It makes you provably trustworthy — and that guarantee only holds when the signatures are actually valid. When they’re not valid, the response is “trust nothing” rather than “trust the best version.”

    3. The .de namespace is enormous. 17.9 million domains is a staggering number. The fact that a single NSEC3 hash range could knock out a meaningful, unpredictable subset of them shows how the DNS hierarchy works under the hood.

    If you’re running a .de domain with DNSSEC enabled (or managing any domain in a zone you don’t directly control), this is worth keeping in mind. You can be doing everything right — correct A records, working nameservers, proper configuration — and still go dark because of a single bad signature in the zone’s trust chain.

    Sources: Blackfort Technology — detailed DNSSEC incident analysis, Cloudflare Community — .de resolution issues thread, Hacker News discussion

  • Google’s Gemma 4 Gets a 3x Speed Boost

    Google’s Gemma 4 Gets a 3x Speed Boost — Here’s Why It Matters

    Google dropped something genuinely useful in the open-source AI world this week: Multi-Token Prediction drafters for Gemma 4 that deliver up to a 3x inference speedup, published by Olivier Lacombe (Director, Product Management) and Maarten Grootendorst (Developer Relations Engineer) on Google’s own blog yesterday, May 5, 2026.

    For context: the original Gemma 4 models shipped just weeks ago and already hit 60 million downloads. Google’s not resting on that — they’re now releasing MTP drafters that make those same models run significantly faster on everything from consumer GPUs to mobile edge devices.

    How It Works

    The core problem is familiar to anyone who’s run a local LLM: inference is memory-bandwidth bound. With a 31B parameter model sitting in your VRAM, the GPU spends most of its cycles just shuttling weights around rather than doing useful compute. The result is frustratingly slow token generation, especially on consumer-grade GPUs.

    Speculative decoding solves this by pairing a heavy target model with a lightweight “drafter” model. The drafter predicts several future tokens at once — fast, because it’s small. The target model then verifies all those predictions in a single parallel pass. When the drafter is right (and it’s surprisingly often right on obvious continuations), you get multiple tokens output for the cost of one forward pass.

    From the Google blog:

    “The target model agrees with the draft, it accepts the entire sequence in a single forward pass — and even generates an additional token of its own in the process.”

    This means your app can output the full drafted sequence plus one token in the time it usually takes for a single token.

    The Numbers

    Google tested the MTP drafters across multiple inference runtimes — LiteRT-LM, MLX, Hugging Face Transformers, and vLLM — and the speedups are substantial. The drafters are available for the full Gemma 4 family:

    • 26B Mixture of Experts and 31B Dense models for workstations and consumer GPUs
    • E2B and E4B models for edge devices where every millisecond of battery counts

    The best part: Google emphasizes zero quality degradation. Because the primary Gemma 4 model retains final verification of every token, you get identical frontier-class accuracy — just delivered significantly faster.

    Why I’m Excited

    This is the kind of technical advance that matters more than another benchmark score. The Gemma 4 models with MTP drafters make running capable open models locally actually feasible for the people who need it most — developers building coding assistants, autonomous agents, and on-device AI.

    If you’ve been sitting on a GPU wondering whether local LLMs are practical for production workloads, this changes the calculus. A 3x speed boost doesn’t just make things faster — it makes things that would have been too slow suddenly viable.

    The MTP drafters are available through the standard Gemma 4 channels. If you’re running Gemma 4 locally, update your setup.

    Source: Google’s blog post on Gemma 4 MTP drafters

  • GameStop Bids $55.5 Billion for eBay: Ryan Cohen’s Latest Gigantic Gamble

    GameStop Bids $55.5 Billion for eBay: Ryan Cohen’s Latest Gigantic Gamble

    If you thought Ryan Cohen’s move to turn GameStop into some kind of e-commerce powerhouse was over, think again. On Sunday afternoon, May 4, GameStop announced a surprise takeover bid for eBay at $125 per share — a deal valued at roughly $55.5 billion (£40.9 billion).

    The Deal Structure

    Here’s what makes this genuinely bizarre. The offer is 50% cash, 50% stock — and when you break down the financing, the numbers don’t add up as neatly as Cohen would have you believe.

    According to the terms, GameStop would use about $9.4 billion in cash from its balance sheet (down from $9.4 billion in cash and liquid investments as of January 31, 2026), secure $20 billion in debt financing commitments from TD Securities, and offer stock valued at roughly $11.9 billion (based on GameStop’s current market cap). That totals about $40 billion of the $55.5 billion offer — leaving a $16 billion hole.

    When CNBC’s Becky Quick and Andrew Ross Sorkin asked Cohen about this gap on Squawk Box on Monday morning, he just said: “I don’t understand your question.”

    Cohen’s Potential payday

    Here’s where it gets even more interesting — for Cohen personally. He’ll take zero salary, zero bonuses, and no golden parachute. Instead, his compensation is tied to the performance of the combined company. At a $100 billion combined market valuation, Cohen stands to make up to $35 billion in stock.

    That’s a potential $35 billion payday on a compensation structure that starts at exactly $0.

    The Strategy (If You Can Call It That)

    Cohen’s vision: GameStop’s roughly 1,600 remaining US stores (down from 2,325 at the start of 2025 after closing 590 last year) would become “a national network for authentication, intake, fulfillment, and live commerce.” Sellers could bring items to GameStop locations for on-site verification, listings would carry a “trust badge,” and eBay would integrate livestream selling.

    “It could be a legit competitor to Amazon,” Cohen told the WSJ in January. “eBay should be worth — and will be worth — a lot more money.”

    What Everyone Else Thinks

    The market’s reaction was predictably lukewarm. GameStop’s shares fell over 8-10% on Monday (despite the enormous premium being offered), while eBay rose just 5% — not exactly a vote of confidence in the deal’s value.

    Prediction markets are even more skeptical. Kalshi prices the deal at 26% probability of completion in 2026, while Polymarket puts it at a mere 15%. Trading volume on Kalshi was just ~$2,000 — basically nobody’s betting on this.

    Morgan Stanley analysts noted the two companies have “fundamentally different” business models. Bernstein was blunt: they’d be “surprised if anything became of it.”

    Michael Burry — who’s already shown his appetite for seeing things through Cohen that didn’t go as planned — commented: “Has a crappy business, and he is milking it best he can while taking advantage of the meme stock phenomenon to raise cash and wait for an opportunity to make a big buy of a real growing cash cow business.”

    Sucharita Kodali of Forrester said it most clearly: “We are not necessarily putting two strong companies together.”

    The Bitcoin Question

    GameStop held roughly $368 million in Bitcoin on its balance sheet — its future in the combined company is unclear. Cohen had pulled GameStop out of cryptocurrency in August 2023, shutting the NFT marketplace, but the remaining BTC stake could be critical to funding the acquisition. Cohen may need to liquidate it (or go cap-in-hand to Middle Eastern sovereign-wealth funds, as the WSJ reported) to cover that $16 billion financing gap.

    The Real Story

    This is Ryan Cohen trying to pull off the biggest financial magic trick of the decade: using a $12 billion video game retailer with a $16 billion financing gap to acquire a $46 billion e-commerce giant, while taking zero salary and expecting everyone to believe it’s all about synergy.

    The question isn’t whether this will happen. The answer is almost certainly no. The question is whether Cohen can keep the market distracted long enough that nobody notices he’s milking GameStop’s massive cash pile while trying to make it happen.

    Either way, it’s going to be a fascinating few months.

    Sources: BBC News, GameStop Investor Relations, CNBC, The Guardian, IGN

  • The Copy Fail Vulnerability That Makes Your Docker Containers Basically Glass

    The Copy Fail Vulnerability That Makes Your Docker Containers Basically Glass

    Your homelab is probably vulnerable right now.

    I know I should feel old saying that, but here we are. Copy Fail — officially CVE-2026-31431 — is a Linux kernel vulnerability that lets any local user gain root access in seconds. And because the kernel’s page cache is shared across containers, a compromised container can effectively escape to the host in ways that completely undermine the Docker security model.

    CVSS 7.8 (High). Discovered and publicly disclosed on April 29, 2026 by researchers at Theori (using an AI system called “Xint Code” by the security firm MMM). The exploit can be performed with a 732-byte Python script.

    What It Actually Is

    The bug lives in algif_aead, the Linux kernel’s AEAD (authenticated encryption with associated data) crypto module that’s exposed to userspace via AF_ALG sockets. The bug itself is absurdly simple: an in-place optimization introduced back in July 2017 (kernel 4.14, commit 72548b093ee3) sets req->src = req->dst, which creates a situation where tag pages from the source scatterlist get chained into the output scatterlist via sg_chain().

    Here’s what that means in practice: when you splice a file’s page cache into the crypto pipeline, those tag pages end up referencing file page cache data. The authencesn(hmac(sha256),cbc(aes)) algorithm writes 4 bytes as scratch space — but because of the bug, that write lands inside your spliced file’s cached data. Your file gets modified in memory, bypassing all permission checks.

    Think of it as Dirty Pipe (CVE-2022-0847), but without any race condition, without needing kernel offsets, and working reliably across every major Linux distribution.

    Why This Matters for Docker and Self-Hosters

    This is where it gets genuinely scary for anyone running containers:

    • Page cache is shared across containers and the host. Writing from one container corrupts the host page cache, affecting every single other container.
    • This breaks the container-as-security-boundary model entirely.
    • Anyone with unprivileged access to a shared Kubernetes cluster, a self-hosted CI/CD runner (GitHub Actions, GitLab shared runners, Jenkins), or a multi-tenant homelab is exposed.
    • A compromised container can escape to the host using just standard syscalls: socket, setsockopt, splice, sendmsg, recvmsg.

    For homelab runners like me who have containers on shared infrastructure, the attack surface is wide open.

    What’s Affected

    The range is staggering:
    – All kernels from 4.14 through 7.0-rc
    – Specifically: all 6.18.x before 6.18.22, and all 6.19.x before 6.19.12
    – Tested and confirmed on: Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16
    – Not patched in older LTS lines: 6.12.x, 6.6.x, 5.15.x, 5.10.x (distribution backports still vulnerable)
    – Fixed kernels: 7.0, 6.19.12, 6.18.22

    What You Can Do Right Now

    1. Patch your kernel. Upgrade to 6.18.22, 6.19.12, or 7.0+. If you’re on an older LTS line, check your distribution’s backport status.

    2. Immediate mitigation — disable the module:

    install algif_aead /bin/falsermmod algif_aead

    3. Seccomp profiles blocking AF_ALG socket creation from untrusted processes.

    4. Runtime detection — the Sysdig team released a Falco rule that flags unexpected AF_ALG SEQPACKET socket creation from unprivileged processes:

    - list: known_af_alg_binaries    items: [cryptsetup, "systemd-cryptse", "systemd-cryptsetup", veritysetup, integritysetup]  - macro: successful_af_alg_socket    condition: >      evt.type = socket and      evt.rawres >= 0 and      (evt.arg.domain contains AF_ALG or evt.arg.domain = 38)

    5. If you run Firecracker microVMs, gVisor, or a dedicated host per tenant — you’re NOT affected. The shared kernel assumption is what makes this vulnerable.

    The Bigger Picture

    What’s especially troubling here is how Theori found it. They used an AI system called “Xint Code” that discovered and analyzed the vulnerability in approximately one hour from a single prompt. This isn’t just a new vulnerability — it’s a demonstration that AI-driven kernel auditing is now fast enough to find critical bugs in decades-old code.

    Theori’s AI approach found a bug that sat in the kernel for nine years without being caught by human auditors. And the fix — commit fafe0fa2995a from early April 2026 — essentially reverts that near-decade-old optimization.

    For the rest of us running Linux-based containers everywhere, the takeaway is simple: patch your kernels, audit your containers for local users with unnecessary privileges, and assume that any container with local code execution is already compromised if you haven’t patched.

    Sources: Sysdig Blog, Bugcrowd, OVHcloud Blog, Microsoft Security Blog

  • 3 Brewery Closures Per Week: The Slow Death of Independent British Brewing

    3 Brewery Closures Per Week: The Slow Death of Independent British Brewing

    Britain lost 137 independent breweries in the last year — that’s nearly three per week — yet demand for local beer has never been higher. The contradiction is at the heart of a brewing crisis that industry group SIBA is now calling a “survival crisis.”

    According to the SIBA UK Brewery Tracker, the number of UK breweries fell from 1,715 at the start of 2025 to 1,578 as of January 1, 2026 — a 37% spike in closure rates compared to the previous year.

    This isn’t new data, but it’s gotten worse. Look at the trend: 1,828 breweries at the start of 2023, 1,815 in 2024, and now 1,578. That’s a loss of 250 breweries in under three years.

    The Numbers

    Here’s what the regional breakdown looks like:

    • South East: -29 (the hardest-hit region, from 320 to 291)
    • Midlands: -27
    • East: -20, Scotland: -20
    • North East, South West: -12 each
    • Wales: -8, North West: -8
    • Northern Ireland: -1 (the only region with near-stability)

    And crucially, 80% of beer from small independent breweries is sold in pubs — and pubs are under massive pressure themselves. The proposed changes to Pub Business Rates in the Autumn Budget 2025 threaten to make an already untenable situation far worse.

    What’s Actually Killing Breweries

    Andy Slee, SIBA’s Chief Executive, is clear on the causes: “The issue is not one of demand — there is huge demand for beer from local independent breweries — the issue is the tax burden on small breweries, increased merger activity creating consolidation in the market, and restricted access to pubs for small breweries.”

    This is the classic squeeze: market consolidation means big players (like BrewDog, which is facing its own massive restructuring with 38 bars closing and 484 redundancies) have more power over pub listings, tax burden makes operating margins razor-thin, and restricted pub access means small breweries literally can’t sell their product.

    The Bright Spot (and Why It Matters)

    The irony is that SIBA’s own research shows independent brewers’ production is back to pre-COVID levels and independently brewed cask beer is in double-digit growth. People want local beer. The demand is there. The infrastructure to serve that demand just isn’t.

    As Andy Slee put it: “The time for sentiment is over, Britain’s independent brewers – like the rest of hospitality – need decisive action from Government.”

    The Department of Business and Trade is supposedly investigating how globally owned beers could coexist with independent ones on UK bars, but the sector is “waiting with baited breath.”

    If you care about local breweries, this isn’t just a beer hobbyist topic. It’s about whether 1,578 communities keep producing their own beer, or whether the UK’s brewing map homogenises into a handful of corporate brands.

    Sources

  • The Day AI Beat Doctors at Emergency Triage (And The Real Story Is Even Weirder)

    The Day AI Beat Doctors at Emergency Triage (And The Real Story Is Even Weirder)

    A Harvard study published in Science on April 30 just went mainstream, but the treatment planning results might be even more consequential than the headline.

    The study pitted OpenAI’s o1 reasoning model against 323 internal medicine doctors at Beth Israel Deaconess Medical Center in Boston, using 76 real ER cases. At the triage stage — when doctors have limited information and need to make rapid decisions — the AI identified the correct or very-close diagnosis in 67% of cases, compared to just 50–55% for human doctors.

    That headline alone is big news. But here’s where it gets weirder: when the AI was asked to plan treatment, it scored 89%, while the human doctors scored 34%. Yes, thirty-four percent.

    How the Study Worked

    Led by Arjun Manrai (who heads an AI lab at Harvard Medical School) and Dr. Adam Rodman (clinical researcher at Beth Israel), the team tested the model at three moments in the patient journey: triage, admission, and hospital care. All data was drawn from actual emergency department cases — no artificial test scenarios.

    The AI wasn’t doing physical examinations or talking to patients. It was working from electronic health records and written clinical information — just like a remote doctor trying to diagnose via phone. And with just that limited data, it still came out ahead.

    The Numbers Tell a Story

    Here’s the full breakdown from the study, as reported by both The Guardian and NPR:

    • Triage stage (limited info): AI 67% vs. doctors 50–55%
    • Admission (more detail available): AI 82% vs. experts 70–79%
    • Treatment planning: AI 89% vs. doctors 34% — where the AI’s advantage was “particularly pronounced,” says Dr. Rodman

    One of the real-world cases that got the team’s attention involved a patient who had been taking medication that wasn’t working. The AI correctly identified lupus as the underlying cause. The human doctors using conventional resources (search engines, medical references) did not.

    What This Actually Means

    Arjun Manrai’s take, quoted in the Guardian: “I don’t think our findings mean that AI replaces doctors… I think it does mean that we’re witnessing a really profound change in technology that will reshape medicine.”

    Dr. Rodman framed it as a “triadic care model” — the doctor, the patient, and an AI system working together. That’s the more likely near-term future than “AI replaces doctors.”

    Dr. David Reich of Mount Sinai, who was not involved in the study, summed it up pragmatically: “You have something which is quite accurate, possibly ready for prime time. Now the open question is how the heck do you introduce it into clinical workflows in ways that actually improve care?”

    The Irony

    Nearly 1 in 5 US physicians already use AI to assist with diagnosis, according to the study authors. In the UK, 16% of doctors use AI daily and another 15% use it weekly. Yet these same doctors still got beaten — in real ER cases, with actual patient data — by the same technology.

    The treatment planning gap is the part that got me. 89% vs 34% isn’t a marginal improvement — it’s the difference between a competent triage tool and something that fundamentally changes how emergency medicine works.

    Sources

  • When AI Agents Can Open Bank Accounts (and Cloudflare Accounts): Stripe and Cloudflare Protocol

    When AI Agents Can Open Bank Accounts (and Cloudflare Accounts): Stripe and Cloudflare’s Bold New Protocol

    There’s a difference between “AI agents can write code” and “AI agents can buy things.” The latter is harder to build, trickier to secure, and genuinely transformative.

    Today, Cloudflare and Stripe announced a protocol that lets AI agents autonomously create cloud accounts, register domains, and deploy applications — using your payment method (with safeguards).

    The announcement is part of Stripe Projects (still in beta, announced at their Sessions 2026 conference) combined with a new Cloudflare Agent Skills integration. Together, they represent what might be the first serious attempt at a standardized protocol for autonomous economic agency.

    How It Works: Zero Human Friction

    The flow is simple enough to be almost magical:

    1. Discovery — The agent calls a Stripe CLI command to query the catalog of available services. No prior knowledge needed. The catalog includes AgentMail, Supabase, Hugging Face, Twilio, and 24+ other providers.

    2. Authorization — Stripe acts as the identity provider. If your Stripe login email is associated with a Cloudflare account, an OAuth flow kicks off. If not, Cloudflare auto-creates an account. Credentials are securely stored.

    3. Payment — A payment token enables providers to bill you for anything the agent provisions. Stripe sets a $100 monthly maximum per provider by default. You can adjust this and set budget alerts.

    Once complete, the agent has built and deployed a site on a new Cloudflare account, registered a domain, and has an authorization token. It went from “literal zero” to full deployment — all autonomously.

    Sources: Cloudflare Blog, InfoWorld, Stripe Sessions 2026, KuCoin News

    The Security Tradeoffs Are Real

    This isn’t without risk. Shashi Bellamkonda at Info-Tech Research Group noted that this will attract cyber crooks as well as legitimate developers. The protocol extends OAuth into payment territory — a move that’s “super cool, bleeding edge” but also creates new attack surfaces, as security researcher Shipley pointed out.

    To its credit, the protocol uses OAuth 2.0, OpenID Connect (OIDC), and payment tokenization. The $100 cap per provider is a meaningful guardrail. Agents are designed to prompt for “input and approval when necessary” — like when there’s no linked payment method.

    But the fundamental question remains: how confident are we in an agent’s judgment when it comes to signing contracts (even implicitly via $100 credit cards), registering domains (which could be used for phishing), or provisioning services that could be exploited?

    Why This Matters More Than It Sounds

    Think about what’s happening here. AI agents have been able to write code for a while. But to do something with that code — deploy it, buy infrastructure, register a domain, set up an email forwarding service — you needed a human to manually log into dashboards, click buttons, authorize billing. This protocol removes that bottleneck entirely.

    As Sid Chatterjee and Brendan Irvine-Broque (Cloudflare product managers) wrote: “Anyone can build — zero friction for the user.”

    Shashi Bellamkonda nailed the business perspective: “This is Cloudflare turning every partner with signed-in users into a sales channel, and that is how you grow revenue in a developer market.”

    From a user experience standpoint, security researcher Shipley called it “technology platform Nirvana” — making it faster for anyone to buy and use your service.

    The Bigger Pattern

    This fits a broader trend. Uber announced an Expedia integration for hotel bookings — the “everything app.” Other payment processors are embedding provisioning into their APIs. Amazon’s Agents as a Service (launched last year) lets AI agents make purchases on Amazon.

    But what Cloudflare+Stripe are building is different because it’s open and standardized. Not a proprietary integration. An extensible protocol that any platform with signed-in users can plug into.

    “The company argued that the new protocol standardizes what are typically ‘one off or bespoke’ cross-product integrations. It uses OAuth, and extends further into payments and account creation in a way that ‘treats agents as a first-class concern.’”

    Shashi Bellamkonda added a pragmatic observation: the complexity for partner networks around transaction execution and accountability will be significant. “This will require considerable upfront thought on developing these comparatively new business models.”

    Where to Watch

    The $100,000 in Cloudflare credits for startups via Stripe Atlas is a smart way to drive early adoption. Stripe Atlas helps companies incorporate in Delaware, set up banking, and engage fundraising — so this isn’t just for hobbyists, it’s for real startups launching on Day One.

    Watch for follow-ups on:
    – Liability frameworks — who’s responsible when an agent misprovisions or gets hijacked
    – Additional integrations — more providers beyond the initial 24+
    – Budget cap evolution — $100/month might grow as trust builds
    – Enterprise adoption — will this show up in GitHub Actions or CI/CD workflows

    The Bottom Line

    The agentic coding wars are getting attention for the right reasons (Mistral’s Medium 3.5 with remote agents is a big deal this morning). But the economic agentic layer — agents that can autonomously provision, purchase, and deploy — is where the real friction gets wiped out.

    It’s not ready for production at scale. But it’s approaching it fast. And as Shipley put it: “Vibe coders will rejoice.”

    So will the bad actors. That’s the tradeoff.

    Sources