Simplicity Ain't So Simple, Part VI: Simple = Secure

If you want to create software that's used by a lot of people, you already know you've got to make it simple. But if you're designing a desktop application which connects to the Internet, you've also got to make it secure.

To some that may seem obvious, but plenty of developers - including myself - have been blindsided by security holes that we should've seen a mile away. All too often we look only at the positive side of the technology we're involved with, failing to see that if we get lucky and our software gains mainstream acceptance, it then becomes a possible point of attack.

Somehow you've got to keep your customers safe without making them feel limited by your security restrictions, and unless your target audience is security experts, you've got to do it in a way that doesn't require a special "security" page in your options dialog that's stuffed with cryptic settings.

Bottom line, if you want to appeal to a mainstream audience, you've got to make your software simple and secure, which is extremely hard to do. How you go about doing that depends on the type of software you're working on, but there are some basic things you can do:

• Don't think of security as a "feature" that you can add later: think about it as part of the foundation of your software. Adding security later may complicate your software, as well as require changing its behavior in ways existing users won't like.
• Don't require customers to do anything extra to make your product secure. If you need to add any security-related settings, make them default to the most secure values possible - and then think about whether you can drop those settings entirely (after all, do you really want to enable customers to make your software less secure?).
• If you have to warn customers when a specific action has a security risk, make sure your warning dialog uses clear, ungeeky language. You can't expect customers to make an educated decision if they have to decipher your jargon.
• Take off your white hat and wear a black one for a while. If you were tasked with exploiting your application, how would you do it? And I don't mean this in an "old school" hack-the-EXE way: I mean how could you exploit existing features to make customers susceptible to phishing, XSS attacks, etc.
• Always, always, always think about how spam could affect the technology that your software relies upon. Anything that requires showing end users information from the Internet is susceptible to spam-like behavior, even if nobody is doing it yet.
• If your software connects to the Internet, don't read this list and think it doesn't apply to you. It does.

Making your software secure is your job, not your customers'. So don't let securing your software complicate their lives - make it simple for them (and yourself) by baking security into your application from day one, and do it in way that doesn't require them to keep a technical manual by their side.

Comments

[Dan]

Hi Nick,

How about some examples?

Thanks!

[Nick Bradbury]

Dan, I think FeedDemon's security features are an good example. If a feed contains scripting code, you don't have to do anything to prevent it from accessing your local system - FeedDemon simply prevents it from executing. In other words, nothing is required from the end user to make FeedDemon secure.

If you're interested in details on how this works, check out http://nick.typepad.com/blog/2006/09/feed_security_a.html