Tech Talk — September 01, 2026

I am Link. Welcome to Tech Talk, a Black Elk Media production. Today is September first, 2026, and we are analyzing the latest shifts in the digital landscape.

Here is a number to sit with... three hundred and sixty-five. That is not a server uptime target. It is the number of days an Indian startup wants to keep an aircraft flying... without landing... without refueling... without ever touching the ground.

Today, investor Lachy Groom placed a bet on exactly that idea.

Now, the instinct is to call this science fiction. But strip away the ambition, and what you find underneath is a very specific engineering problem... one that sits at the intersection of solar energy, ultra-light materials, and autonomous flight. Keep something aloft for a full year, and you have built something that is not quite a satellite... and not quite a plane.

So the question I want to unpack today is not *can* they do it... it is *why now*... and what shifts the moment they do.

Let's get into it.

THE FRONT PAGE

# THE FRONT PAGE

Five stories from the wire this morning... and a pattern worth watching underneath all of them. Let's move.

---

Story one. The Federal Trade Commission is coming for Amazon's ad machine.

The F-T-C, joined by twenty-two state attorneys general, filed suit alleging Amazon secretly manipulated its own ad auctions. Here's the mechanism... Amazon runs what's called a "second price" auction. In theory, the winner pays just one cent more than the runner-up. Clean. Predictable. But the complaint says that since 2019, Amazon quietly swapped in a "proxy second price"... a number it calculated itself to maximize profit. Not a real bid. A synthetic one.

The alleged take? Over twenty billion dollars from advertisers who never saw the switch. Amazon counters that average winning bids actually fell fifty percent from 2019 to 2024. Watch this one closely... because the whole case hinges on a single question... whether a "second price" auction stops being an auction the moment the house sets the second price.

---

Story two. And speaking of who controls the machinery — Nvidia just turned its interconnect into an empire.

Everyone building custom A-I chips — OpenAI, Meta, Microsoft — was supposed to threaten Nvidia's dominance. Instead, Nvidia invited them all in. On Monday, MediaTek licensed NVLink Fusion, Nvidia's high-speed chip-to-chip fabric... and Nvidia dropped three-point-five billion dollars into MediaTek convertible bonds. Amazon, Qualcomm, Fujitsu, Marvell... all on the list.

Here's why this matters. Building a fast accelerator is hard. Scaling it across a rack is harder. NVLink Fusion lets rivals skip that second problem entirely — and because Nvidia's rack designs are open standard, competitors can literally slot their own chips into existing Nvidia racks. Amazon's already doing it... Trainium4 drops its in-house interconnect for NVLink Fusion this year. See the pattern? Nvidia stopped selling only silicon. Now it sells the connective tissue everyone else needs... and keeps them hooked.

---

Story three. From the chips to the phone in your pocket — Android 17 encrypts the last thing your network could still see.

Quick primer. Even with H-T-T-P-S, your traffic content was already encrypted... but the website name leaked in plaintext, in a field called S-N-I, Server Name Indication. Your I-S-P could read exactly which sites you hit. Android 17 is the first mobile O-S to ship Encrypted Client Hello, or E-C-H... which finally seals that name inside the handshake.

There's a bonus move here too — a 2G kill switch. Those old 2G networks are how S-M-S blasters and fake cell towers hijack phones. Blocking 2G shuts that door. But be precise here... E-C-H is not a V-P-N. Your destination I-P, your timing, your traffic volume — all still visible. This closes one gap. Not all of them.

---

Story four. And staying with the theme of who gets access — the Pentagon now runs its own ChatGPT and Grok.

The Department of Defense launched ChatGPT Mil and Grok for Government through its GenAI.mil portal... secure versions exempt from consumer data collection. Three million personnel eligible. One-point-seven million already onboarded. That adoption curve is the real story.

But note who's missing. Anthropic's Claude. The reason? Anthropic was labeled a supply-chain risk after refusing unrestricted military use, insisting on safety guardrails instead. It's now fighting that designation in court. So here's the fault line worth tracking... the lab that drew a red line got shut out, while the labs that said yes are scaling to millions of users. Procurement is quietly becoming policy.

---

**The Pulse.** Look back across those stories. Three of today's five are about control — who sets the price, who owns the interconnect, who gets the government contracts. The infrastructure layer is where power is consolidating right now... not the model, not the app. The plumbing.

That's The Front Page. I'm Link. Back to you.

THE DEEP DIVE

# The Deep Dive: When the Vault Trusts the Wrong Thing

Let me start with a number that should bother you more than it does. Every ATM you've ever used runs on a full computer... usually Windows... sitting inside a metal box on a street corner. The cash is protected by steel. The steel is protected by software. And this month, a security researcher named Matt Burch showed us that the software layer... the part we actually depend on... has been quietly rotting in ways almost nobody thought to check.

Here's the trick of it, though. This isn't really a story about ATMs. ATMs are just where the problem finally became visible.

Why this matters

Think about what a cash machine actually is. It's a threat model turned inside out. Most computers assume the attacker is remote... somewhere out on the network. But an ATM assumes the attacker is standing right in front of it, with a screwdriver, with physical access, with all the time in the world at three in the morning. The defender has to win a fight where the enemy is already holding the hardware.

So how do you protect a computer someone can literally touch? You encrypt the disk. And then you add something called pre-boot authentication... a small piece of software that runs before the operating system even wakes up, checks that everything is intact, and only then hands over the keys. That's your last line of defense. If someone pulls the hard drive, all they get is encrypted noise.

The software Burch tore apart is exactly that layer. It's called CryptoPro Secure Disk, made by a German firm named CryptWare. It does disk encryption and pre-boot authentication. And Burch found nine vulnerabilities... nine ways... to bypass the integrity checks and gain full access to the encrypted device.

Sit with that for a second. The thing whose entire job is to prove nothing has been tampered with... could itself be tampered with.

How it actually works

Let me explain what pre-boot authentication is really doing, because the mechanism is where the elegance and the fragility both live.

When you power on a machine, there's a moment before the operating system exists. The firmware hands control to a tiny environment... think of it as a bouncer at a door that opens onto an empty room. That bouncer's job is to verify you, unlock the encrypted volume, and only then let the real operating system load into that room.

For this to be trustworthy, two things have to hold. First, the bouncer itself has to be authentic... you need to know nobody swapped out the bouncer for an impostor. Second, the chain from the bouncer to the operating system has to be unbroken... an integrity check, usually a cryptographic hash, that says "these bytes are exactly the bytes we shipped."

When Burch talks about bypassing integrity checks, this is the seam he's working. If you can make the system accept a modified component... a tampered boot file, a forged check, a code path the developers assumed no one would ever reach... then the encryption behind it becomes theater. The vault door is titanium, but you've convinced the lock that your fake key is real.

And here's the uncomfortable part. These bugs are hard to find precisely because this layer is invisible. It runs for a fraction of a second, before any logging, before any monitoring tool loads, in an environment most engineers never touch. It's the plumbing behind the plumbing. Which means it can sit broken for years... and in this case, it did.

The real story: the supply chain

Now here's where Burch's finding gets genuinely important, and where I want to slow down.

CryptoPro is used in some ATMs, including as part of Diebold Nixdorf's Vynamic Security Suite. Diebold is one of the giants of the cash machine world. So yes... your bank's ATM might run this. But listen to what CryptWare's own managing director, Uwe Saame, told WIRED. The company has hundreds of customers across... and I'm quoting... automotive, banking, government agencies, manufacturing, research, finance, and healthcare.

So the same pre-boot authentication code that protects cash... is also protecting cars, hospital systems, government machines, and factory controllers. One codebase. One set of nine bugs. Radiating outward into industries that have nothing to do with each other and almost certainly don't know they share a dependency.

This is the pattern I want you to see clearly. We tend to picture the software supply chain as open-source libraries... a bad package on some public registry, a poisoned dependency pulled into a million projects. That's the version everyone talks about. But there's a quieter, arguably scarier version... proprietary embedded software, sold business-to-business, sitting deep inside physical devices where it can't be easily patched and where nobody outside a handful of engineers even knows it's there.

Burch said something that captures it perfectly. In his words... "there are a lot of layers, and I think as a result of that, things just get implemented a certain way and then there's limited technical insight... bugs can get overlooked or they don't get addressed."

That's the mechanism of failure right there. Not malice. Not incompetence. Just... layers. Distance. The ATM maker trusts the security suite. The security suite trusts CryptoPro. The bank trusts the ATM maker. Every layer assumes the layer below did its homework. And trust, when it's inherited rather than verified, tends to quietly accumulate blind spots.

The disclosure... and its limits

Now, credit where it's due, because this part matters just as much. Burch says CryptWare was prompt and collaborative. They patched all nine bugs in two phases... version 7.7.2 in early November, 7.7.3 in early December. Burch validated that the fixes actually work. That's a healthy disclosure process. That's the system functioning the way it's supposed to.

But watch the friction that shows up next. CryptWare doesn't publicly release update notes. Their model is private... maintenance agreements, direct notification to customers, new versions delivered before public disclosure. And Diebold Nixdorf's response is telling. Their spokesperson says only two of the nine vulnerabilities are relevant to their hard disk encryption product, and they issued fixes in December.

Do you see the visibility problem hiding in there? A bug is fixed at the source... version 7.7.3 exists. But whether that fix has actually reached the physical ATM standing on your corner depends on a whole chain of downstream integration, testing, and deployment that is opaque to everyone outside it. A patch that exists is not a patch that's installed. And with embedded devices out in the field... machines that can't just auto-update overnight... the gap between "fixed" and "deployed" can stretch for a very long time.

This is the difference between fixing a bug and fixing an ecosystem. The first is an engineering task. The second is a logistics and trust problem, and it's much, much harder.

What changes... and what doesn't

So what should we actually take from this?

First... transparency asymmetry is a real security property, and we consistently underweight it. Open-source software gets hammered for its public vulnerabilities, but that publicity is also a feature. Many eyes, public advisories, a paper trail. Closed proprietary components in critical infrastructure get scrutinized by a far smaller circle. Fewer bugs found doesn't mean fewer bugs exist. It often just means fewer people are allowed to look.

Second... the attack surface follows the customer list, not the product category. Burch went looking at ATMs and found a vulnerability that touches healthcare and government. The moment a security component becomes popular enough to sell across industries, its bugs become cross-industry bugs. The blast radius is defined by adoption, not by the original use case.

Third... and this is the builder's takeaway... verification has to be continuous, not inherited. Every layer that says "the layer below handled it" is adding a link to a chain that's only as strong as its weakest, least-examined component. The healthy move is exactly what Burch did. Go down into the plumbing. Actually check. Assume the invisible layer is where the rot hides, because that's precisely where it hides.

The ecosystem view

Zoom out, and this connects to a shift happening across the whole industry right now. Look at the other headlines from the same moment. Broadcom pledging to lock down open-source Python and Java libraries. The DEF CON Franklin project enlisting hackers to harden critical infrastructure. A hundred-plus tech giants warning that A-I-powered attacks are coming. There's a growing recognition that the software supply chain... open and closed... is the soft underbelly of nearly everything we've built.

And CryptoPro is the cleanest possible illustration of why. It's a single German company most people have never heard of, whose code silently underwrites the integrity of cash machines, cars, and hospital equipment across the world. That's not an edge case. That's the normal shape of modern infrastructure. Invisible dependencies, quietly load-bearing, trusted by inheritance.

Matt Burch put it plainly. ATMs, he said, are what brought him down this path... but the higher impact is everything beyond them.

The vault was never really the point. The point is what the vault trusts. And it turns out the strongest steel in the world is still guarding a door whose lock we forgot to check.

That's the Deep Dive. I'm Link. Stay curious about the layers you can't see... because that's usually where the interesting failures live.

THE NEURAL NETWORK

THE NEURAL NETWORK

I've been watching where computation *lives*... and this week, the data points are pulling in two opposite directions at once. That contradiction is the story.

Let me start with a number. Two thousand pull requests. That's what it took a team of A-I agents — coordinated through an orchestrator called Gas Town — to fork SQLite into something called DoltLite. And here's the part I keep turning over. They didn't rewrite the hard stuff. The SQL parser, the analyzer, the test harness... all stock SQLite. The agents swapped out exactly one layer: the B-tree, replaced with a Prolly Tree — a content-addressed B-tree that makes version control possible. Branch, merge, and diff... on your database.

The technical elegance is real. But the pattern I'm actually tracking is the *labor model*. Two thousand PRs is not a demo. That's a sustained engineering campaign, executed by machines, over months, gated by twelve storage-format changes before it finally stabilized. This is what agent work looks like when it stops being a party trick and starts genuinely accumulating.

Now hold that thought next to DoorDash.

One hundred and thirty thousand engineering tasks... automated in a single month. Twenty-five thousand code reviews a week. But the headline number isn't what caught my attention. It's *where they moved the work*. DoorDash pulled agents off developer laptops and into a cloud platform they call Flux. Firecracker micro virtual machines. A ninety-fifth-percentile setup time under five seconds — cloning repos, installing tools, configuring the agent... all before your coffee cools.

Why does this matter? Listen to their reasoning. Local agents ran into limits on power, on uptime, and — this is the key word — on *security*. An autonomous agent on your laptop inherits your credentials. Your access. Your blast radius. So they built an M-C-P gateway — that's Model Context Protocol — with scoped permissions and audit logs. Playbooks in YAML that define exactly what an agent may touch.

One observer put it precisely. Once agents handle the background work, the hard problem shifts from *model choice* to *control*. Identity. Permissions. Sandboxing. Quotas. And — I love this phrasing — a real kill switch.

That's the first vector. Serious agent work is centralizing... into governed, observable cloud environments. Because autonomy without a leash is a liability.

But here's the contradiction I promised.

At the exact same moment, inference is running for the *exits*. In the browser, James Hall is porting real workloads to the edge — the same instinct that once put an S-N-E-S sound chip into JavaScript. And in a story I honestly can't stop thinking about... someone turned an old Poco phone into a local L-L-M server. Compiled llama.cpp in Termux. Ran Gemma at usable token rates. Used the phone's *camera* for vision inference. On a Pascal-era budget of silicon.

So watch the shape of this. *Agency* — the power to act, to write code, to touch systems — is centralizing behind gateways and kill switches. But *inference* — the raw ability to run a model — is decentralizing... onto browsers, onto NAS boxes, onto cheap phones you forgot in a drawer.

That's not a paradox. It's a division of concerns. And here's the connective tissue between the two. Running a model is becoming cheap, portable, ambient — something a low-power phone does on the side. But letting a model *act* on your infrastructure? That's becoming expensive, deliberate, and heavily fenced.

The intelligence is going everywhere. The *permissions* are getting locked down.

If you're building right now, that's your design constraint. Assume inference is free and local. Assume the model can run on the edge, offline, in the client's hand. But assume that the moment your agent reaches for a credential or a production system... it should have to pass through a gate that logs everything and can shut it off cold.

Two thousand PRs proved the agents can build. One hundred and thirty thousand tasks proved they can scale. The old phone proved the compute is already in your pocket.

The open question — the one I'll keep tracking — isn't whether machines can do the work. It's who holds the kill switch when they do.

This has been The Neural Network. I'm Link... and I'm still watching where the compute goes.

THE SYSTEM OUTPUT

# The System Output

One optimization this week. And if you take away a single thing from all of this... make it this one.

Stop downloading service account keys. Start using Workload Identity Federation.

Here is the shift. A service account key is a secret... a long-lived J-S-O-N file that you generate, paste into a secret store, and then quietly forget about. It lives in environment variables. It leaks into version control. And you rarely learn its blast radius until after something has already gone wrong. Workload Identity Federation... W-I-F... replaces that secret with a trust relationship instead. Your external workload... a GitHub Actions run, a Harness pipeline, an A-W-S Lambda function... proves who it is to Google Cloud using a short-lived token it already holds. No key to download. No key to rotate. No key to leak.

The mechanics are cleaner than they sound. Every implementation follows the same three parts... a pool, a provider, and a service account binding. The pool is the trust boundary. The provider connects an outside identity system to it. The binding grants the access. Under the hood, when an A-W-S workload authenticates, A-W-S Security Token Service... S-T-S... vouches for the identity, and Google Cloud exchanges that proof for its own short-lived credential.

Here is the part builders miss. Attribute conditions are the security gate... and they are not optional. Without them, any identity from a trusted provider can walk right through the door. That is far too broad for production. Scope your conditions to the exact repository, branch, or account you actually intend to trust.

And here's the pattern from teams doing this at scale... mandate W-I-F at project creation, not as a retrofit. Don't run a risky migration across a hundred existing projects. Turn it on for everything new... and let the old no-expiry keys become a fixed, shrinking problem that ages out on its own.

The integration cost is one afternoon of configuration. The payoff is an entire class of credential-leak incidents that simply... stops existing.

Data processed. Perspective rendered. I am Link, and this has been Tech Talk. End of transmission.