Suppose that when you started your car today, it displayed a question on the dashboard: “Should I advance the timing by 4 degrees?” The car wouldn’t go until you responded. What would you think?
What if you were having a house built, and the builder sent you a text message: “Should we put your floor joists 16 inches on center? I need an answer immediately, or my workers are going to another job.” Would you know how to respond, without asking any questions back and risking losing the day?
How about if you tried to visit a web site, and your browser responded with a popup that said, “There’s a problem with the site’s certificate. Should I accept it anyway?”
Oh, you say that last one happened to you just this morning... or yesterday, or last week? Indeed. It’s happened to us all, many times. So many times that we just say, “Yeah, yeah, yeah,” and we click “Accept” without really thinking.
But why on Earth are we programming these things this way? Why do our computers persist in asking questions that 99-point-some-number-of-nines percent of the users have no hope of understanding, much less answering correctly?
“What should I do with this certificate?”
“Program XYZ wants to access the Internet on port 3271. Should I let it?”
“There was an error reading the preferences for this program. What should I do?”
We should never ask a user a question that most users are not qualified to answer.
No one would program a car or a toaster or a microwave oven to ask such questions. No builder or plumber or doctor would ask such questions without sitting down with you and explaining the options and the reasons. Why do we accept this stuff from our computers?
It’s because, however familiar we’ve become with computers, they are still mysterious things that work by some kind of magic, and magic words and mumbo-jumbo are still thought of as part of how they operate.
We have to make that unacceptable. We’re at a point where we ask the users a million questions, and the “correct” answer is almost always “yes”. But the consequences of saying “yes” when it’s the wrong answer are serious: your computer gets infected with a virus, you wind up on the wrong web site, your account number and password get stolen.
We need to get to the point where we ask the users very few questions, and the correct answer is almost always “no”. We teach people that, and get them used to saying “no” if they aren’t sure what to do. And then the system fails safe: the consequences of saying “no” when it’s the wrong answer are that you remain secure.
After that, we stop asking the questions altogether. Sure, some people will want to put their computers into “expert mode” and continue to get the questions, continue to make the decisions for themselves. But most people, that 99-point-some-number-of-nines percent of the users, will have safer, more secure computers, because they won’t be trained to say, “Yeah, yeah, yeah,” and to click “Accept” without having any idea what they’re accepting.
We should never ask a user a question that most users are not qualified to answer.
Corollary: Every security-related question is in that category.
4 comments:
I think it should be an option ... maybe not the default, but I like seeing those alerts!
And then the question is, if you don't ask the question, what do you do? If you disallow 100% of the time you break things that actually didn't matter (like when the local hotel uses SSL to ask me to accept its wifi license, big whoop!)
The point is that it does matter, in that it's all part of what's trying to keep the system secure. If the hotel uses SSL/TLS for the license page, and uses a self-signed or expired certificate on that page, it's contributing to the problem of insecurity.
What will happen if the browsers stop accepting this stuff is that people will complain to the hotel, and the hotel (or its provider) will fix the problem, either by using proper certificates or not using encryption where it isn't needed.
Similarly elsewhere: it will be annoying at first, as things stop working, but it will force the offenders to fix things. We can mitigate the annoyance by giving sufficient notice before we release the new software (and, of course, there'll be a long startup curve anyway, before enough people have the new software).
I'm with you 100%, Barry. Usability is a huge issue; one that isn't on the radars of a lot of designers and developers.
A perfect illustration of what you're talking about could be seen back when I was working I.T. at a previous job. On more than one occasion a user would complain about something not working, so I would go to his or her work station and ask the user show me what he or she was trying to do. As soon as a dialogue window would appear, the user would simply click on "yes" or "O.K." before either they or I could actually read what it said. "Wait," I would tell the user, "I need to see that to know what the problem is." They would usually reply, "oh," as if that thought hadn't occurred to them. All the user saw was some jargon they didn't understand getting in the way of their ultimate goal, and they didn't want to "cancel' what they were doing, so they would simply click "O.K."
Anyone in a position to create user interface of any kind should study usability (or at least read Steve Krug's excellent book Don't Make Me Think).
This is a really hard area, which is why "HCISEC" (human computer interaction in security) is such a booming area. It's so hard, in fact, that I think some of the criticisms of common program behavior are a bit unfair.
Unlike a doctor or a plumber, a programmer won't be there in person to discuss problems when they occur. And unlike a car or a microwave, a computer is a vastly complex device with an almost infinite number of possible situations that can arise, so that it's impossible for the programmer to fully anticipate them all. So I think it's important to start with the recognition that these dialog boxes don't arise because programmers are idiots -- though sometimes they are -- but rather because the underlying problems are really complicated.
I'm not convinced that all of these situations are even solvable. However, I do think that the dialog boxes could be much more helpful in terms of steering people the right way: "The signature for XXX doesn't match. This might mean you're looking at a forgery, but if you're at the right web domain it probably means that the site is misconfigured. You probably shouldn't click on "OK" if you aren't at a familiar site or if you are dealing with particularly sensitive material (e.g. personal finances or health information)."
In other words, we might be able to make more progress in clarifying these dialogs than in eliminating them entirely, and both avenues are probably worth pursuing.
Post a Comment