The last couple of weeks have exposed a couple of high-profile instances of neglectful, or willful, appropriation of users’ personal information by start-ups. The first was by Path. It was revealed that Path was uploading each user’s address book to its servers, in the background, without prior consent. The second was by Hipster. Hipster didn’t store its users’ address book data, but did transmit it (without consent) over a non-secure connection to use for matching with other Hipster profiles.
I’m going to just assume here that neither of these actions were done maliciously, as that would be a whole other discussion. But they do reveal how the perception of “minimum viable product” (MVP) amongst start-ups is sorely lacking with respect to information privacy controls when it comes to getting a first release out the door. If anyone thinks it’s Apple’s responsibility to prevent developer data access from happening, think again. Just like it’s not Microsoft’s responsibility to protect you from every conceivable threat on Windows, it’s up to the developers of mobile applications to behave appropriately on Apple’s platform, and in the best interest of their users.
The core issue is that when many developers and product managers sit down to decide on the ‘features’ for their MVP, they only focus on the features that are directly visible to the end user. Features that relate to technology or design “behind the scenes” are often the first on the list to be cut in order to speed the product to market. The shame of it is that both of these recent instances of misuse of user information could have been mitigated with a couple of simple steps to at least secure the data transmission and formats.
Hipster is hosting a privacy summit tomorrow, and to help, I’ve created a simple user privacy check-list for devs when scoping their MVP.
Everyone developing products should consider at least the following when using or accessing someone’s personal data:
1. Secure the data transmission. At a minimum use HTTPS, which provides SSL security to the transmission. But if you’re not running over an HTTP/HTTPS connection, then encrypt the data so that it’s not simply enough to monitor the data stream coming from a device and read all the information transmitted.
2. Ask yourself if you really need the data itself or just need to match data together? If all you’re doing is matching patterns (like looking for matching email addresses) then you can just hash the actual pieces of user data and match on the hashes. This is actually very easy and simple to do, and Matt Gemmell has a great post about it.
4. If you are storing user information (and do you really NEED to or just WANT to?), how are you storing it and is it secure on your servers? Server security is just as important as the security on the app itself. Servers are the focal point for crackers as there’s way more value in breaking into a repository of personal information than trying to compromise an individual user. There are strict rules for storing credit card info and similar care should be taken for personal data.
If you’re not respecting your users’ personal information, at some point, you will have a negative public relation incident, and the “no press is bad press” saying definitely does not hold true in this case. Just ask Path.