The Wonsys Blog

Security in Web applications is obviously critical: you have to think about security right from the start through the whole development process.
You have to make sure your server is secure, which might be more or less daunting depending on the kind of infrastructure you’re building, and you also have to ensure the security of processes inside your applications — is it OK if a user can do this with that data? and what happens if he/she click on that button? –, but there is another kind of security breach which is impossible to plan: user stupidity.

A few days ago, I found a link on Digg: it was titled Man deletes /usr, blames Apple for his mistake!. My first reaction was laughter, but when I read the article I couldn’t believe it.

A guy installed a little app that exposed the /usr folder to him — I think you all know about it, but for those who don’t: it’s a Unix system directory — and he thought: “I already have the /Users directory…I don’t need /usr!,” and deleted it.
Obviously, his Mac started having problems, but what surprised me was that he blamed Apple because he actually had the right to delete it! Basically, he installed two third-party applications — no-ip client and Cocktail –, decided that folder wasn’t useful — notice that /usr contains 10/15 thousand files…all useless, of course — and deleted it by providing his administrator password. Sure enough, it was (in his mind) Apple’s fault!

Now think about Web apps.
You have to provide a way for your users to unsubscribe, so you will probably put a button to do it and it will lead to a page where the user is asked for confirmation, then you’ll probably throw in a JS confirmation box just to make sure and boom the account is gone.
Now, a stupid user might claim you deleted it, and he didn’t know it was for real, you should’ve told him, and so on.
Mind you this is just a stupid example about user stupidity.

Every now and then — luckily enough, for us it’s just a needle in the haystack –, we’ll receive an email from a user who clearly didn’t understand a single thing.
For example, Michele once told me someone had sent an email to 16bugs’s customer support because he was shocked and really upset because he upgraded his account the month before, but didn’t now it was a recurring fee and he actually thought it was a one-off fee, even though it was expressly stated both in the terms of service and on the upgrade page. The user said it was a scam and he threatened reporting it to PayPal.
In the end, Michele managed to explain it to him, still, it’s a clear example of how sometimes users are not that smart.

When developing Web apps you have to focus on your users, you have to try to think like them, trying to figure out what are the most/less intuitive things or what the average Joe would expect from your apps. As easy as it might sound, it’s not!
I often find it difficult to imagine what a user would expect in a page or from a function. Sometimes, I go too deep and think the user needs some features that he/she will never use, while other times the opposite happens. And that is for a very simple reason: when you’re working on an app, you live by it, you breath it, you touch it every single day for hours, so it’s almost impossible to look at it with the eyes of a stranger.

There are two things I can suggest to overcome this situation:

1. launch soon and upgrade often: when you’re in stealth mode, you can’t receive any useful feedback, so launch as soon as possible and make sure you listen to what your users have to say.
2. get away from that app: when you feel like your stuck or don’t know how to solve an issue or implement a feature, just get away from the code for a while; take a day off and make sure you don’t even talk about what you’re doing. The next day you’ll feel the difference.

All of this just to alert you about one thing: users will sometimes use your app in unexpected ways — which sometimes might be a good thing –, but what’s worse is that they will happen to use it in a wrong way and blame you for their errors.

This post was written by Simone D. 2 years, 11 months ago on April 19th, 2007 lunch time.