Years ago, in the Dark Ages of desktop software, security was an option. People used software that was insecure by default, but if they knew where to look they could turn on various options that made the software secure.
Microsoft Outlook used to be like that: by default it would allow viruses to be emailed to you, but you could configure it to be secure if you knew where the security options were.
Then people started getting all sorts of nasty viruses via email, and Microsoft wised up. They stopped treating security as opt-in and started making their software secure by default.
Fast forward to today and we're seeing a similar situation with privacy.
By default most social software isn't private - it's configured to share everything about you, not just with people you know but also with advertisers. You have to figure out where the privacy settings are - and what they mean - if you want the software to respect your privacy.
And as with the opt-in security settings of the past, today's opt-in privacy settings are leading to all sorts of problems. Every day we see headlines about privacy violations that could've been avoided if we used software that didn't treat privacy as an option.
Software developers need to look at privacy the same way we've learned to look at security: it's not an add-on or a feature that customers have to turn on, it's something built-in that shouldn't be turned off.
I write the Android version of Glassboard, an app designed for private conversations. Find out more at glassboard.com.
There's a big difference between the lack of building security features in your app and explicitly building features that for example steal your information from your address book.
Difference is that developers didn't care about security until it became a problem for their bottom line, now developers care a lot about the lack of privacy because it is their bottom line.
Posted by: Chuck | Tuesday, April 03, 2012 at 04:28 PM