On the delicate art of not sucking


For those who don’t know me, some introduction. I am an IBM usability specialist. I am also a bit of a computer security hobbyist. I am lots of other things besides, but for the purposes of this article, these two are the relevant bits. As a usability specialist, I work on WebSphere Integration Developer, possibly one of IBM’s most usable software products to date, certainly one of the biggest usability challenges since it involves taking Nth-generation IT concepts like services-oriented architecture and loosely-bound component based application design in a J2EE application environment, and making it accessible to business people without programming skills. As a security hobbyist, I have worked (informally and unpaid) with companies like Cisco and FedEx to fix security issues in their apps before some nastier person got ahold of them. I really don’t want this to sound like strutting because it isn’t, there are lots of people in each domain with much more impressive resumes. It’s just an attempt to establish bona fides so that the next thing I say won’t sound totally stupid.

Security and Usability are basically the exact same kind of problem, and you’re probably doing them wrong.

Let me tell you how a software product is developed. First, someone gets ahold of an idea. Maybe they get this from a customer requesting a new product, maybe they get it from a fit of napkin drawing in a pub with friends, but somehow the idea comes together and a project begins. This idea is almost always a function – a solution to a problem, real or imagined. This is natural, of course, you need to be able to answer the question “what does it do?” It’s a very exciting time for programmers, (and if you’re in the corporate world, architects, project managers and other folks) because there is possibility everywhere, and everyone is chomping at the bit to jump in and make the magic happen. So jump they do. People who don’t do it may be surprised to realise that the programming is actually the easy part – very rarely is straight programming-to-create-function difficult; it is time consuming, and it can be challenging and interesting work, but it is not particularly hard. Many projects complete this stage and ship, but some companies (and open source projects) recognize that above and beyond function, there are a set of quality assurance tests that should be met: performance, stability, usability, security, &c. These features are now implemented by getting a usability guy to review the interface and make naming suggestions and organizational changes; or getting a security whiz to add some encryption support; or running a set of tests to gauge performance. With those out of the way the product ships, and most of the time, it sucks. Your users are confused, you’re riddled with security holes. What happened to quality?

The problem is that unlike function, security and usability are hard. Users and customers want them, no doubt, but unlike a new excel annuity function or a “sort by date” option in outlook, they can’t be bolted on, because they aren’t just another feature. Bruce Schneier, security god extraordinaire, talks about how security is a process, not a product. There are a dozen usability gurus that say the same thing about ease of use. You will never improve these things materially at the end of a cycle because it’s too late to make the fundamental changes necessary – sometimes that late in the game you can’t even see what those changes would be. It is at the beginning, and throughout the development process, that progress should be shaped by what the user’s mental model will be, what tasks they will want to perform and how or, in security, what the attacker’s threat model will be, what information and privilege leakages need to be defended against. Do otherwise and you produce half-assed successes at best, and at least as often, dangerous failures.

Some products get this far and figure that since developers are the ones participating in the entire cycle anyhow, the trick is just to get them to commit to “focusing on usability” or making security “a number one priority.” This is also stupid. There’s no such thing as a free lunch, particularly when the thing you’re trying to get for free is the most difficult piece. Developers are smart people, and want to produce quality product, but there are two big reasons they are wrong for the job: they are too close to the code, and they don’t know their history.

Developers are, by definition, close to the code – they wrote it. The problem is that programming is an exercise in understanding and mapping out a problem domain for implementation purposes, and once you’ve done that, it becomes the way you think about the problem. User interfaces in business apps are famous (and IBM’s doubly so) for forgetting what their customers are actually trying to do most of the time, and instead just reflecting the underlying structure of the code. A lot of security holes come from developers thinking in terms of certain protocols being followed and data formats being used because it’s how they do it, and failing to recognize that attackers don’t have to play fair. A great example is voltage based smart card attacks where clever smart card programmers craft excellent programmatic security and are beaten by attackers who supply the wrong voltage to the chip causing all manner of very revealing electronic failures to occur.

History is also a hard thing for developers to track. What do I mean by history? Buffer overflows are a common programming error that can be made in languages without proper memory bounds checking (e.g. C). They are the source of countless new vulnerabilities in new products today, despite the fact that there are easy ways to avoid them which are well publicized. I don’t know when they were first discovered, but the Morris worm used them in 1988, almost 20 years ago, and they weren’t new then. Usability concepts like task flow analysis have been around for decades as well – many even pre-date PCs since a lot of software usability is just a microcosm of human factors engineering and ergonomics which have been on the books longer still. A developer has enough on their plate keeping their skills current and relevant and consuming the new requirements as they emerge and evolve, it is not practical or desireable to add these processes to their plate. This is what usability and security consulting is for. If you want a quality product, at some point you’re going to require smart people whose only job – at all points in the development cycle – is to make your product not suck. This is the reality whether you accept it or not.

I don’t know what it is that attracts me to two such superficially disparate fields with such similar deep characteristics. I don’t even personally find them interesting for the same reasons, but their commonalities are inescapable. And don’t get me wrong, there are people doing things right too – firefox, for example, seems to be taking both of these concepts to heart at a process-not-product level, hiring people dedicated to focus on it, and trying to think things through from the user’s perspective (and I’d say so even if my good buddy Mike wasn’t one of them). If I wasn’t having so much fun where I am now, I’d probably be sniffing around their Toronto offices plenty, to see if they could use another IBM ex-pat. But for the time being I am happy – my developers seem to get it, at least on the usability front, and the success we’re having is pushing other products to get on board too. Give me a while and I’ll get this place turned around.

2 thoughts on “On the delicate art of not sucking

  1. “Bruce Schneier, security god extraordinaire, talks about how security is a process, not a product.”

    I think stating that security is a process just trivializes the whole thing. It’s like saying that security can always be achieved through a series of straightforward steps. It puts the emphasis on the day to day changes instead of the end result, or the ideal that it aims to achieve. A better word is “direction.” Security as a “direction” makes much more sense as it shows an intended ideal and doesn’t pretend to know the best route. The same can be said about usability., Usability isn’t just a series of simple steps that reach a delegated requirement, but is an ever changing goal that we strive to attain.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s