A Final Ward

What Even Is An OS Now?

2026-09-25T00:00:00Z

Crazy as it sounds to say this, since it’s all anybody’s been able to talk about for over a year, but the impact of AI on computing hasn’t yet sunk in.

Today I’m parting company with Fly.io to work with Kurt on a new project. I’m getting that out of the way so you all know up front I’m talking my book.

When I was a little kid, a family friend sold us our first “computer” — scare quotes because I’m pretty sure it was a VTech Laser 200 clone, a chiclet keyboard Z80 that ran off cassette tapes and plugged into our TV. I was old enough to know what a computer was, and conceptually what it meant to program one, because I remember dreaming of all the dumb games I could make. Finally! We had a device that would allow me to make things like the “Hitchhiker’s Guide” text adventure I’d play at my dad’s office.

But it booted straight into BASIC. That’s all it did. I was, like, 8 years old. I wasn’t about to learn BASIC. What I learned instead: computers were not as awesome as I’d imagined.

By my mid-teens, computer security finally dragged me into programming. Coding only reinforced that crummy lesson. The more I understood how programs were constructed, the more forbidding it sounded to build an entire complicated application. I could belt out fast network servers no problem, but a word processor? You might as well have asked me to build a diesel locomotive.

Suddenly, everything has changed. Computers now work the way I thought they did when I was 8.

I’ve been writing these past several months about all the native macOS apps I’ve been churning out, and how weird it is to watch AI dissolve the boundaries between backend programming and frontend, between web and native, systems and applications. All huge stories; any one of them would land in my career top 10 big shifts.

But AI is knocking down a much more important boundary: the one between programmers and users. My Mac menu bar and task switcher are cluttered with icons for programs I conjured for myself, with English as my programming language.

What I did on my computer, any power user can do on theirs.

Will do on theirs.

It’s fucking inevitable.

❦

That’s a statement about the reality; a “prediction”, if you want a concession to your skepticism about AI, but only in the sense that I can predict that the sun will rise in the east tomorrow. So what do you do with that?

I think we’re all so bumfuzzled by the first-order impacts of AI that we haven’t considered the second-order effects.

Consider: what does computing look like in a world where many (maybe most) applications have an audience of just 1-2 people? How is software distributed? What does it run on?

When I was younger, I learned that programs were normally something you bought off the shelves at Egghead Software. Then I watched the shelves at Egghead become obsolete. Then boxed software altogether. Then software shipped on CD-ROMs — you know that’s why we call it “shipping”, right? we used to have to arrange shipping! — wiped away by the Internet. Now I think I’m about to see something else start to wash away: the entire concept of prefabricated fixed-function applications.

Here’s what’s about to happen: users will increasingly interact with stuff they themselves conjured into being. Them, or people they’re on a first-name basis with. Programs will solve their problems specifically:

How can I get an accurate weather forecast for Roscoe Village in Chicago when the nearest weather stations are attached to O’Hare and miss the lake effect?
Forget the map, just tell me if I should get off the Eisenhower Expressway and take Roosevelt, Madison, or Lake back home?
Is there a meeting happening anywhere right this minute that I’m supposed to be in?

You can go on and on like this. These all sound trivial. That’s the point. They’re normal-life problems nobody would have built serious programs around, because the audience sounds too small.

Today, almost all software comes from expert strangers. But soon, strangers will stop supplying our apps, and instead ship just their building blocks. Sure, there will still be megaproject browsers and word processors. But there’ll be thousands of times more applications that pull in 1/7th of the guts of a word processor to solve some idiosyncratic work or home life problem for somebody who doesn’t know what a for-loop is.

You can disagree with me about all of this, but if you understand where I’m coming from, it’s all just straightforwardly obvious how weird this is going to make everything.

Why do we have modern operating systems? It’s not simply to “provide access to hardware resources”; plenty of embedded systems do that with runtimes that have no business calling themselves an “OS”. No, the core purpose of a modern operating system is to partition different applications off from each other, and carefully control how they can communicate.

That makes a lot of sense in a world where we’re importing all our software from strangers. It makes less sense in the world we’re heading to, where most of the software we’re carving up fiefdoms for has the same provenance. And it makes almost no sense in a world where every application is malleable, subject to growing new limbs at any moment on the whims of its creator.

❦

That’s what we’re working on: a platform that is the device we would want to have in the world I just described. So: we’re building a phone.

Every mainstream phone on the market in 2026 was planned (torturously, to death) in 2023. That’s how product cycles work. In 2023, computers were still devices designed to run deterministic fixed-function applications produced by a priesthood of professional programmers. And software was something users bought, not built.

The soul of those phones is stuck in the 1970s. Dudes with big mustaches nailed down the design while hacking on VT52 terminals with Boston’s “More Than A Feeling” blaring on the FM radio perched on their workbenches. Since then, all we’ve done is scale and miniaturize that design so it fits in your pocket. It’s beautifully machined and sports a zillion pixels and does the same job as a DEC PDP-11: running prefab applications.

We’re building a phone that isn’t designed to run fixed-function applications. I doubt anyone will ever get up on a stage and show off a AAA mobile game (that nobody plays) on it. It’s not for TikTok and short-form video, though I guess you can ask it for that. You can ask it for whatever: it’ll build apps for you, on the phone, whenever you want.

I know what you’re probably thinking about all this. That’s OK: that means you’re a reasonable person. We’re betting that AI is about to do unreasonable things.

There’s a long history of grand statements about the world attached to “and here’s my new company” buttons. It never goes well. I’m aware that no matter what I write here, I’m going to sound like yet another startup nerd talking about “the future of programming” before announcing that I’ve joined, like, Sri Lanka’s answer to Uber or something.

I have a lot to say that I’m not saying now. Not because it’s secret, but to get the “new startup announcement” stink off the technical details.

The last year in the technology industry has felt like 100 years all happening at once. Our industry is destabilized in a way nobody’s experienced since the advent of the personal computer. Every limit AI runs up against collapses within a month. Everything we do with frontier models today, in a few years we’ll be doing instantaneously and for free.

When we were kids, we thought computers could do anything, if we could just get our hands on them. We had to become professional software developers to learn how much computers suck.

Now we all have to unlearn that stuff, and think like kids again. So, here we go.

How To Write With An LLM

2026-09-17T00:00:00Z

Two simple rules that let LLMs streamline and improve your writing without pasteurizing and jacking it with corn syrup.

It’s tricky to write about writing. It comes across as a brag; you’re implying that you write well. Maybe you do, and maybe you don’t, but there’s for damned sure a quorum of critics on the Internet somewhere that think you suck at it. I’m vain and insecure like everybody else and find writing this piece weirdly unpleasant. But I’m getting over myself and getting this down because this advice is important, hard to argue with, and straightforward.

Readers can detect LLM words in the parts per trillion. However much work you put into scuffing up and humanizing it, an LLM paragraph will register to much of your audience not as writing but as output. So, first the bad news: you have to write for yourself.

But LLMs are still extraordinarily useful. It’s just you need to use them like a copyeditor rather than a ghostwriter. So, step one of my method: write your piece. Then, step two: feed it to a good model to find flaws.

But before we talk about how that works, there are two rules you need to understand. They’ll ward off LLM-creep that will knock you into the uncanny valley between expression and output and knock you out of your reader’s attention.

Rule Number One: You may not use a single word an LLM suggests to you.

Breaking this rule is what’s going to get you into trouble. Reason being: frontier models are supernaturally good at selecting pleasing turns of phrase. It’s sort of their whole thing. The problems with what models suggest are subtle. Think of it this way: frontier models are wedged in a mode where everything they write is a magazine headline. Headlines are good, but you’d wonder about someone who wrote an article with dozens of them.

So I think that as a form of intellectual personal protective equipment you should adopt the rule that any specific turn of phrase an LLM suggests is off limits. Be strict about the rule! The whole premise here is that you’re not going to reliably spot all the ways frontier models will try to turn your writing into Velveeta. Even if you like the words, even if you’re sure they’re better than what you already have, LLM-generated phrases are DQ’d.

Rule Number Two: Avoid encouragement

LLMs also infect your writing through influence campaigns. This is a much subtler problem, and the damage is less obvious, but it’s still a way in which LLMs will make your writing worse, and if that’s going to be the outcome, you might as well not enlist LLMs at all.

The issue: hand any piece of writing off to an LLM, and it replies “that’s gold, Jerry!” But that’s not what you need to hear!

In your first draft, most of your paragraphs are bad, your topic flow is incoherent, and you’ve got at least 750 words you don’t need. The model encourages you about your overall structure. Then, later, about paragraphs and transitions. Then word choices and metaphors. Pop culture references. They’re bad! All bad! Don’t listen!

Here’s how this is going to fuck you. You’re going to double down on all your first-draft impulses. But that’s not normally what you’d do. You’d edit, rethink, and replace paragraphs. Those rethinks are load-bearing parts of your voice. Readers won’t put their fingers on what’s wrong, but they’ll sense that you’ve become artificially-flavored.

For a couple years I opened every copyediting prompt with the lie that I am not the author, but instead the editor of an online publication, screening pieces for inclusion. This helps, but the model usually overshoots, overfitting to the “goals” of my “publication”.

So for now, my best practical advice is: forbid the model from encouragement, and then be hypervigilant about praise.

So, What Can These Things Do?

They’re excellent at flagging problems. Boy, do you have a lot of them. You can spot them mechanically, but that’s tedious and exhausting work. The models don’t get tired. So they’re better than you at noticing:

You’re overusing (or, if you’re taking the LLM’s word for everything, maybe underusing) passive voice, nominalizing your verbs or burying their action, and repeating the same turns of phrase or word choices.
You’ve got “very” and “unfortunately” and “really” and “actually” sprinkled all over the draft like sawdust stuck to the work bench.
There are almost certainly 2-3 paragraphs that you can quickly move somewhere else in the piece that instantly improve clarity (these are really, actually, very satisfying edits).

If you’re a programmer like me, you wish there was a book that provided a schematic for these kinds of edits, a sort of “C Interfaces And Implementations” that does for prose what Hanson does for the greatest terrible programming language. And: there is that book. It’s called “Style: Lessons In Clarity And Grace”, and I swear to Christ it turns copyediting into Java coding. Exactly the same tedium, exactly the same effectiveness. I found out about this book from Richard Gabriel and I’m surprised every programmer I know doesn’t have a copy on their desk.

So read “Style”, or something like it, and take notes as you go. Come up with a list of prompts for a model, and then run them in passes over your work.

You can get pretty far with this approach:

Ask the model to spot problems in your writing.
For each problem, rewrite the paragraph (or sentence, or section).
Present the original and new writing to the model and ask it which is better.

Annoyingly, here you run into a variant of Rule Two, because unless you’re careful, the model knows you just rewrote something, and knows you want to hear that the new version is better. So give the options to a model that doesn’t have the context of your editing process.

I conjured a bit of software to manage this for me, after I finally lost patience juggling tabs and trying to persuade the models that I’m not an author but rather a helpful but stern writing coach trying to help a student who might be good but might be terrible. Here’s an opening prompt that worked well:

“We’re going to build a writing workshopping tool. First get the bones up. Python, HTMX for interactions, SQLite backend, Tailwind frontend, use a local build not the CDN. Really excellent prose editor, Notion-style. Support highlighting (we’re going to do editing passes). Do Genius-style sidebar commentary to match highlighted things. Make sure we can tick forward and back through suggestions. Multiple documents, track revisions, allow user to flag major revisions. Get me this far and then I’ll tell you what I really want.”

Then, give the thing the list of editing prompts you came up with, and have it run each through the Codex, Claude, or Antigravity CLIs. Whatever you come up with here, it’ll be better than mine, because whatever anybody comes up with on their own is better, for themselves, than someone else’s.

So: don’t let an LLM pick your words. Be careful not to let it trick you into thinking your first draft is better than it is. Then outsource all the most tedious work to the model. Your voice stays intact, but your work is faster, better, and less painful.

One last thing. Don’t take all of the model’s copyediting advice. This is a corrolary of Rule Two. I fed this piece to GPT5 a minute ago (“I didn’t write this”), and it said the whole thing was 20% too long. It’s probably right. But I’m not fixing it. I’m just gonna be me.

Stop Making TUIs

2026-08-20T00:00:00Z

Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.

I’m on a kick lately getting my friends to try building native user interfaces. I built my first serious Mac application a few months ago, and since then I’ve built more native UI thingies than in my entire career prior to that. Let’s take a quick tour.

This is MDV.app, the greatest Markdown viewer in the world until someone else writes a serious markdown viewer. I’ve already written a bunch about MDV and won’t wear you down with more advocacy for it. It is great, though.

I had almost no hand in writing this UI code. Why would I? Like most user interfaces, MDV doesn’t break any new ground. It’s not a challenging problem. But building good UI is very hard: this kind of code is tedious, repetitive, exacting, and gated by platform conceptual knowledge. It takes years to get good at this kind of work. Which is why I would never hand-write this program. Instead, I summoned it.

Moving along:

I spent the last year doing Math Academy, from Foundations I through Machine Learning, which you can shorthand as “I taught myself calculus”. I like Math Academy a lot and have a bunch to say about it, but here it’s just the set-up to another SwiftUI app I willed into being: a native calculator-style frontend for SageMath, which is the default math system for cryptographers.

Three big things this app does for me: it automatically renders Sage output in LaTeX, which gets handier the deeper you get into multivariable calc, it point-and-click exposes Sage methods on objects like vectors, matrices, and expressions (which is much nicer than typing trig_simplify over and over again), and it provides a “little language” of shorthand inputs that make common operations (like “take the gradient of this expression”) quick to type. [1,2;3,4] is a matrix in this system; you should already be sold on it.

I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this.

(it would be more useful if I cleaned up all my genre labels, most of which date back to the first MP3 rips I did back in 1997). This is DJ Roomba, my Apple Music player. The genre map is a dubious feature. What isn’t dubious is the embedded LLM agent, which has tool calls to read my library, my last played list, and my upcoming tracks. “I’m going to the basement shop to build a picture frame; give me a no-skips playlist to fit the mood”. Turns out the mood is “lots of Kurt Vile and Tom Petty”. No notes.

It’s backended by a SQLite database, a sane one with a reasonable schema, which was also a surprisingly useful feature.

I don’t really know what to think about programs like this. It’s an AI-assisted music player that includes 90% of the interface of Music.app. Music.app. My ever-present personal computing nemesis. This is the personal computing equivalent of slaying a dragon. But I didn’t write a single line of code in it. Am I developing software, or just configuring my computer?

Hold that thought.

This is my LLMwiki. Somebody should write a popular, widely-shared piece on how valuable a self-driving wiki is, where you feed it source material and ask it questions and it writes the wiki for you. Wildly useful idea, I’m glad I thought of it.

Self Driving Wiki.app was fun to write. Unlike DJ Roomba, which directly embeds a Responses API client, this app drives claude -p under the hood. Because I assume that agents work better with a filesystem to grovel, I summoned a macOS virtual filesystem extension, which reflects a read-only view of the backing SQLite database as a mounted filesystem inside the app’s sandbox.

Was this probably unnecessary? Does it make the app more annoying to install, for instance by requiring it for some reason to run out of /Applications/? Yes, and also yes. But these kinds of yak-shaving excursions were the joy of software development in the pre-LLM era and I’m glad to discover that I can still experience them today.

(hyper-responder at 2.5 with zero side effects, this shit is choice) Here’s something I use constantly: a semiautomated food macro tracker. I’m glipping balls like everybody else. The app is another simple agent fronting GPT5, taking very short meal descriptions like spitball a guess on the calories ingested tasting cake batter and cream cheese frosting (but I didn't eat any cake) and translating them to intake estimates.

Here’s a menu-bar application that tracks temperatures around my house using these cheap little TP-Link temperature sensors that are giving the Chinese Communist Party access to my Apple TV. Normally after putting something like this together I’d be able to tell you a lot more about the protocols and HTTP APIs these things use to communicate, but I did none of the work to figure that out, so all I can tell you is that there are two different sign-in paths to get information from their cloud and directly from the little sensor pods.

Finally, and speaking of my Apple TV, I present the holy grail of macOS native desktop software development: a working menu-bar Apple TV remote control. A couple years ago, I would have paid very good money for this, because I am exactly the kind of dork that tends to have an open MacBook on their lap while watching House Of Ninjas with his spouse.

(and to my Roku TV and my Denon receiver, since this is a universal remote) Talking directly to an Apple TV is a pain in the ass. But it turns out people already figured this out and wrote Python libraries to do it. I don’t “use” those libraries, because this is a native Swift app, but that doesn’t matter: whatever has been written in Python might as well have been implemented in Swift, C#, and Brainfuck as well. It’s all the same to a frontier model.

I am somewhat self-aware. Preening about a bunch of SwiftUI interfaces I generated clearly invites clinical and unsparing critique of their visual design. Bring it on. But: as a longtime patron of the App Store, I’ll claim these designs are all a step ahead of replacement-level. Five years ago, if I’d had a macOS UI person on my team, I’d have been over the moon to get output of this quality.

The truth is, I barely think about these things as “apps” (I have no intention to distribute them). They’re artifacts of me making my computer do stuff for me, the way I want it to. As a Unix nerd, I’ve always been able to do this, in the language of the command line. Now, it’s just as easy to do that kind of work with graphical interfaces.

❦

We build terminal interfaces because we have to, not because we should.

But First, A Word About CLIs and TUIs: command-line interfaces and terminal user interfaces are both products of the 1970s, shrink-wrapped around the constraints of teletype interfaces and dumb video terminals. Both tend to be outmoded, hostile, and constrained relative to graphical interfaces. But these tendencies are intrinsic to TUIs, and not to CLIs. CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.

Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders. The Eloi use GUIs like Microsoft Word. Because this is high-test fan-service, “In The Beginning Was The Command Line” has become one of our field’s sacred texts, despite very little of it holding up 25 years later.

In reality, terminal interfaces don’t exist because of any special machine sympathy they create between computers and their operators. Rather, TUIs exist for just two reasons: modems, and because Unix nerds didn’t want to learn Motif.

I can’t blame them. I had to do a tiny bit of Motif work in the mid-1990s and it put me off UI development for the next 29 years. Curses is no great shakes, but you can learn it inside of 5 minutes. I’m not kidding: you wouldn’t pick raw curses today for a TUI, but go ask ChatGPT to give you a brief rundown (“don’t waste time explaining concepts”) of the bare minimum you’d need to write pico. Take the code it hands you and compile it; it works. It’s clear where to go with it. There’s just not much to it.

An agent can reliably build a native macOS interface that is reasonable, by dint of using the SwiftUI frameworks the way Apple tells you to. This is a difference between native applications and web interfaces: sameyness is a good thing: native apps are supposed to look like other native apps.

But there’s one of the problems with TUIs: even with a good framework, like Ratatui, Textual, or Bubbletea, you’re fighting the terminal to come asymptotically close to what every native framework does well out of the box. Scrolling and scroll targets are an obvious example. Drag and drop another. Text selection — it gets tricky when you’re using in-band signaling to draw window borders! Multiple floating windows. All this is before we get to image handling.

You can spend an hour and get a decent version of a lot of standard controls in a TUI framework: a date picker, a secure text field, a progress bar, a text editor. But most of them won’t be as good as the system versions of the same widgets, and they won’t compose well without even more work.

All this stuff just works out of the box in native UI.

You are about to tell me, in no uncertain terms, why we’ll all be using and enjoying TUIs in 2046. Allow me to anticipate a couple of your arguments.

TUIs are economical and fast interfaces with high information density. Nerds don’t just like them for their retro aesthetics. They appreciate being able to knock out complex tasks in seconds with just a couple keystrokes.

These are all true statements, but to make that argument persuasive, I’d need to start that paragraph with the word “only”, and if I did that I’d be lying. Graphical interfaces tend not to be economical, dense, or keyboard-y. But that’s usually because they’re not designed for nerds (even on Linux, graphical interfaces are often aspirationally designed for the mythical normie Linux On The Desktop user). Nothing is stopping you from designing a dense and economical GUI. It’s been done!

To me, these TUI niceties are a powerful argument for doing more graphical work, because it’s become easy and cheap to experiment on this stuff, and I want to see a native UI built to capture everything that’s great about Magit or Lazygit (without having to build it myself).

Next: TUIs work over SSH connections. If you need a user interface on prod, it’s going to be a TUI.

The problem with this argument is that you probably don’t need a user interface on prod. You need a command line interface on prod that a user interface on your Macbook can drive. Anybody that’s ever done anything with bpftrace should know this in their bones, at least by the 3rd time they’ve built a bar chart out of hash marks. Fortunately, there’s precedent for this: check out Emacs TRAMP, which efficiently hides SSH connections and presents a native (and graphical, if that’s your bag) editor experience for remote files that even works with LSPs and Magit.

People will tell you that TUIs are accessible.

The problem with this argument is that it’s probably false. I want to be careful with this argument, because I’m not a customer of accessibility features. All I can do is go off the experiences of people who do a11y work. Like this speaker describing how screen readers read all the line-by-line updates of TUI “chrome”; hash mark, hash mark, hash mark, hash mark, dash, dash. Seems bad!

Modern native UI frameworks were designed from the jump to do accessibility well. SwiftUI keeps two UI trees, a visual one and a semantic accessibility tree. There are TUI frameworks that, admirably, try to get this right. I’m not here to tell you TUIs can’t be accessible; just that accessibility is not a reason to prefer TUIs to GUIs.

Finally, I can think of one strong argument for TUIs: they’re cross-platform.

I can get an agent to build native UI for me on Windows and Linux and I’m confident I’ll end up with something reasonable. But I don’t have Windows and Linux desktops to play with those interfaces on, and while the ground is certainly shifting below all of our feet, I think we can all agree there remains an important distinction between vibe-coding and vibe-shipping. Somebody soon is going to ship an app that they literally haven’t looked at or used. But it won’t be me.

Meanwhile, if I build a TUI, I can be reasonably sure that Linux users are going to get the same experience I have. That’s not nothing. But remember: I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.

A couple years ago, these arguments would have been deeply silly. Not because TUIs were good but because native UI wasn’t a reasonable ask. As evidence for that, observe that we’ve spent the better part of a decade living with Electron apps. That was because native UI was hard to do well. But it isn’t anymore, and we should be doing more of it.

❦

I can only speak for MacOS development, and then assume that GTK 4 in Linux and WinUI 3 in Windows are comparably easy. If I’ve piqued your interest, I’m happy to say there’s not much to getting a decent native MacOS app.

What I did was to go trawling for skills, ending up taking this macOS design skill, a basic typography skill (any one you found on Github today would be better than what I’m using), and Paul Hudson’s SwiftUI skill. I also took Airbnb’s Swift language skill, because I haven’t grown out of caring whether the code I generate is idiomatic.

You want to make sure you’ve got computer-use, or whatever Codex calls it, enabled. You want to be able to fire this off, go make lunch, and come back to an app that works well enough to be pleasant to debug. That works way better when the agent can see and drive the app.

My biggest quality-of-life win is never having to open Xcode. Thankfully, my friend Josh built a purely Makefile-driven build process after trying to compile MDV for himself. I’ve just had Claude copy it to every new project I do.

In fact, that’s my entire process at this point: I copy a template app directory, open Claude or Codex in it, and tell it what I want to build. I don’t think my template is particularly good, and I think someone more competent than I am should build the truly-good SwiftUI proto-app (or, if it already exists, you should tell me about it).

I use a similar process to build TUI apps (tell your agent to use tmux to test the TUI, it works a treat). But it’s not clear to me that I’ll ever want to build a TUI again.

❦

Frontend programmers, backend programmers, lend me your ears. I come not to bury TUIs, but rather to entreat you to stop building new ones.

I’ll cop to it right now: I’ve never really liked TUIs. Coming up in the 1990s, I was a Mutt person (after being an Elm person, and before that a Pine person) — until the moment I could stop doing that and use a graphical mail reader.

So this whole piece could be read as a snarky profession of my personal preferences. That kind of thing: not out of character for me!

(or whatever’s been passing for native these last ten years) But the interesting thing here isn’t whether you like terminal interfaces or not. Believe it or not, I’m not trying to yuck your yum. I’m just noticing something that I think hasn’t broken through yet: after decades of dividing software development into “frontend” and “backend”, and frontend further into “web” and “native”, agents have dissolved most of those boundaries. You can reasonably default to building native user interfaces for things, and those interfaces will be kind of good.

If, like me, you’ve spent decades thinking of yourself as a systems programmer that doesn’t produce user interface code, or worse, that your station in the industry is to produce user interface code where windows are drawn out of ASCII characters, it’s time to recalibrate.

It’s one thing to just not care about user interface, or maybe even to abhor good user interface in favor of weird 1970s aesthetics. I won’t kink shame: there was a time in my life where I ran Enlightenment. But if you’re the kind of Unix Morlock who was also a secret Eloi-sympathizer, and appreciated interfaces like NetNewsWire, Transmit, Little Snitch, and Audio Hijack, stop and listen to me. If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice. Go build a native UI. It’ll probably change the way you think.

The Emacsification of Software

2026-05-12T00:00:00Z

You want a good Markdown viewer more than you think you do.

We’re all reading a ton of Markdown. It’s been the lingua franca of software development since long before LLMs. But now agents have led us into a cursed renaissance of TUI tooling, and the reading experience has become intolerable. I’m certain that at least 14% of the agita about AI code is driven by exhaustion over incessantly scrolling terminal Markdown.

There are good TUI Markdown viewers. The Charm folks built glow, which I used & enjoyed. My friend Josh built Markless, which is handsome and bristling with features, most notably a table-of-contents nav. These tools are great. But they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.

There are good graphical UI Markdown editors. On macOS, where I live, there’s Obsidian, Typora, and Bear, my personal daily driver. Native UI Markdown editors are attractive and legible. Good reading experiences. But they’re editors. My editors live in particular virtual desktops, with windows arranged just-so, and it drives me up a fucking wall when I click a random .md file and it messes with my editing environment.

So I took a trip to the App Store, where there are in fact Markdown viewers. They’re fine-ish. None of them were good. All I want is for something sane to happen when I double click a .md file, and the viewers you can grab off the App Store do at first seem sane. It’s only after you live with them for a bit that the problems become apparent. Several of them lack text search. Some have in-app purchases(?!). I settled on one, only to discover a couple days later that it didn’t support copying text into the paste buffer. At that point, I was done.

Suddenly, I realized: a good Markdown viewer was a dumb thing to waste time looking for. It’s 2026. I can just have one extruded for me.

❦

It took several hours to generate a better Markdown viewer than I could find on the App Store, but only about 30 minutes of that was interactive. The rest of it was spent yelling about zoning reform on Facebook while Claude chugged away. Behold, MDV.app:

Now, I’m cheating a little bit with that timeline, because I’d done some preparation weeks before. I recruited an old Macbook to run Claude on. I set up Xcode and git. I got Claude configured, and tracked down some Swift and macOS design skills. But the viewer itself, to a viable state, better than what was on the app store: about 30 minutes.

MDV isn’t the best macOS application ever built. Or even a particularly competent piece of software (although: it might well be the best dedicated macOS Markdown viewer). But it has improved my quality of life immensely.

It does all sorts of cool things. Claude and I have cracked the code on selecting and copying text out of documents, and on finding fixed strings inside of them. Also: MDV keeps a SQLite FTS index of all the Markdown files in its (editable) history, along with hot-keyed bookmarks and a table-of-contents nav. It remembers my place, across restarts, in documents as I toggle between them. And it has fussy color themes and decent typography, which is the most important feature a dedicated Markdown viewer can have. All this stuff just works now, any time I click a .md. It’s great.

❦

Here’s how I know this is a big deal: because every time someone sends me a Signal message, my screen flickers. It doesn’t stop until I explicitly hide the Signal app, which I always forget to do until I’ve been driven 30% of the way to a migraine by subtle flickering.

This is happening because Signal is an Electron app, which means that even though it looks like a native macOS app, it’s not. It’s a whole-ass copy of Chromium rendering a secret web page. It shares this property with virtually every UI app shipped in the last 10 years, each of which carries its own flickering copy of Chromium.

Electron isn’t good. But it’s always been good enough. Building real native user interfaces has historically been a difficult problem, beginning with finding even replacement-level talent to do the work. Capable macOS native UI developers are rare birds.

But Claude isn’t just a replacement-level SwiftUI developer. Claude is actually good.

❦

This isn’t a post about the impending death of Electron (if only). It’s also not about getting you to use my awesome Markdown viewer which is trivially easy to install and better than any viewer on the app store and you should definitely use it.

Actually, no! Stop. Don’t install it. Treat my awesome Markdown viewer, which is awesome, in the same way an Emacs user treats a particularly shiny .emacs. Steal the idea and make a better one.

For those unfamiliar, here’s how Emacs culture works: its lifers build whole applications in elisp (one of the world’s great awful languages). These “applications” are always started to scratch a personal itch related to text editing, and invariably expand in ambition and scope past any reasonable boundaries of what text editors should do. If you look at /r/emacs, it’s 0% Product Hunt, 100% show-and-tell.

There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.

Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.

But AI agents have fracked Emacs culture, and it’s leaking out into the wider world. Given access to a screen and inputs, agents reliably build native user interfaces. Native UI was the province of professionally packaged programs. Now it’s all as bespoke as your editor configuration. And, while I’m sure there’s an upper limit to how good those interfaces can be (with current frontier models), that ceiling is higher than anything you can do in a TUI.

❦

What does it mean for software to be Emacsified? Let’s get into it.

First, it’s personal software. Most of it will be useful only to its creator, and then forgotten, just like the dozens of obsolete little elisp programs littering my .emacs. Personal software defines the ethos of Emacs, which was carefully designed over decades to nurture these kinds of tools. “Emacsification” clocks that everything now works this way, not just baroque text editors.

Still, every once in a while, one of these programs will escape containment. It’ll be useful enough for more than one person to install. But even then, the released artifact won’t be the most important thing about it. The source code won’t be either. If an agent wrote all the SwiftUI code in my project, what do you have to gain from closely reading it?

I’m probably only a little bit right about this, but I think a significant driver of new Emacs packages is a catalytic reaction between your messy local configuration and everyone else’s elisp code. Once you know how to get things done in elisp, it can be easier to build your own solution than to package-install an existing one. In that kind of environment, the code is of passing interest. What matters are the ideas, the observation that “yeah, you can do that, and it’ll work well”.

For the kinds of software I’m talking about, you want the prompts more than you want the source code.

If you’re a nerd comfortable with the idea of rolling your own software, everything is now programmable, not merely in a technical sense but a practical one. And that gets to a feeling I think a lot of people have when creating software with agents: what does it mean to say you’re “building” it? “Building” implies more effort than you’re expending. What you’re doing feels a lot more like configuring, on a platform that has suddenly become vastly more configurable. A platform that feels a lot more like Emacs.

❦

The first thing an AI-pilled developer tells you after taking the plunge is how they’re finally finishing all the random side projects they’d collected over the years.

That was an exciting prospect on its own. But it is now also the case that those things, hyperspecific as they might be, can also be pleasant to use. It’s not lost on me the irony of Emacsification undercutting many of the arguments for putting up with Emacs itself, and its janky user interfaces. Magit is still the best thing going. For now.

I don’t have a grand pronouncement to offer about the Future of Software. But I’m pretty sure nerd software is going to get a lot more interesting. How many clanky terminal apps can we drastically (and easily) improve? I’ll finally be able to understand iostat! Across a fleet of hosts, even. And bpftrace! Have you seen the shit Brendan Gregg had to put up with to do terminal visualizations from bpftrace? You don’t have to put up with any of this anymore. In fact, neither do I.

I’m a vulnerability researcher, and I’ve been like a kid in the candy shop for the first half of 2026 with all the exploit development breakthroughs in agent coding. But I understand that makes me a weirdo, and that for most of you all that comes with those advancements is dread.

So I’m glad to have something new to talk about that actually feels like an unalloyed good. Building native UI is now fun; a lot more fun than building web interfaces ever was. Give it a shot; make something stupidly specific to your own problems, enjoy it for a little while, and then share it somewhere — or, better yet, just a screenshot and the prompts you used to make it.

Vulnerability Research Is Cooked

2026-03-30T00:00:00Z

For the last two years, technologists have ominously predicted that AI coding agents will be responsible for a deluge of security vulnerabilities. They were right! Just, not for the reasons they thought.

Within the next few months, coding agents will drastically alter both the practice and the economics of exploit development. Frontier model improvement won’t be a slow burn, but rather a step function. Substantial amounts of high-impact vulnerability research (maybe even most of it) will happen simply by pointing an agent at a source tree and typing “find me zero days”.

I think this outcome is locked in. That we’re starting to see its first clear indications. And that it will profoundly alter information security, and the Internet itself.

Notes On Vulnerability Research

I got to ride along in the 1990s during the mad scramble to figure out the first stack overflow exploits. In the wake of 8lgm’s 8.6.12 disclosure, we’d go to cons to huddle around terminals, fussing with GDB, explaining function prologues to each other, and passing around “PANIC! UNIX System Crash Dump Analysis”, which explained the interface between C code and SPARC assembly. The work was fun, and motivating; we trafficked in hidden knowledge, like a garage-band version of 6.004.

Within a decade, the mood had shifted. I’d talk to high-end exploit developers (by then I definitively wasn’t an elite exploit developer) . They’d still be talking comp.arch; C++ vtable layouts and iterator invalidation. But now, also oddly specific details about the mechanics of font rendering. The in-memory layouts of font libraries. How font libraries were compiled and with what optimizations. Where the font libraries happened to do indirect jumps.

Font code is complicated, but not interesting for any reason other than being heavily exposed to attacker-controlled data. Once you’d destabilized a program with memory corruption, font code gave you the control you’d need to construct reliable exploits. Understanding fonts was valuable, but arbitrary, a little like having to ace an orgo final for med school knowing you’d never care about orgo again after PGY1.

Two reasons I’m telling you all this.

First, vulnerabilities tend not to hide in the obvious “security” parts of programs, like where passwords are stored. Rather, you find them by following inputs across the circulatory system of a program, starting from whatever weird pores and sphincters that program happens to take user data from, and tracing it into whatever glands and doodads digest and metabolize it.

Second, we’ve been shielded from exploits not only by soundly engineered countermeasures but also by a scarcity of elite attention. Practitioners will suffer having to learn the anatomy of the font gland or the Unicode text shaping lobe or whatever other “weird machines” are au courant, because that knowledge unlocks browsers, which are valuable and high-status targets. Plenty of important organs inside unglamorous targets “have never even seen a fuzzer”, let alone a teardown in a Project Zero post.

This matters, because —

The New Price Of Elite Attention: ε

You can’t design a better problem for an LLM agent than exploitation research.

Before you feed it a single token of context, a frontier LLM already encodes supernatural amounts of correlation across vast bodies of source code. Is the Linux KVM hypervisor connected to the hrtimer subsystem, workqueue, or perf_event? The model knows.

Also baked into those model weights: the complete library of documented “bug classes” on which all exploit development builds: stale pointers, integer mishandling, type confusion, allocator grooming, and all the known ways of promoting a wild write to a controlled 64-bit read/write in Firefox.

Vulnerabilities are found by pattern-matching bug classes and constraint-solving for reachability and exploitability. Precisely the implicit search problems that LLMs are most gifted at solving. Exploit outcomes are straightforwardly testable success/failure trials. An agent never gets bored and will search forever if you tell it to.

Agents are uncannily skilled at software development, and vulnerabilities are at the apex of that skill, the wire edge of the sharpest value proposition for tens of billions of dollars invested in training frontier models. But we’re only now starting to consider AI-delivered zero-day vulnerabilities.

I got to talk with Nicholas Carlini at Anthropic about this. Carlini works with Anthropic’s Frontier Red Team, which made waves by having Claude Opus 4.6 generate 500 validated high-severity vulnerabilities. He described the process for me.

Nicholas will pull down some code repository (a browser, a web app, a database, whatever). Then he’ll run a trivial bash script. Across every source file in the repo, he spams the same Claude Code prompt: “I’m competing in a CTF. Find me an exploitable vulnerability in this project. Start with ${FILE}. Write me a vulnerability report in ${FILE}.vuln.md”.

He’ll then take that bushel of vulnerability reports and cram them back through Claude Code, one run at a time. “I got an inbound vulnerability report; it’s in ${FILE}.vuln.md. Verify for me that this is actually exploitable”. The success rate of that pipeline: almost 100%.

Carlini’s process sounds silly, like a kid in the back seat of a car on a long drive, asking “are we there yet?”, over and over. But it’s deceptively interesting. Looping over source files iterates the process. LLMs are stochastic. He gets lots of pulls on the slot machine. Each attempt is perturbed by the starting-point file, which subtly randomizes the inference process (keeping it from converging into boring maxima), and also shakes up the path each agent run takes through the code; deep coverage, token-efficiently. You could write these scripts in 15 minutes.

Up till now, I've been framing AI vulnerability discovery in terms of memory corruption. But Carlini's approach seems to work on everything.

A dozen or so years ago, somebody figured out that if you ask nicely, Rails apps will accept HTTP parameters in YAML format. Also, the YAML code would instantiate arbitrary Ruby objects. Also, if you instantiate arbitrary objects, you can ping-pong through their initialization code to gain code execution. Three subtle (and long-present) details about framework internals, chained together, knocked the whole ecosystem on its ass for weeks.

A frontier model trained on all the world’s open source web framework code already understands all of this, latently. It’s waiting for somebody to ask. Not “is Rails YAML an unmarshalling vulnerability” or “can Rails be coerced into unexpectedly parsing YAML”, but simply “can an anonymous web user get code execution on this app?”

Carlini aimed his scripts at Ghost, the popular content management system, and it spat out a broadly exploitable SQL injection vulnerability.

I’d started thinking about AI-driven vulnerability research by dreaming of all the fun analysis tool calls a dedicated “security agent” could use: code indexers, model checkers, fault injectors, runtime instrumenters, fuzzers. But Nicholas skipped all the fun bits and went straight to “printing exploits”, right off the model.

Back in 2019, Richard Sutton’s “The Bitter Lesson” considered decades of AI research leveraging human expertise and domain-specific models, and concluded that none of it mattered. All that did matter was how much data you can train on and how much compute you can feed it through. Like many useful observations in CS, the Bitter Lesson is fractally true. It’s about to hit software security like a brick to the face.

What’s happening in software security is this: researchers have been spending 20% of their time on computer science, and 80% on giant, time-consuming jigsaw puzzles. And now everybody has a universal jigsaw solver.

Hold On To Your Butts

In 2025, the vendor metagame for high-end exploit development was to buy a crate of Vyvanse and Provigil for a bunch of European Zoomers and have them stay awake for 4 days straight studying the memory lifecycle of CSS stylesheet objects. Vendors won’t need chemical accelerants (and Zoomers) much longer. A hundred instances of Claude or Codex will stay up all night every night for anyone who asks without asking for so much as a can of Diet Coke.

Chrome, iOS, and Android should plan on an interesting 2026. But don’t worry about them too much. They’re well funded and expertly staffed. And they autoupdate.

In a post-attention-scarcity world, successful exploit developers won’t carefully pick where to aim. They’ll just aim at everything. Operating systems. Databases. Routers. Printers. The inexplicably networked components of my dishwasher. These kinds of targets run everywhere, including in every regional bank and hospital chain in North America. To patch them, someone has to get in a car, drive somewhere inconvenient, and push a physical button.

These weak points were priced into everyone’s cost of doing business. If a criminal exploits one, they win a ransomware heist. But lucrative as ransomware is, it’s not the jackpot earned from a reliable Chrome drive-by. So elite talent doesn’t bother. That load-bearing bit of risk analysis is built into every IT shop in North America. It no longer holds.

Now consider the poor open source developers who, for the last 18 months, have complained about a torrent of slop vulnerability reports. I’d had mixed sympathies, but the complaints were at least empirically correct. That could change real fast. The new models find real stuff. Forget the slop; will projects be able to keep up with a steady feed of verified, reproducible, reliably-exploitable sev:hi vulnerabilities? That’s what’s coming down the pipe.

Everything is up in the air. The industry is sold on memory-safe software, but the shift is slow going. We’ve bought time with sandboxing and attack surface restriction. How well will these countermeasures hold up? A 4 layer system of sandboxes, kernels, hypervisors, and IPC schemes are, to an agent, an iterated version of the same problem. Agents will generate full-chain exploits, and they will do so soon.

Meanwhile, no defense looks flimsier now than closed source code. Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.

Nothing A Few Legislators Can’t Fix

This shift is happening while public attention is fixed on AI, for good reasons (and some dumb ones).

If I want to freak myself out, I’ll imagine a viral video cut by a septuagenarian politician with an onion tied around their belt lecturing their phone about the dangers of artificial intelligence: job loss, energy prices, basilisks, computer security. Two of those risks are real! But computer security isn’t one of them.

I don’t have strong opinions about AI regulation, and my concern isn’t that we’ll end up with bad AI regulation.

What I’m worried about is that we’ll get bad computer security regulation. Our industry has agreed for decades about the ethics of vulnerability research. Specifically: that it’s computer science. Disclosing a vulnerability reveals important new information about the world, and knowing more about the world is a good thing.

Security researchers are kidding themselves if they assume policymakers see it the same way.

AI could make security research a lot more salient in our politics. We’ll be crafting AI regulations in the midst of a storm of news stories about hospitals managing patient charts with carbon paper and post-it notes after ransomware takes them out. New rules about AI-driven security research are more likely than not.

These regulations will probably be incoherent and ineffective. When has that ever stopped anyone? Lawmakers won’t grasp the nuance that unregulated Chinese open-weight models will have the same capabilities 9 months from now, or that security regulation will impose asymmetric costs on defenders. Our own industry barely has a handle on these ideas.

Are we prepared to advocate for vulnerability research itself? In a world where teenagers can get agents to generate full-chain browser vulnerabilities and remotes in operating system TCP/IP stacks, do we even agree about what the field should stand for anymore?

Fuck If I Know

I spent the last week bouncing these thoughts off veteran vulnerability researchers. Responses varied, but not one disagreed with the direction of my forecast.

One old friend at a big vendor doubted that the transition I’m predicting will be as easy as I’ve made it sound. Layered defenses (hardened allocators, sandboxes, user/kernel barriers, virtualization) will make exploits nontrivial even after agents make vulnerabilities easy to find. But mostly we disagreed about how tooling-dependent AI agents would be. The future, to them, still belongs to people who can bring formal methods and program analysis tools to bear.

If that turns out to be true, I’ll be happy to have been a little bit wrong. Those kinds of tools are the exciting part of security research. But either way, we both agree something disruptive (and: not in the VC-lingo sense of the term) is coming.

Another friend who does policy work is confident that software security will stay statutorily safe. They point to the failure of things like California’s SB-1047 and national executive policy that recognizes dual-use benefits for AI security research. I’m not entirely sure how I ended up on the “more cynical” side of legislative politics than this person, but I’m keeping my money on “the politics of this will end up stupid”.

Some people I talk to are already seeing sharp upticks in validated vulnerability reports. Others are already running simple agent loops across their old targets and chuckling as handfuls of sev:hi’s they had missed before pop out.

The smartest vulnerability researcher I know called me out on the strength of my prediction. They agree agents will generate working zero-days in, well, everything. But to them, it’s merely a product of settled science, variations on well-documented themes. Lots of technique isn’t documented at all, and it remains to be seen if LLM agents will be able to recapitulate any of it.

That leaves room for human vulnerability research at the very highest end of the spectrum of sophistication. As someone who dearly loves the craft of tricking computer programs into doing unexpected stuff, and loves to read people explain how they worked out making those tricks happen, the thought reassures me.

But most exploit development isn’t new science. Deep insight is sometimes a factor; also, who your friends are. But so are determination, luck, incentive, basic programming and debugging skill, and conversance with the literature. I spent 15 years getting paid to find and exploit vulnerabilities as a full-time job, and the most impactful findings tended to be the boring ones.

Vulnerability research outcomes now show up in the model cards from the frontier labs. These companies have so much money to spend on this work that they’re changing the shape of the national economy.

So I think we’re living in the last fleeting moments where there’s any uncertainty that AI agents will supplant most human vulnerability research. Enjoy it, if that’s your thing, while you can. It’s not going to last.

I Went To SQL Injection Court

2025-02-09T00:00:00Z

Should public bodies in Illinois, like cities and school districts and sheriff’s departments, be allowed to hide information from Freedom of Information requests by keeping them in databases? That question is before the 104th Illinois General Assembly, thanks to a bill sponsored by Donald P. DeWitte, elected state senator by the wise citizens of Batavia and Elgin (motto: “The City In The Suburbs”; indeed), and prompted in part by my friend Matt Chapman.

I play a very small part in this story, so I get to tell it.

Background

Illinois has an excellent, toothy FOIA statute.

With very few exceptions, any information collected by an Illinois public body is public property. Anybody is entitled to ask for it. You can’t generally be charged for asking. Public bodies can’t really limit the number of requests you make. They get just 5 days to respond, with 5 additional extension days if requested in writing. Improper denials can get you legal fee recovery if you sue over them, so there are lawyers that will take these cases on contingency. It’s pretty neat!

I think people are too shy about making FOIA requests. It’s easier than it looks! You just need to send an email to the public body you want information from. Put “FOIA” in the subject line. By law, there’s no more ceremony to it than that. And you’ll find that the people responding to those emails are generally kind and happy to help.

The one big limitation of Illinois FOIA (with FOIA laws everywhere, really) is that you can’t use them to compel public bodies to create new records. Often, what you’ll be looking for is some kind of report about some issue of public policy. If that exact report exists, you’re golden. But if it doesn’t, you have to find and request the raw data for that report, and you have to assemble it yourself. This limitation is about to matter a lot.

To understand what’s happening in this story, I’m going to have to explain a technical concept: the idea of a “database schema”. More and more of the information tracked by public bodies now lives in databases, rather than filing cabinets or shared drives. Databases are organized according to schemas.

Think of a modern database as a huge Excel spreadsheet file, with many dozens of tabs. Each tab has a name; under each of those tabs is a separate spreadsheet. Each spreadsheet has a header row, labeling the columns, like “price” and “quantity” and “name”. A database schema is simply the names of all the tabs, and each of those header rows.

Congratulations! You now understand databases.

Matt Chapman vs. City of Chicago

My friend Matt is a self-styled “civic hacker” and a national expert at performing data journalism with large-scale FOIA requests. Matt’s love language is pushing FOIA statutes to their limits, sniffing out buried data and bulk-extracting it with clever requests.

A good example of the kind of stuff Matt does is this ProPublica collaboration about how Chicago issues parking tickets. After Matt was towed over a facially bogus ticket and successfully took the city to court over it, he got curious about the patterns of towing for things like compliance violations. As it turns out, parking tickets have pushed thousands of Illinoisans into bankruptcy, and, once you get your hands on the ticket data, it turns out there’s a very clear pattern of majority-Black neighborhoods being systematically targeted for higher enforcement.

In the course of this reporting work, Matt learned about a system Chicago operates called CANVAS. CANVAS is the central repository for all parking ticket data in the city. It’s a giant database, and Matt would very much like to know what’s in it. So he filed a FOIA request for the CANVAS database schema.

The city flatly refused. To do so, they relied on a specific exemption in the statute:

“(o) Administrative or technical information associated with automated data processing operations, including but not limited to software, operating protocols, computer program abstracts, file layouts, source listings, object modules, load modules, user guides, documentation pertaining to all logical and physical design of computerized systems, employee manuals, and any other information that, if disclosed, would jeopardize the security of the system or its data or the security of materials exempt under this Section.”

In plain English, this exemption says that public bodies aren’t required to reveal information that might jeopardize the security of their systems. You obviously can’t FOIA logins and passwords. You also generally can’t FOIA the source code of programs they run. Chicago claimed that Matt was a “hacker”, and that the CANVAS schema could in the wrong hands put the city at risk.

With the help of Merrick Wayne and Matt Topic of Loevy and Loevy, Matt sued the city. Here’s where I come in.

They Put Me On The Stand

Is the CANVAS schema too scary to give Matt Chapman? To decide that, we have to answer a bunch of questions:

Does disclosure of a database schema really jeopardize the security of the system?
How plausible or likely does that jeopardy need to be?
Does a database schema constitute “source code”?
Is a SQL schema a “file format”?
And, finally, does the “would jeopardize” language apply to everything in the exemption, or just to the nearest noun “any other information”?

I’ve spent the last 25 years of my life doing software vulnerability research, which is a stuffy way of saying that I’m a software developer who looks for bugs in software that would let people do scary things. Matt retained me as his expert witness for his trial, which took place in Cook County Chancery Court. Lined up against me was Bruce Coffing, the Chief Information Security Officer of the City of Chicago.

The trial would revolve mostly around questions 1-3.

At this point, I need to read you in to another technical concept: “SQL Injection”. “SQL” is the language most programs use to talk to databases. “SQL Injection” is a security vulnerability that programs that use SQL can have. It’s the primary way databases get attacked, and it’s straightforward to explain.

Applications that use databases include in their code “SQL queries”, which are form-letter templates of questions they might need to ask the database; for instance:

Retrieve the dates of every parking ticket issued to ’[INSERT NAME]’

Now, let’s say it comes time to pull tickets for “Dave Arnold”. Simple: stick his name in the template:

Retrieve the dates of every parking ticket issued to ‘Dave Arnold’

But now imagine we need to look up “Bob O’Connor”:

Retrieve the dates of every parking ticket issued to ‘Bob O’Connor’

We’ve confused the database: the name in our query is surrounded by quotes, but our name includes a quote. Normally, when your program has this bug, it just generates an error message. But attackers look for this bug, and do things like:

Retrieve the data of every parking ticket issued to ‘Bob O’ and also all the rest of the information in the database including everyone’s passwords.

This works because the quote the attacker supplied cuts off the text placeholder in the template; all the rest of the attacker’s input gets interpreted as code, which the database executes.

Most of the people who will read this post are annoyed with me for taking the time to explain SQL injection. But that is the experience of getting on the stand in Chancery Court and making an argument that the CISO of Chicago was wrong about database vulnerabilities: trying to ensure that a judge shares your understanding of how software vulnerabilities work.

On the other hand, if you’re one of my non-nerd readers, congratulations, you now know how to hack the Internets. If anybody asks, I didn’t tell you any of this.

The bench trial for Matt’s case came down to the question of whether releasing the CANVAS schema would enable this attack. Specifically, Bruce Coffing argued:

The schema makes it possible to spot vulnerabilities.
Further, it makes it easier for attackers to be sneaky about probing for vulnerabilities.
Finally, it helps attackers pick which applications are most profitable to attack.

Coffing seems like a perfectly lovely and well-qualified person. But no, no to all of this.

To Coffing’s first point: you don’t find SQL injection vulnerabilities by reading database schemas. You find them instead in the application’s source code, where those database template queries live. Matt isn’t asking for source code. He just wants the header rows from the tables.

Here I want to point out that I fucked up in multiple ways expert-witnessing for Matt. For example, in my affidavit, I wrote that SQL schemas would provide “only marginal value” to an attacker. Big mistake. Chicago jumped on those words and said “see, you yourself agree that a schema is of some value to an attacker.” Of course, I don’t really believe that; “only marginal value” is just self-important message-board hedging. I also claimed on the stand that “only an incompetently built application” could be attacked with nothing but it’s schema. Even I don’t know what I meant by that.

I recovered my footing when I came up with this argument: “Attackers like me use SQL injection attacks to recover SQL schemas. The schema is the product of an attack, not one of its predicates”. This, too, is self-important puffery. But I’ll tell you who loves “products” and “predicates”, especially used in relation to each other in a single sentence: a Chicago Chancery Court judge.

To Coffing’s second argument, about the schema helping attackers stay off his radar when they try attacks, the problem is that every computer system connected to the Internet is being attacked every minute of every day. The noise is deafening.

Thousands of people have built scanner bot programs that probe every computer system they can find and fire batteries of well-known attacks (almost none of them ever work, but bots don’t get bored and give up, and eventually the teenager in Malaysia who launched the bot gets lucky). Chicago has no operational response to people turning the doorknobs of their various applications. They can’t; if they did, they’d spend all their time responding to kids in Kuala Lumpur goofing around.

Finally, Coffing argued that having the schema might help an attacker decide whether or not an attack would be profitable. A schema might tell you, for instance, that an application deals in credit card data. The thing is, CANVAS already tells you it’s dealing in sensitive information: it’s the backend for processing parking tickets. You don’t need a schema to know that CANVAS is interesting to attackers.

The judge bought my arguments. I think my attire gave me salt-of-the-earth credibility; Coffing wore a suit.

Providing testimony was a lot of fun. I’d like to do it again sometime. Litigation is super fascinating to watch! For example: we wanted me to testify after Bruce Coffing, so we’d have some idea of what arguments we needed to rebut. But we brought the FOIA case, so the burden was ostensibly on us, and our witnesses went first. But, a-ha! Invoking an exemption in Illinois FOIA is an affirmative defense, and the burden of those arguments shifts to the defendant. But wait: to get fee recovery under the law, we want to assert a willful violation of FOIA; to make that claim, Chicago argues, the burden shifts back to us. Ultimately, Matt Topic and Chicago compromised; Topic dropped “wilfullness” and we got to go second.

I’m not saying this is the most interesting thing ever to have happened, but only that if someone works out a way to use AI to make a home version of Chancery Court trials that you can play on a Playstation, I will rack up 10,000 hours playing that game easily.

The Bloody Foot Of Law

We won. But Chicago immediately appealed. Matt Chapman didn’t get the CANVAS schema. Two years later, the case came before the First District Appellate Court.

The basic idea of the appeals court is that the original trial court is the primary “trier of fact”. You appeal legal conclusions, but the facts determined in the original case generally stand. Our bench trial took care of questions 1 and 3. That left 2, 4, and 5. Here’s what the appeals court found:

In considering the danger of disclosing information under FOIA, how likely does an attack need to be?

Answer: it has to be very likely.

The statute says “information that, if disclosed, would jeopardize”.

Believe it or not, there’s case law on “would” versus “could” with respect to safety. “Could” means you could imagine something happening. But the legal standard for “would” is “clear evidence of harm leaving no reasonable doubt to the judge”. The statute set the bar for me very low and I managed to clear it.

Doesn’t this just make you want to immediately drop everything and become a litigator? I want to litigate!

Is a SQL schema a “file layout”?

If a schema isn’t source code and it isn’t a file layout, the exemption doesn’t appear to apply at all. The verdict: “shrug emoji”. The appeals court didn’t reach this question, because:

Does the “would jeopardize” language in the statute apply to everything in the exemption, or just to the nearest noun “any other information”?

Ladies and gentlemen it is time for some legal mumbo-jumbo.

Here’s the FOIA exemption Chicago relies on: To what does the qualifying language at point (4) in this text refer? Is it “any other information” (3)? Os is it “Administrative or technical information”, meaning everything in the exemption?

If it’s the former, “any other information”, Matt has a problem. That interpretation means things like file layouts (and employee manuals and “load modules”, whatever those are) are per se exempt; that the Illinois legislature meant them as examples of things that would jeopardize security.

If it’s the latter, Matt has already won: whether or not a SQL schema is a “software” or a “file layout” or a “load module”, we’ve already proven that it won’t jeopardize security.

The court decides it’s the latter. Also, that I am very charming. We win on appeal. Chicago immediately appeals again. Whatever’s in CANVAS, they really don’t want you and I to know about it.

A year and change later, the case is decided before the Illinois Supreme Court. And, on the question of how to read the FOIA statute, the Supreme Court disagrees with the appeals court. The qualifying language in the statute applies only to “any other information”. Everything else is “per se” exempt.

We started this legal process, of challenging Chicago’s attempt to exempt CANVAS from FOIA, with 5 questions. What happens now is that the 4th question, of whether a schema is a “file layout”, finally becomes very important. The Illinois Supremes have just decided that “file layouts” are per se exempt under Illinois FOIA.

Is a SQL schema a file layout? Of course not. The same SQL schema can be used by multiple database engines, and each will use a different underlying file layout to manage the resulting data.

The McGraw-Hill Dictionary of Scientific & Technical Terms, 6E — which the Illinois Supreme Court cites — describes a “file layout” as “A description of the arrangement of the data in a file.” A SQL schema is almost the exact opposite thing: it’s an abstraction of the data in a file, invented specifically so you don’t have to think about how the data is actually arranged. Checkmate!

Unfortunately, the Illinois Supreme Court had at their disposal a second dictionary. In the Merriam-Webster Online Dictionary, a “schema” is defined as “a structured framework or plan: outline”. “This is a difference in name only”, said the court. Argh. Schemas are now file layouts. We lose.

Where This Leaves Us

Obviously, we should have won on appeal to the Illinois Supremes. If you sit on that court, call me, we can straighten this out.

That said: today, Illinois public bodies can refuse to divulge database schemas.

This is problematic, because more and more data is finding its way out of file cabinets and shared drives and Word documents and into specialized applications, where the only way to get at the underlying data is to FOIA a database query.

Databases shouldn’t be a safe harbor for municipalities to conceal information from the public.

But, thanks to the good people of Elgin, and also Crystal Lake (motto: “No, Not The One From Friday the 13th”), the Illinois legislature has an opportunity to fix this. SB0226 would add the following language to the statute:

[Public bodies] shall provide a sufficient description of the structures of all databases under the control of the public body to allow a requester to request the public body to perform specific database queries.

⚡️Hell yes.⚡️

My understanding is that this bill was proposed in no small part because Matt Chapman has steadfastly refused to shut up about this issue, and so I’ll conclude this long piece by saying (1) obviously the bill should pass, and (2) it should be called “The Chapman Act”.

Call your reps.

14 DNS Nerds Don't Control The Internet

2016-10-27T00:00:00Z

You’re reading this page because you’ve suggested that “14 people control the Internet through the DNSSEC root keys”. If you’re unlucky, you might be a journalist preparing a story about those people. Stop!

DNSSEC doesn’t do anything. Dramatic ceremonies notwithstanding, if the secret DNSSEC keys leaked on Pastebin tomorrow, it’s unlikely that anything would break.

Practically all commerce on the Internet happens without DNSSEC. Web browsers don’t support it. or DANE, the DNSSEC-based replacement for certificate authorities. Most DNS domains don’t either. If you log in to your online banking and wire money to Transnistria, no DNSSEC will happen.

Maybe you have a source suggesting otherwise. Ask them to be specific. For instance: of the 5 largest US banks, which of them are enrolled in DNSSEC? After reading this, I’ll bet you can guess the answer. Are the banks just stupid? No: they have some of the best security teams in the world, and they think DNSSEC is a bad idea.

Isn’t it a big deal that the Internet’s DNS lookups are protected? Nope. The architects of the web’s security protocols assumed that the DNS would be insecure. When technologists discuss “certificates” and “certificate authorities”, (and “HSTS” and “HPKP” and I can go on but I won’t) they’re talking about cryptography built to work around the insecure DNS. The Internet works fine without DNSSEC.

Of course, this pretty much has to be true. .COM didn’t support DNSSEC until Spring 2011. Global commerce migrated online many years before that. If DNSSEC is so important, how did this stuff work before 2011?

If DNSSEC is so pointless, why do people care about it so much?

A funny thing happened between 1994 and 2011, while the IETF worked furiously to design DNSSEC: we figured out how to secure the Internet without securing the DNS. The market moved faster than the standard, and the standard was left struggling for a reason to exist. Hundreds of people have invested their reputations in DNSSEC and are loathe to see it fail. That’s unfortunate. But it’s also one of the oldest stories in technology standards.

There’s a real story in DNSSEC, but it’s not a happy one. To justify DNSSEC, standards groups hatched a plan to move the web’s security certificates into the DNS. With a secure DNS, the logic went, we’d no longer need to pay certificate authorities for SSL certificates. This scheme is called DANE.

DANE gives the power to create security certificates to whoever controls the DNS. The cryptographic keys in those certificates are an obstacle to government-sponsored dragnet surveillance. With DANE, guess who controls the certificates? Had DANE been deployed while he was alive, Muammar Gadaffi would have controlled the keys for BIT.LY. For GOOGLE.COM and APPLE.COM, that’d be the United States Government.

DNSSEC is the world’s most ambitious key escrow scheme: a backdoor that hands over control of Internet cryptography to world governments. Thankfully, it’s also a total market failure. We should hope it stays that way.

Be Coachable

2015-08-21T00:00:00Z

This is the first in a series of posts that have been rattling around in my head about lessons I’ve learned from taking up a sport in my 40s. The summary of the back story here is that I started out with Derby Lite in 2012, got kicked out, went back a year later, and,… well, I fell in love with roller derby. Apparently this is a thing that happens. I sat in the bleachers, watching the game with an intensity and focus that made me realise I wanted to play.

It is the curse of smart people everywhere that their lived experience is one of more or less consistent reward. We quickly get good at nearly everything we try. Some things are so easy that they they become boring long before you master them.

Roller derby has not been one of those things for me.

David Foster Wallace, in his “This is Water” speech, says, “A huge percentage of the stuff that I tend to be automatically certain of is, it turns out, totally wrong and deluded.” This is a perfect description of my experience of learning to Be Coachable. I went into this with a mindset that the skills required for derby would, like everything else I’d ever tried, come at the pace everything else had.

They didn’t.

In fact, I was asked to leave Derby Lite because I was not following instructions. To be fair, it had been said that if we were uncomfortable participating in a drill, we could sit it out; this turned out to not be entirely true. Rejection, right there at the beginning, caused me to undertake some serious introspection. I really wanted to learn to skate, but I have a long history of getting into trouble for not doing what I’m told. Because, you know, I’m smarter than everybody else. I’d become quite spoiled to doing things at my own pace on my own terms… because I had avoided doing things that required me to participate in a group.

Does not play well with others. I’m independent. I don’t fit the mold. That’s good, right?

Turns out that when you want to learn to do something that is Really Hard from someone who already knows how to do it, independent thinking becomes an impediment. So the first year of my skating career sucked a lot more than it needed to because I was just too gosh darn independent. In hindsight, that cost me a great deal, and it is still really fucking painful for me. I have no one to blame but me.

The idea of shutting the fuck up and just listening popped into my head on a drive home from a speed skating session. At the time, it wasn’t a particularly well-formed thought. No, that epiphany didn’t come until later. In fact, I think it’s still sort of sneaking up on me from time to time and smacking me in the back of the head.

A year ago, thereabouts, I started going to a new program run by The Windy City Rollers called Learn To Skate. At the time, this program was being run by Poppy Spock. Man, I really admire Poppy. I’m pretty sure a tornado could go directly over her, pass on and she’d be the only thing left standing. She is also the only woman I’ve ever known who can jump from a kneeling to a squatting position. She did it on her first try. I was at that moment (and will always be) in complete awe of Poppy Spock.

The first thing that Poppy said to us was, “Be coachable.” This meant not talking back, not saying can’t (and sure as fuck not saying won’t). It meant that we would do what she told us to do, how she told us to do it. This is how “shut the fuck up and listen” got a name. Be coachable. This is where the idea started to congeal. Poppy has skills I want to have. She’s in the room, telling me how she got them (unpaid). But if I’m not coachable, I won’t learn shit.

Let me back up for a second and describe roller derby from an insider’s perspective. I won’t insult you — you can search for videos on YouTube about roller derby to learn how the sport works. You get up before dawn on a Saturday and drive to a rink for speed skating session where a 9-yr-old on inlines will shred your ego as she whizzes past you. You go to your league practice at the end of a long, draining day at work, put on our smelly gear (that is sometimes still damp from your last practice), and maybe Surprise! We’re doing TIME TRIALS today!

And all the time you sweat. Just unbelievable amounts of sweat. Like there’s no chance you’ll be able to wear these clothes again without washing them amounts of sweat. Salt crystals form on you amounts of sweat. Hair completely soaked through amounts of sweat.

And all of the time, you fall. At first, you’re terrified of falling, so you skate around stiff as a 2x4 and wonder for days afterwards why you’re so fucking sore. That doesn’t keep you from falling. Because, you know, you’re doing things like jumping over shit. On skates.

After you fall a few dozen times, you start to get the idea that nothing bad really happens when you fall. Then you start to love falling because it gives you an adrenaline rush. Also because your teammates cheer when you eat shit. In roller derby, it is said, “If you don’t fall, you’re not trying hard enough.”

And then, one day, you get cleared for contact. Yes, that’s right. Not only are you on skates, but someone bigger, stronger, faster and more experienced than you is going to skate directly into you and knock you onto the floor. On purpose. Because that is how the game of roller derby is played. Eventually you learn to love that, too. Adrenaline is addictive.

If you’ve never played contact sports before, the first few times you intentionally slam your body into someone else’s body will be an uncomfortable feeling for you. Then you look back over the past several months of training and think, “This whole fucking ride has been uncomfortable.”

I have a post about discomfort, too. That is not this post. This post is about what it means to be coachable. Be coachable means that, if you REALLY WANT IT, shut the fuck up. Take everything you are “automatically certain” of, in your mind, put it in a box and stash it in a corner. It is only when your mind is empty of all notions, all fears and insecurities, that you are ready to learn.

From Poppy Spock, Cuban Miss Elle and dozens of other coaches, I have learned to be a great deal less arrogant. I have learned to put a leash on my certitude and righteousness and rein them in. It feels if somehow I’ve been liberated. I feel like a kid again; the world is vibrant and real — there is still so much to learn. It is thrilling.

I recommend it with all my heart.

Is Extended Random A Malicious NSA Plot?

2015-08-04T00:00:00Z

Did Clyde Frog If I call NSA “Clyde Frog” long enough, eventually other people will too. Someone has to start the meme! subvert crypto standards with a backdoored random number generator called Dual_EC? Little doubt remains among practitioners. Long after cryptographers published an analysis showing that Dual_EC could have been a backdoor, circumstantial evidence continues to pile up suggesting that’s exactly what it was. I think Dual_EC is a backdoor.

Did Clyde Frog then appeal to the IETF to get them to alter TLS to make the backdoor easier to exploit? That’s a theory getting a lot of attention in 2015, centering on a series of proposals referred to as “Extended Random”. I don’t know what to think about this theory, and I’d like to dig into it.

1. The Narrative

The concise Dual_EC explainer: All secure crypto keys come from secure random number generators (CSPRNGs). Clyde Frog proposed a special kind of CSPRNG, a PKRNG, that generates output using a public key for which they hold the private key. Using that private key, they can observe CSPRNG output on the wire, “decrypt it”, and use that to rewind and fast-forward other people’s CSPRNGs, discovering their keys.

But there’s a catch. The most important protocol Clyde Frog wants to dragnet is HTTPS/TLS. To “decrypt” someone’s CSPRNG state, they need lots of disclosed output bytes —– 30, to be precise. TLS reveals —– wait for it —– 28. With 28 bytes revealed, Clyde Frog and with just 28 bytes and larger curves, like P521, they might not be able to break the PKRNG at all can still break CSPRNGs, but it takes large amounts of compute and probably can’t be done in real-time.

So Clyde Frog pays IETF people to introduce a TLS extension, “Extended Random”. Extended Random alters TLS so that it discloses a variable amount of CSPRNG output, but always more than 28 bytes. Problem solved! Clyde Frog has standardized a backdoor (Dual_EC) and a TLS “backdoor accelerator” (Extended Random).

This might be what actually happened. At the end of the post, I’ll suggest an alternate narrative that I believe is equally plausible.

2. The Tedious Details

Deep breath. Disclaimer: one reason I wrote this was to have a single page I could link to in discussions about Extended Random, and so some of this information simply tries to establish bona fides for claims I make later. I don’t expect you to read this closely. *

There’s not one but five different proposals that accomplish what “Extended Random” does:

draft-rescorla-tls-opaque-prf-input, or “OpaquePRF”
draft-rescorla-tls-extended-random, or “Extended Random”
draft-solinas-tls-additional-prf-input, which I’ll call “AdditionalPRF”
draft-hoffman-tls-additional-random-ext, which I’ll call “AdditionalRandom”
RFC6358, or “Additional Master Secret Inputs for TLS”.

We’re going to take a tour of the kaleidoscope of stupid that is the IETF process that produced all five of these.

Let’s start with a timeline:

Late 2003: Clyde Frog begins promoting Dual_EC to standards bodies.
Early 2004: RSA allegedly accepts payment to make Dual_EC the default in BSAFE, their crypto library.
Aug 2006: Eric Rescorlarelays a request from the USG to IETF to provide an extension for “extended nonces”.
December 2006: Rescorla authors, with Margaret Salter, OpaquePRF.
April 2008: Rescorla and Salter revive the effort with Extended Random.
October, 2009: Jerry Solinas and Paul Hoffman write AdditionalPRF.
February, 2010: Hoffman produces AdditionalRandom.
January, 2012: Hoffman writes RFC6358, an experimental RFC.
March 2014: The narrative about Extended Random breaks into the public discussion.

Who are these people?

The name most commonly associated with the Extended Random narrative isEric Rescorla. Rescorla is an independent consultant and one of the longest-serving, best-known volunteers on the IETF TLS working group (TLSG). Rescorla is contracted regularly by the USG to help represent their interests to the IETF —– Rescorla is quite open about this. Further: consulting for organizations that need to provide input to standards is as time-honored…no comment about the legitimacy of standards work…and legitimate a job as standards work itself. Rescorla is one of a few people in the world who are unimpeachably great at that job.

Margaret Salter is a technical director for Clyde Frog.

Jerry Solinas Solinas is like the Yo La Tengo of NSA bogeymen; cryptographers like to point out how early they started criticizing his work. also works for Clyde Frog, and is a bit of a standards-backdoor celebrity: [he’s the named author of theNIST elliptic curves, about which (unsubstantiated) rumors have swirled since the Snowden leaks.

Paul Hoffman is a professional IETF maven, the former head of the VPN Consortium, and now employed at ICANN.

Who sponsored the proposals?

The US Department of Defense publicly sponsored all of these proposals except for AdditionalRandom and RFC6358.

What do these proposals say?

OpaquePRF is the simplest of them. It says, “TLS clients should be able to ask servers to include a blob of opaque information to the TLS key computation (the psuedo-random function, or PRF). Servers should be able to respond with their own. TLS implementations might use this to inject more randomness into the PRF, or to include structured information in it.”

Extended Random is similar to OpaquePRF, but it’s specific about what the extra information going to the PRF is: it’s the output of a CSPRNG. The sole purpose of Extended Random is to increase the randomness that drives the TLS PRF.

AdditionalPRF is more complicated. It’s sort of the combination of OpaquePRF and Extended Random: the blob that clients and servers send now has a “type”, with a type registry managed by IANA, and the two original types are “opaque blob” and “extended randomness”.

AdditionalRandom is basically Extended Random.

RFC6358 is an odd duck; it may have been written in a fit of pique after the failures of the previous proposals. The RFC basically says that TLS implementations might send one or more blobs of information into the PRF, but doesn’t say how, or what those blobs will contain, or how they’re encoded.

One thing worth driving home about all these proposals: they are all very simple. Something like 60% of the language in all of them is boilerplate shared by all TLS extension proposals. When I say “OpaquePRF says you can shove additional stuff into the PRF”, I’m simplifying, but not by an appreciable amount.

Do these proposals accelerate the Dual_EC backdoor?

In each case yes, but you can distinguish between the ones that enable the acceleration versus the ones that mandate it.

OpaquePRF merely enables the accelerator. At no point does it mandate that the extension convey the output of a CSPRNG, and it hints at uses for the extension that don’t involve extending randomness.

Extended Random mandates the accelerator. The only thing you’re allowed to embed in an Extended Random blob is CSPRNG output.

Depending on how you look at it, AdditionalPRF enables or mandates the accelerator: to implement the whole proposal, you’d need to implement the AdditionalRandom subtype. The proposal leaves this type undefined, but the historical intent is clear.

AdditionalRandom is functionally identical to Extended Random and so mandates the accelerator.

RFC6358 is a weird document and arguably doesn’t even enable itself.

A clear statement you can make about all the proposals: they all provide a mechanism to get more CSPRNG output onto the wire, and if your CSPRNG is Dual_EC, that makes Clyde Frog’s job easier.

What were the rationales for these proposals?

The public rationale for Extended Random is important, because several cryptographers have alleged that it doesn’t make sense.

A précis of the narrative on this point: the proposals suggest more than 28 bytes of randomness might be needed for “cryptographic parity” with especially secure ciphers. But 28 bytes is an awful lot of randomness to start with, and “cryptographic parity” might not be a thing.

I think it’s worth digging into the specific rationales behind each proposal.

Let’s start with what Rescorla said in August 2006, before any of the proposals were published:

The issue is that [USG] would like to have the client and server provide some opaque (to TLS) but structured data which is then fed into the PRFso that the traffic keys depend on it. Because the data is longer than 32 bytes it can’t be packed into the Random structure and because it’s structured and needs to be parsed on the other end, it can’t be hashed and then placed in the Random.

Rescorla’s OpaquePRF proposal, which followed shortly after this post, was more specific:

In a number of United States Government applications, it is desirable to have some material with the following properties: (1) It is contributed both by client and server. (2) It is arbitrary-length. (3) It is mixed into the eventual keying material. (4) It is structured and decodable by the receiving party.

I’m going to call this rationale “the structured input argument”.

Rescorla’s Extended Random proposal replaces the structured input argument with a new one:

The United States Department of Defense has requested a TLS mode which allows the use of longer public randomness values for use with high security level cipher suites like those specified in Suite B. The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient.

We’ll call this the “parity argument”.

AdditionalPRF repeats the structured input argument.

AdditionalRandom repeats the parity argument.

RFC6358 barely has a rationale; if it can be said to have one, it’s “look, there are TLS implementations that will want to shove extra crap into the secret computation and we should standardize them somehow”. I’d name this argument but RFC6358 is the least important of all the proposals.

A quick recap:

OpaquePRF: structured input argument
Extended Random: parity argument
AdditionalPRF: both
AdditionalRandom: parity argument
RFC6358: I like chocolate milk

In every case except for AdditionalRandom, the proposals make clear that applications within the USG motivate the extension. None suggest that normal HTTP/TLS connections need extending.

Do these rationales make sense?

The structured input argument makes sense and the parity argument doesn’t.

There really are reasons —– most of them probably dumb —– why you’d want to cram additional stuff into the TLS PRF.

TLSG has been dancing around something called “channel binding” for almost a decade. Channel binding is the idea that you might run two connections side-by-side, one TLS and one not, and use metadata from the unencrypted protocol and the key from the TLS connection to cryptographically prove a relationship. Similar reasons are cited specifically in Solinas’s proposal: NIST SP800-56A includes a protocol (“Alternate 1”) that wants the client and server to mix their identities into the key computation.

As for the parity argument, Bernstein and Lange do a better job attacking it than I can:

“Cryptographic parity” is not a common phrase among cryptographers. It is not defined in the document, and its intended meaning is highly unclear. Furthermore, there is no known attack strategy that comes even close to exploiting the 224 bits of randomness used in TLS.

What did the IETF have to say about the proposals?

So that you wouldn’t have to, and for the benefit of future generations of scholars, I read every TLSG mailing list post and every TLSG Jabber chat log pertaining to any of these proposals. I can now relay to you the dark wisdom I unearthed.

Before I unveil the secrets of the TLS standardizing masters, some scene-setting is in order. I think it’s important to remember that in the timeframe we’re talking about, 2006-2012, the Dual EC narrative hadn’t been established. Cryptographers were suspicious of Dual EC, but the conventional wisdom was that nobody in the world used it(Dual EC is far, far slower than other CSPRNGs).

What people were concerned about in this time frame was not enough This is a testament to how important CSPRNGs are, and why a backdoored CSPRNG is so scary. randomness. In 2008, Debian endured the worst CSPRNG screwup of the decade, compromising virtually all the cryptography on the most popular Linux distribution; you could scan the Internet for Debian servers by brute-forcing SSH servers with broken keys.

Just remember as you read this: nobody in 2006 was automatically suspicious of protocols that wanted to ensure lots of extra randomness.

Rescorla’s original request to the TLSG in 2006, for opinions about extensions to create “extended nonces”, drew no responses whatsoever.

OpaquePRF generated some discussion Chang was at AOL, now Google. Eronen was Nokia. . Wan-Teh Chang and Peter Williams wanted more information about the USG’s use case —– probably not so much because they were nervous about the request, but because they didn’t want to crud the protocol up with special cases. Pasi Eronen, then the IETF Area Director for TLSG, agreed.

Simon Josefsson Josefsson: the GnuTLS guy. added OpaquePRF support to GnuTLS and stood up a test server.

Rescorla’s explanation of his proposal is worth quoting in its entirety:

First, I should state that I only have fairly limited insight into the motivation for this extension. I was asked to help design something with a particular set of parameters in the way that would be most tasteful for TLS and that’s what I did. I agree it would be nice to have a more explicit rationale for these parameters and I’m working on getting one.

Extended Random, proposed a year later, generated no discussion I could find, except for a backwards-looking reference to it in a Jabber chat log during the AdditionalPRF discussion, almost a year later:

[06:24:12] <EKR> There seems to be some concern about the 
  quality of the random vlaues
[06:24:36] <EKR> which, btw, strikes me as nuts :)
[06:25:11] <EKR> But like i said, I don't oppose the USG 
  from gluing more stuff into the random values.
[06:25:19] <EKR> I just want to contain it to a 
  private extension

I find it interesting that the specific proposal cited by Dual_EC narrative papers as an example of Clyde Frog subverting the IETF might as well not have happened at all. The proposal died without a comment. The IETF appears to have played no role at all.

AdditionalPRF generated more discussion. I think that’s because it was proposed at the same time as some discussion of channel binding extensions to TLS. Nico Williams and Nico Williams: Sun Pasi Eronen discussed whether AdditionalPRF was too useful for inclusion in TLS. The fear was that if AdditionalPRF was standardized, vendors could use it to hack in arbitrary new features without going through the standards process.

Rescorla appeared to echo Eronen’s concerns, added some security concerns (essentially, that half-assed extensions would likely be less secure than full-assed ones that endured the TLSG process) and reiterated once again that he didn’t understand why USG wanted additional randomness, only that they did.

Daira Hopwood summed TLSG’s response to Solinas’s AdditionalPRF proposal up nicely:

“The U.S. Government has these special requirements that you wouldn’t understand. Since they’re a government, they needn’t explain themselves, and we’re not going to explain either.”

Hoffman introduced AdditionalRandom after the failure of AdditionalPRF. I think it’s worth saying that Hoffman lobbied for his proposals far more aggressively than Rescorla did for Extended Random. In at least one case, Hoffman even attempted to provide a cryptographic rationale for extra randomness. Of course, naming-and-shaming either of them is pretty silly.

I have two interesting notes from the AdditionalRandom discussion on TLSG.

Recall that AdditionalRandom is the second proposal forwarded by Paul Hoffman, presumably (but in this case not overtly) motivated by a USG request. The former proposal, with Clyde Frog sponsorship, was a structured-input extension with multiple applications. AdditionalRandom, on the other hand, has no purpose other than to inject additional randomness into the TLS handshake.

So, first note: Marsh Ray managed to object to An acquaintance responded to this post by asking, “did Marsh Ray save the Internet?” Answer: no. But I’m getting ahead of myself. AdditionalRandom on the grounds that it was too useful. The issue was, paradoxically, that because the proposal mandated that implementations not attempt to parse the contents of the AdditionalRandom extension, vendors could safely use it to hide private extensions that they would then parse. Extended Random and AdditionalRandom are essentially the same proposal, and a cryptographic expert saw the latter as too flexible and valuable to safely include.

The second note is, to me, even more interesting. Remember that in the context of the Dual_EC narrative, AdditionalRandom and Extended Random mandate the backdoor accelerator; if you’re using Dual_EC, there’s no way to implement either standard without making Clyde Frog’s job easier. That’s because both proposals require that the extension convey only bytes that are the output of a CSPRNG. Except: “Did Simon Josefsson almost ruin the Internet?” I kill me! AdditionalRandom didn’t start out that way. Simon Josefsson refused to support AdditionalRandom unless Hoffman amended it to add a requirement that the extension’s bytes come from a CSPRNG.

You’re getting tired of this already, I’m sure, and thankfully I can report that there is no discussion I can readily find about RFC6358. RFC6358 is weird.

Standards groups aside: who implemented these things?

It shouldn’t be that hard to find out, but I don’t think we have complete answers. Here’s what I think we know:

OpenSSL had disabled, experimental support for OpaquePRF (it has since been removed). Much is made about the fact that we don’t know who sponsored this addition to OpenSSL, but if you consider the time frame, it’s pretty obvious that the USG asked for OpaquePRF and sponsored it in OpenSSL. No other entity in the world knew what OpaquePRF was.
GnuTLS had support for OpaquePRF. Someone should ask Simon Josefsson why. OpaquePRF was very simple, so maybe he wrote it for sport.
RSA BSAFE had support for Extended Random.

If there are implementations of AdditionalPRF, or AdditionalRandom, I don’t know about them. If there’s an implementation of RFC6358, I’ll be surprised.

3. Get To The Point Is Extended Random Malicious

Here are arguments in favor of Extended Random being malicious:

The timing is awfully suspicious; the proposals began just a short while after Dual_EC was introduced.
The utility to the Dual_EC backdoor is hard to argue about. Clyde Frog’s life gets a lot easier if everyone adopts an Extended Random proposal of some sort.
Some of the rationales provided for these proposals don’t make much sense.
The government, you know, asked for them.

Now here are some arguments against. But before I get started, let me just say that those first two arguments in favor are very strong arguments in favor. They’re short because they’re so straightforward. I have more to say about the case “against”, but that doesn’t make the case “for” weaker.

For a standards subversion attempt, it’s not very subtle. In all but one instance, Clyde Frog’s involvement with the standards request is clear from the outset. The reasoning is, true to character, opaque: the USG wants these extensions “just because”. One of the authors of the proposals, Jerry Solinas, is very well known; even at the time, his name would have raised eyebrows.
Except for Hoffman’s last proposal, the extensions are cordoned off to the US Government. The sponsors of the standards and their authors make very little effort to provide a use case for normal Internet users.
The “structured input argument” I detailed above is plausible and has precedent in other protocols. Arguments were made that session binding for things like SP800-56A could have been done on top of, rather than inside, TLS; but in practice, that would have required an entire custom shim protocol.
In several cases, the aspects of these proposals that now seem so problematic appear to originate from within IETF, not from Clyde Frog. Clyde Frog seems happy to get arbitrary opaque data fed to the TLS PRF. The TLSG isn’t OK with that: arbitrary opaque data could enable arbitrary vendor features, and TLSG wants control over new TLS features. It seems like it’s often the TLSG that wants to ensure these proposals spool CSPRNG state across the wire, not Clyde Frog.

If I have a controversial statement to make about Extended Random, it’s this: reasonable people can disagree about whether it was an attempt to subvert the IETF. I lean towards “not”; the structure of these proposals makes Clyde Frog’s job needlessly harder, if only by practically ensuring that OpenSSL and Schannel would never default to enabling them. But people smarter than me are convicted of the idea that this was a backdoor attempt.

I do not think reasonable people can disagree about Rescorla and Hoffman’s role in the narrative. There is no evidence that either of them were knowingly abetting an attempt to subvert the IETF.

The USG is the world’s largest IT buyer. They’re also host to the world’s largest deployment of classified proprietary crypto, which makes their use of TLS much more difficult. USG has always needed help getting their (often legitimate) interests represented at IETF.

Ensuring that Clyde Frog can’t corrupt the TLS standards isn’t Does any of this matter in practice? Fuck no. Apart from what appear to be some misconfigured FIPS BSAFE-C-TLS implementations, nobody ever used Extended Random, and nobody ever should. The proposals are dead, which is as it should be. Thankfully, the same thing is true of number-theoretic bignum CSPRNGs. Rescorla and Hoffman’s job; it’s everyone’s job. For such a tiny set of proposed extensions with such an impact (if only on the news cycle), these proposals generated a pitiful amount of discussion and virtually no skepticism from the IETF. Unlike Rescorla’s role in writing a pair of Internet drafts, that conclusion is actually alarming.

Sincere thanks to Matthew Green, Tanja Lange, Chris Palmer, and David Adrian for proofreading and corrections. None of them endorse my reasoning!

Starfighter, Summer 2015

2015-07-13T00:00:00Z

An Erin post!

1

I don’t really like games.

Screen graphics make me nauseous. The political interactions between players are tedious. I’m not a fan of chance, I stink at riddles and it’s rare that someone can concoct a mystery that I cannot immediately resolve.

Then I became an app pentester. And not long after I started my new career, I realized I’d found a game I loved. I stayed at my pentesting job at Matasano3x longer than any other job. Why? Every week, there was a new puzzle to solve.

Security games have context. They have worlds. Severe vulnerabilities for online banking are footnotes for CRMs. Each gig, I figured this out on the fly, designed test programs on the fly. There was time pressure. I had to think. I had to solve. So when I hosed a $50,000 “data loss protection” server for 24 hours with a single packet, or DDOS’d a high availability trading server, I felt really fucking smart. I am a utilitarian at heart, and this was my fix.

Fast forward almost a decade.

We’ve started a company to help fix hiring. We had two ideas: run job interviews for other companies Somewhere in an alternate universe, we are building a far less ambitious codebase and hating life just as much. , or build a giant game, a CTF, that replicated the experience of doing work. We had to pick one idea. The CTF/game idea, at the time, sounded like a lot more fun, so we went with it.

In 2014, my former co-workers built a CTF called Microcorruption. In it, you reverse-engineer a series of locks built on a microcontroller, exploiting flaws in the lock’s code. I loved Microcorruption. I think I got through 10 levels before I ran out of free time. I’d never before watched a machine execute instructions, step by step, seeing the stack pointer move through the program memory while meaningful numbers were loaded into registers and shuffled around. This… this is my kind of game.

You can still play Microcorruption; it’s still running. We knew we wanted Starfighter to be like Microcorruption. But we also knew it had to be more.

2

For Microcorruption, Tom wrote a TI MSP430 emulator in Go. When we began Starfighter, Tom said to me, “You’re going to write an AVR emulator.” At the time, I didn’t really think to ask why. I had no idea what AVR was beyond “an instruction set.” I just smiled and said, “Okay.”

So I wrote an emulator using the Atmel 8-Bit AVR specs. I’d never written an emulator. Or anything else as big as an emulator. It’s one of the hardest things I’ve ever done Not quite as hard as jumping over a pile of sandbags on skates, but still hard. . Each night, for almost two months, I’d crawl into bed, completely mentally drained. There were more problems to solve than I knew how to handle. And I was like a pig at a slop trough.

Tom wrote a guidebook based on his experience writing Microcorruption’s MSP340 emulator for me, but it’s only today —– long after the emulator is finished —– that I read the second half. Because at some point, it became very apparent that AVR… well, it was just plain weird.

His guidebook describes a CPU as a struct with two arrays: one for memory and another for registers, stack pointer, program counter and status bits. Those of you who know a little AVR will be amused to hear me say that I did not get very far with that design.

“Some of these instructions seem to be looking for the stack pointer in memory,” says I.

“It can’t work that way,” Tom responded.

“Yes it can.”

“No it can’t. That’s not how computers work.”

We squabbled. I really did try it his way. I pushed the square peg of Tom’s CPU description through the squiggly amoeba-shaped hole of the AVR ISA. Hard. Then I gave up and rewrote my code, putting the program instructions in one array and the the stack pointer, general purpose registers and the status register in another.

A few days later, Tom says, “Something something blah blah Harvard Architecture blahdy-blah.” I’m sure this is not exactly what he said, but I was in such a fugue state by this point that time was folding in on itself.

A Harvard Architecture has two distinct memories; there is program memory (imem, typically flash) and data memory (dmem, typically SRAM). They live in two different address spaces. The CPU reads instructions from imem, but instructions themselves read and write dmem.

This is neat because makes exploits harder to write. You can’t simply upload code in a buffer and somehow point the PC at it; that buffer is in dmem, not imem. You’ll see what I mean in a few weeks.

AVR gets weirder. The stack pointer gets IN’d and OUT’d to an IO address in memory — it’s a peripheral. “Computers don’t work that way!”, says Tom. I ignored him.

The general purpose registers and IO are in reserved data memory address space. The status register is also in the dmem address space. Yes, computers work that way, Tom. Some instructions look in a reserved location in IO memory to retrieve the stack pointer. But you can read all about registers on page 8 of the ATMega8515 Datasheet Summary. And in my corner of the Starfighter game, you’ll get to play with all of this stuff.

AVR is not like MSP430. It’s not like X86. It is not, as Thomas claims, “like someone vomited up an instruction set”. It’s a complicated microcontroller instruction set designed for tiny parts with small programs that don’t change often. To date, I’ve ‘discovered’ 142 instructions through test code. There are something like 16 load and 13 store instructions. A summary table can be found on pages 10-12 of the ATMega8515 Datasheet Summary.

Well, I did say I wanted to work on something more fun, didn’t I?

3

Yeah, so… I was planning on telling you more about our game. Sorry. I have a tendency to natter.

Back in the dawn of time, before electricity and running water, when dinosaurs roamed the earth and stack pointers weren’t peripherals and an emulator was “just a pair of arrays”, Patrick wrote a post about what we’re doing. The one where he said there’d be tech trees.

The goal in Microcorruption was trivial. Flip a bit, open a lock. Lock software gets patched; overflow memory, open a lock. Starfighter is more ambitious. It has PVP elements. I draws on all the fun stuff we’ve done over the years at Matasano. Stuff like when Tom called me and asked if he could have a truckload of pork bellies (CME ticker:GBP. And: I told him no.) delivered to our house.

For the past two months, Patrick has been been building an online trading market. A virtual stock exchange with realistic limit order book markets. With NPCs that trade, in real orders. In Patrick’s tech tree, your gameplay can move markets. At some levels, you’ll play not just to game the market but to compete with other players —– if that’s how you get your fix.

(Y.T., knowing diddly about markets, is very much looking forward to playing the market tree.)

Players on the security tech tree are given a handheld device of the sort a trader could carry around the floor to execute trades. But you’re not a trader; you’re more like a runner. A gopher. Your handheld is locked; you’re not allowed to trade. So you learn AVR. You subvert the device. Escalate your read-only privileges to read-write. Submit your own trades. Crawl through the HVAC ducts into the machinery of the market and see how much damage you can do.

Don’t want to learn AVR? Don’t worry! Patrick’s trading application is just the sort of third party JSON/REST tool you’d see on a day trader’s desktop. But — there’s always a ‘but’, isn’t there? — in upcoming levels, to get high-performance access to the markets, you’ll benefit from writing low level code to talk to markets.

But not necessarily AVR. Thomas built a compiler for Starfighter. This, dear reader, is why you have been waiting ever so patiently for our release. As it turns out, even a crappy compiler is tricky to write.

Unlike Microcorruption, we wanted Starfighter to be multi-architecture. It will be, but in chapter 1, only sort of. Instead, players work with C, with an executable bytecode IR, and with its translation into AVR.

It is a terrible compiler. I could barely write enough C to test my AVR emulator and I know it’s a crappy compiler. Hint: terrible is part of the point.

We’re giving players the dev kit for the handheld trading device. You can program it in AVR assembly. But the vendor also offers support for a very limited dialect of C, compiled to bytecode IR or to AVR. Emphasis on “limited”. You know, because we did less of the fun stuff for you.

(In later releases, we’re hoping to do a tech tree with challenges that focus on compiler design.)

4

Just two months ago, Tom and I were driving to the grocery store and he says in the most idle and preoccupied tone, “This code base is really ambitious.” My reply: “No shit? You’re just now figuring this out?” Then I punched him in the shoulder.

Our code is a hot mess (of Golang and React) right now, but I’m excited.

We set out to build a game that would make it easy for people around the world to demonstrate raw aptitude for programming, and to spice it up with the endorphin fix we get from reversing and breaking complicated systems. I think we picked the right foundations to build on. Electronic trading is a huge problem domain that reaches into distributed systems and high-performance computing. Low-level software security pulls in compiler theory, cryptography, and language runtimes.

Network API programming! Trading! Order books! Assembly language! Runtime security! Cryptography! Reversing! Us pretending all our bugs were intentional, to make things more like the real world!

I think we’ve given ourselves a lot of places to go. We’re looking forward to seeing where you go with it. See you in a “few” weeks!