Blog

If you are the kind of person who enjoys reading accident reports for fun (hi), you may have heard of the Therac-25, a medical radiation device. Some of us learned about it in school, including yours truly, by reading this paper by Leveson & Turner describing how it had some software bugs and ultimately killed some people.

In 2026 I think we’re all pretty aware that software can have serious negative real-world consequences up to and including death, but when I first read the paper in 2007 or so it was a bit of a wake-up call for me.

When I started at Akamai in 2012, my manager had just gotten really into the work of a Prof. Nancy Leveson, whose book Engineering a Safer World (open access PDF at link) was just out. Eventually he convinced me to read it, but I didn’t realize until well after I finished that the Prof. Leveson of the book was one of the authors of the Therac-25 paper I’d read in school. Safety is a small world.

Some time after that, what I remembered of the paper and what I’d learned from EaSW suddenly came together in my head with a force like an X-ray burst, and I realized that one of the lessons I’d originally taken from the paper was quite incorrect and, better yet, EaSW taught me why.

If you talk about software and safety a lot (also hi), the Therac-25 will come up in conversation from time to time, and I’m always very interested now to hear what lessons people take from the paper. There are a few common observations, but perhaps the most common is the one I now describe as the Hardware Interlock Fallacy.

Yeah, that’s the real issue.
I should’ve phrased it to point to the replacement of proven safeties being replaced by unproven ones, with those responsible dismissing reports that the new ones weren’t working.

Altytwo Altryness, BS (@whereIsTheSpai)

This is the tweet that set me off (and in fact this blog post is a cleaned-up version of my tweet thread), but I want to be really explicit when I say that I’m not trying to rag on @whereIsTheSpai here. I believed the Hardware Interlock Fallacy too, when I first read the paper. The paper’s authors maybe even believed it when they wrote the paper! We get to watch the field advance in real time, how cool is that?

So what is the Hardware Interlock Fallacy? First we need to understand a little bit about the Therac-25. The best way to do this is to go read the paper, and then I’ll recap the important bits. (I hadn’t read the paper in a decade; I had to go read it again before I could finish the thread.)

Okay. You’re back. Very quickly: the Therac-25 is a medical radiation machine. Its purpose is to apply a narrow and metered beam of radiation to a small area of a patient’s body in order to kill the cancer cells growing there. The Therac-25 in particular output an electron beam at various powers and then either delivered it directly to the patient or converted it to X-rays and then delivered it.

There’s a turntable between the beam source and the patient which looks like this and controls what happens to the beam before it hits the patient. And it is very, very important that the patient not be exposed to the unfiltered beam.

The mirror is there to make it possible for staff to position the patient correctly under the beam so only the treatment areas are exposed and they’re exposed correctly, and in the mirror mode, the electron beam source is inactive and instead a lightbulb simulates the beam. Or the beam source is supposed to be inactive.

You can probably tell where I’m going with this already.

When we read the Therac-25 paper for class, essentially everybody came away with the idea that the “root cause” of the problem was that the hardware interlocks has been removed between the Therac-20, which had similar software bugs but no accidents, and the Therac-25. The paper itself argues against this implicitly but not explicitly, and given the prominence of the interlocks throughout the paper and the authors’ own recommendation they be reinstated it’s a seductive reduction to make.

The software was supposed to check that the turntable wasn’t exposing the patient to the full strength beam before turning it. However, under certain machine configurations, there was a race condition with a 1/256 probability that the turntable position wouldn’t be checked.  (This was not the only software bug, or the only software bug implicated in some of the accidents)

And this is really important, so I’ll say it again: It is really, really important that the patient not be exposed to the unfiltered beam. People who were so exposed died fast, horrific, and painful deaths.  You could almost say that “the patient must never be exposed to the unfiltered beam” is a design invariant of the machine, which it must uphold in order to be operating safely.

And while hardware fails differently, it does fail. The machine’s designers were intimately familiar with hardware failure, and seem to have believed that software, which is not subject to wear, weathering, etc should be more reliable.  At many years’ remove that may seem silly to us, but it doesn’t prevent us from making implicitly the same mistake in reverse of trusting hardware more than software, with also bad consequences (see e.g. making the mistake of trusting the hardware encryption of your SSDs).

So the Hardware Interlock Fallacy is this: It doesn’t matter the precise mechanism by which a safety design invariant is maintained, only that it is maintained.

A couple years ago a family member who was thinking about starting their own consulting company reached out to me, and I wrote up a long answer to them about what I had learned so far that I hoped was helpful.  Last week when I sat down with a friend and former colleague, who was in a similar place, I realized that I had never posted that advice publicly, and if it might be valuable to these people then it might also be valuable to a wider audience.

This was the question that started it off:

What is the one thing you wish someone would have told you when you were about to start your company?

And this is what I wrote in response:

Continue reading “Advice for New and Aspiring Consultants”

I was revisiting my Github README article about incident communications the other day and noticed that many of the links I had put in my bio to Akamai’s public-facing incident management documentation had rotted away due to some intervening revision of the Akamai web site.

Since they provided valuable context and I had cause to want to refer to them in my client work, I went and tracked them down in the invaluable Internet Archive, and present now the links on their own as well as a fixed version of the bio with working links (and some paragraph breaks for readability).

• Akamai’s Infosec Program
• Incident Management at Akamai
• Information Security Compliance

And the updated (very casual) bio:

Hi there 🙂 I’m Kevin (@kevinr.free-dissociation.com).

While I learned to code while I learned to read and have loved computers my whole life, I realized pretty quickly after college that I wasn’t going to be happy spending the next forty years of my life sitting in a cubicle in a corner writing code and not talking to anybody.

After a bit of a sojourn I landed in security, which I love because it’s the intersection of the hardest technical problems we know (like cryptography) and the hardest social problems we know (like making cryptography usable by people).

I got my start in Infosec at Akamai, where I helped to redevelop our incident management process, train incident managers, and served as an incident manager myself on some gnarly and interesting incidents.

These days I have my own little shop, and I’m available for consulting on incident management as well as several other areas of security, privacy, and the broader emerging field of software safety. In my “spare time” I make videos on security and safety topics. 😉

I value the truth, and, more importantly, I value the process of seeking the truth.  Scientific methods, despite every misstep, are the best methods we know for developing and understanding truths about the universe around us and ourselves—that is to say, they give us the best ability to predict what will happen in the universe and in our social systems.

I value the physical world.  The physical world around is is the ultimate source of truth in the universe, and, while our understanding can never fully capture that truth in all its manifold complexity—to do so would take a system larger than the universe—still we can, collectively, approach some kind of asymptote of understanding and ability to predict the world around us both physical and social.

I value the people around me and the human species as we are, alive, today, and tomorrow.  I value that as many of us and our children as possible are as healthy, happy, and safe as possible, and I have dedicated my life to doing what I can to make us all healthier, happier, and safer.  I believe that understanding the physical and social worlds is valuable precisely for the reason that that understanding offers our surest path to those outcomes.

(The future beyond that is our children’s and our children’s children’s responsibility, just as our health, happiness, and safety today are our responsibility and not our great-grandparents’.  Our duty is to set our children and grandchildren up for success as best we understand that, but not to trade their health, happiness, and safety for those of hypothetical far-future many-times-great grand-children.)

I value democratic methods of decisionmaking.  Like science, politics is also a method for understanding the social world, the impacts it has on the physical world, and the impacts of the physical world on it.  Politics is the arena in which we define what it means for us to be healthier, happier, and safer, and who gets to be that.  Democratic decisionmaking methods, despite every misstep, provide the best ways we know for developing what it means for us to be healthier, happier, and safer and understanding how that might be achieved, and for spreading those benefits to as many people as possible.

I value capitalist and socialist economic methods and structures to the extent that they serve the other values.  These methods are among the best economic methods we have found so far for distributing high-quality, safe, and wholesome physical goods to as many people as possible, and capitalist methods do the best job of any economic methods we have found so far of turning basic human self-centeredness to socially-beneficial ends.

 

I wrote up some fairly off-the-cuff travel cybersecurity advice back in 2022 for a client, and it’s generic and useful and still current enough that I thought I would post a lightly-edited version here.

Its audience is mostly-US persons and US-based organizations traveling abroad for conferences in a professional capacity, although I think it is fairly applicable outside that.  This advice is also specifically not for people who believe they are or may be actively targeted!

Obviously in fall 2025 the risk calculus, particularly for non-US persons traveling to the US, is changing very rapidly, and without doing substantially more reading and thinking I don’t feel I can give good advice to that specifically.  I do think the advice here still provides a good, safe baseline for everyone, and additional measures can be layered on top as you need and desire.

---

tl;dr:

1. If you are ever concerned that your device may have been compromised, stop whatever you’re doing and reboot it immediately.
2. Take your software updates, always, but especially before you travel.
3. Don’t click through certificate warnings on public WiFi!

How come? Read on.

Continue reading “Basic Conference Travel Cybersecurity Advice”