Teach Security

I read a lot of computer books. Partially this is because I'm a huge nerd. Well, mostly because. Partially it's because I try to keep up with trends and fail mightily. I can't understand how computer professionals do it. Partially (and this is the part I want to talk about) I do it to learn new computer things, mostly programming languages.

So while I am not a self-styled expert on textbook design, I can tell you a few trends I've noticed. Firstly, and this should come as no surprise to anyone, documentation for programs is generally incredibly unhelpful. Sure it's useful if you're interested in the nuts and bolts, but for the beginner, most documentation is lousy. I might address this in its own article. But the trend I want to talk about derives from that trend.

Beginning instructional manuals (I'll use that as a catch-all term for books about the subject, rather than the documentation published by the developers) always seem to be in a rush to get somewhere. Maybe it's Object Orientation. Maybe it's the latest bell or whistle. But whatever it is, these books have to wave their hands and make magical gestures at certain subjects in order to make it to the finish line in time. Most of the time, these goals are laudable; it's hard to teach someone the basics of something and actually give them knowledge they'll be able to use. No one wants to come away from a book with only the ability to regurgitate examples in the text; "Hello World!" is insufficient progress.

So the books must do a certain amount of gloss-over. They gloss over the various complications that can arise. They gloss over more powerful features. Then they gloss over security. And that's unforgivable.

The most one hears on the subject of security, in this day and age of online computing, is, "Security is very important too. Consult the manual." Believe me, security in an online environment is more than very important. It is vital. Like robust error handling (not keeling over and dying at the slightest sign of trouble, for the uninitiated), security cannot be overstressed. And like robust error handling, security gets short shrift.

So by the time a prospective programmer has finished the text, he or she knows how to do many exciting things. He or she then rushes out and does those exciting things and never once considers that these exciting things are gaping flaws. Because the programmers of today are not being trained to think in secure ways, they learn security only later and view it as something which needs to be added once everything else is working, rather than something which should be integrated into an application from the word go. Don't believe me? It can and very well might happen to you. I've found myself in that mindset on more than one occasion. Just like error-handling, security comes late in the process if at all.

We should be training programmers to be secure and robust from the start. Even if they never expect a piece of code to need to be secure, it should be nonetheless. Taking shortcuts leads to tragedy.

Just as one would not teach Object Oriented Design (a design paradigm... oh, look it up) by first teaching the language procedurally (oh, wait, nearly all books do that) so one should not teach a programming language which is intimately connected with insecure situations without teaching such security. I understand that the topic is huge; so are all topics in computer science. If you, the authors and publishers of these books, at least acquaint the reader with the basics, basics which can be used along with all the other basics in the book, then you'll start the students thinking on the right track.