The Best of Intentions
So you’ve built this application. It’s a brilliant application. It’s design
is spectacular, the architecture is flawless, the coding is clean and coherent, and
you even followed the SDL best practices and created a secure application.
There is one minor problem though. The interface is terrible. It’s not
intuitive, and settings are poorly described in the options window. A lot of
people wouldn’t necessarily see this as a security issue, but more of an interaction
bug -- blame the UX people and get on with your day.
Consider this (highly hyperbolic) options window though:
How intuitive is it? Notsomuch, eh? You have to really think about what
it’s asking. Worst of all, there is so much extraneous information there that
is supposed to help you decide.
At first glance I’m going to check it. I see “security” and “enable” in the
text, and naturally assume it’s asking me if I want to make it run securely (lets
say for the sake of argument it speaks the truth), because god knows I’m not going
to read it all the way through the first time.
By the second round through I’ve already assumed I know what it’s asking, read it
fully, get confused, and struggle with what it has to say.
A normal end user will not even get to this point. They’ll check it, and click
save without thinking, because of just that – they don’t want to have to think about
it.
Now, consider this:
Isn’t this more intuitive? Isn’t it easier to look at? But wait, does
it do the same thing? Absolutely. It asks the user if they want to run
a secure application.
The Path to Security Hell
When I first considered what I wanted to say on this topic, I asked myself “how can
this really be classified as a security bug?” After all, it’s the user’s fault
for checking it right?
Well, no. It’s our fault. We developed it securely, we told them they
needed it to be run securely, and we gave them the option to turn off security (again,
hyperbole, but you get the point). It’s okay to let them choose if they want
to run an insecure application, but if we confuse them, if we make it difficult to
understand what the heck is going on, they aren’t actually doing what they want and
we therefore failed at making the application they wanted secure, secure.
It is our problem.
So what?
Most developers I know at the very least will make an attempt to write a secure application.
They check for buffer overflows, SQL Injection, Cross Site Scripting, blah blah blah.
Unfortunately some, myself included, tend to forget that the end users don’t necessarily
know about security, nor care about it. We do like most developers do.
We tell them what we know: “There has been a fatal exception at 0x123FF567!!one! The
index was outside the bounds of the array. We need to destroy the application
threads and process.”
That sounds fairly familiar to most error messages we display to our end users.
Frankly, they don’t care about it. They are just pissed the work they were doing
was just lost.
The funny thing is, we really don’t notice this. When I was building the first
settings window above, I kept reading the text and thinking to myself, it makes perfect
sense. The reason for this is by virtue of the fact that what I wrote is my
logic. I wrote the logic, I wrote the text, I inherently understand what I wrote.
We do this all the time. I do this all the time, and then I get a phone call
from some user saying “wtf does this mean?”, aaaaaaand then I change it to something
a little more friendly. By the 4th or so iteration of this I usually get it
right (or maybe they just get tired of calling?).
So what does this say about us? Well, I’m not sure. I think it’s saying we need to
work on our user interface skills, and as an extension of that, we need to work on
our soft skills – our interpersonal skills. Maybe. Just a thought.
