Over the past couple of months, I’ve been struggling to understand why Flash has to die, but C gets no blame. (See 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11.)

I was confused because I was hearing over and over that the reason Flash had to die was for its poor security, but I knew that the root of Flash’s security problems come from the choice to implement it in C/C++.

The fact that C/C++ inherently leads to insecure programs is well known and well documented. It is as true as a fact can be: it is true if you look at it anecdoctally, for a few example programs; it is true if you look at all Flash security issues; it is true if you look at all web browsers; it is true if you look at any class of C programs written by any community of programmers. It is fractally true—it is true at whatever level of detail you care to examine.

What I forgot is how often facts don’t matter. Facts only matter when they are part of a narrative.

The foremost reason that Flash is dying is that Steve Jobs decided he didn’t want it to run on iPhones. As the CEO of Apple, he had the power to make that happen, and everything else follows from this.

In Thoughts on Flash, Jobs lays out the reasons for his decision, which he claims is “based on technology issues,” and not business issues. It’s interesting to look back at his letter, written in April 2010, from today’s perspective.

Jobs gives 6 reasons for not allowing Flash on iOS:

1. Flash is not open, Apple is open.
2. Flash does not provide anything that Apple user’s can’t already get.
3. Flash is unreliable, insecure, and a performance hog.
4. Flash kills battery life.
5. Flash doesn’t support touch.
6. Flash is cross-platform so does not lead to the best experience on Apple.

Today we can see the following:

1. No one thinks Apple is open.
2. Most features of Flash are now available through other means.
3. Insecurity is often mentioned in connection with Flash.
4. There is not much talk about Flash and battery life.
5. There is not much talk about Flash and touch interfaces.
6. No one talks about Flash as a cross-platform technology, except for those who are sad because they want to use cross-platform technologies.

That is, most of the reasons that Jobs gave don’t seem to be important at all. Only (2) and (3) have relevance today. And (2) is a direct consequence of the most important fact, that Jobs would not allow Flash on iPhones. iPhones are too large a market to ignore, so people reimplemented everything important from Flash by other means.

As for (3), the insecurity of Flash, the reason we still hear about it is that Jobs was throwing a bunch of reasons at the wall and this is the only one that stuck. In other words, Jobs made a decision, this letter was his attempt to create a narrative to support it, and security was the part of the narrative that had resonance. Security became the narrative.

Perhaps this seems cynical—facts don’t matter!—but actually I find it hopeful. If there is a narrative to kill Flash, perhaps there is a narrative to do something about a far worthier target, C.

A narrative against the use of C

The goal, then, is to develop a narrative that stops people from using C for most projects. Note that I don’t seek to kill C, in the way that Jobs is killing Flash; that’s impossible for legacy reasons, and, moreover, it would not be an effective narrative. Programmers are irrationally attached to their favorite programming languages, and C is beloved by many. I like it myself. Calling for the death of C would not be productive.

The fact that writing programs in C/C++ leads to insecure programs can serve as a core of the narrative, since that’s supported by the data and by (most of?) the security community. We are still missing the driver of the narrative: a powerful figure, like Jobs, who can force the issue.

That figure should be the government, and in particular, the military. The US government says that they are constantly under “cyber assault,” and they are spending billions of dollars in response—$13 billion in 2015. There is a very good case to be made that the cheapest and most effective single thing we can do to improve military and government systems is to implement them in safe programming languages.

This is a much better goal than trying to convince C programmers to switch from their favorite language. If the government, one of their largest customers, indicates a preference for safe languages, then inevitably the market will follow.