How do we make bigger better?

You’ve probably heard of Alan Kay, the principal designer of the object-oriented language Smalltalk. The original Smalltalk implementation was written by Dan Ingalls – allegedly to settle a bet that only a single page of code would be needed to implement the language [1].

How times have changed! I know I’m being slightly unfair here, proverbially comparing apples with oranges (though in practice they compare quite well [2]), but the current Linux kernel sources consist of some 35,000 files totalling over 400MB in size.

I’d love to tell you how many lines of source code that is, and on any Unix-like system that should be easy:

$ wc $(find . -type f -print)

Use ‘find’ to enumerate a list of all the files in the Linux source tree. Pass that list to ‘wc’, counting the words and lines in each file and producing a total. With 4GB RAM at my disposal, this should be easy. But it isn’t:

-bash: /usr/bin/wc: Argument list too long

Clearly, bigger is not always better.

Nevertheless, computing seems set on interminable expansion. I don’t mean to criticize anyone in particular, but I need an example, and I’ve chosen Adobe. Its entry-level PDF-reading software Reader, is now a 70MB download which asks for over 400MB of disk space.

More interestingly (at least for a threat researcher), Reader now incorporates runtimes for three different programming languages: PostScript, ActionScript and ECMAScript, more commonly known as JavaScript.

In the interest of objectivity, I’ll admit that anti-malware software is getting larger, too. Sophos Endpoint Security for Windows, for instance, is an 80MB download, expanding to around 110MB of disk space.

However, it’s fair to point out that the overall complexity of products in our industry is, to some extent, determined by the sum of the rest of the parts. We aren’t just trying to protect Adobe Reader from attack, or your browser, or your video player, or your operating system, but all of them.

Since your browser contains a JavaScript engine in which attacks can be played out, we need a reasonably complete analogue of that environment to deliver satisfactory malware prevention. We need an analogue of your CPU and operating system, too. We need to know how to unravel complex files (archives, images, software bundles etc.) in a way that takes into account all the known peccadillos of all the commonly used software that consumes those files.

So, whilst bigger may not always be better, it is clearly always bigger. And bigness begets bigness.

For security, this means that the gap between functionality and security in software and services is likely to remain wide, and will probably widen further.

Even if you embrace the ‘thin client’ model – Google’s ChromeOS project springs to mind, in which the browser is just about the only software on your PC – you won’t be free from bigness. Facebook, for example, which exists only in your browser, is an enormous, new and fruitful stamping ground for cybercrooks.

In short, therefore, education and user awareness are always going to be important. In fact, they are probably the most important aspects of computer security, since they continue to protect us when technology cannot.

In the past year, I’ve heard a number of fellow security researchers writing off user education altogether. I think that’s defeatist, and ultimately self-defeating. If education fails, you can blame the students. But you might equally blame the teachers.

And what about Alan Kay? In 2001, he took the intriguing step of starting an organization to investigate how far you might get in the modern world with just 20,000 lines of code. Have a look for yourself – you might be pleasantly surprised [3].

Latest articles:

Bulletin Archive