Mobile apps need clear copy, not a privacy summit

It's great that mobile app makers are waking up to the trouble of "sharing" everything in opt-out fashion. But a few words would make all the difference.

If you haven’t heard about Path, it’s probably because none of your friends uploaded your name, email address, and phone number to their servers yet.

Path is a mobile app for iPhone and Android that acts as a valet service for all your social network transactions. From one stylish, flowing app, you can share a photo, a thought, or a link through Twitter, Facebook, Foursquare, or Instagram, or you can share it to only your close friends you’ve connected with through Path itself. Like most social-minded apps, Path can scan your address book and find connected friends.

Unlike most apps, or at least the way most apps claim to work, Path, until recently, automatically uploaded your address book and all the people in it to Path’s servers, without really stating that it was explicitly doing so. That behavior was noticed by a developer trying to craft a related Mac app for Path, and Path rather quickly apologized in a blog post, wiped all the data it had collected, and sent out an iOS update that now asks users to opt in or out of having their address book sent over for analysis and friend-finding.

That would be a case study in decent mobile app response, but it turns out Path isn’t an isolated case. Hipster, which creates digital postcards from your photos and shares where you are, also sends your address book along, or it did, until Hipster’s CEO apologized and forced an app update, which we can now call “Pulling a Path.”

The interesting thing is that Hipster also called for an “Application Privacy Summit” to “discuss … user privacy in mobile applications.” Not a bad idea, but here’s the thing: couldn’t you have made it clear what the app was doing in the first place?

iPhone and iPad apps are submitted and downloaded through Apple’s App Store, where, presumably, Apple’s staff is checking that everything is kosher. That doesn’t always happen. Android apps are submitted in much freer fashion, but the Android development kit and Market check to see what aspects of a device the app asks for in its code--location, the camera, your contacts, and so on--and should make it clear when you’re installing the app that it has access. But there’s both a Boy Who Cried Wolf problem, due to the huge list of “demands” every popular app makes, and a few cases niche cases where apps have used Google’s generalized language to slip in some tricky stuff. It’s similar to the problem with software agreements--too long, too complex, and so too often ignored.

It’s an obsession of mobile apps to move as quickly as possible thorugh signing in, starting up, and getting to the first screen where somebody gets to actually do something. It’s why signing in via Facebook or Twitter or a Google account have become almost a default option. What those big firms do with your data is whole other matter.

But here’s the easiest solution to the problem of apps assuming users are okay with, say, having their entire address book uploaded: tell them exactly what you’re doing. Do it in crisp, mid-century Swedish typography that drops down from the top of the screen. Do it with cute stick figure illustrations that show you don’t take yourself too seriously, even if you have $10 million in venture funding and should totally take your business a bit seriously. Just write to the person with the phone, “Can we grab a copy of your address book to check for other HappyApp friends? Only our server programs see your book, and we’ll delete it after 90 days.” Or ask if it’s okay that the app sends your photos to their servers for compression before sharing them.

You’re selling your app to people, even if it’s something that’s nominally free. If you can’t ask them for something with a straight face, than you’re not really selling, you’re marketing. There’s a notable difference.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies