iOS 6 wants: Granular privacy control
Like with Notification Center, Apple should look to and improve on what Google's done with Android to better keep our Contacts safe.
Earlier this week the internet got itself into a kerfuffle over Path, a small-circle social networking app for the iPhone, which took Contact information without asking and openly transmitted it to Path's servers. It's an important issue to be sure, one worth getting into a kerfuffle over, and Path eventually apologized and vowed to make changes. But Path was only one of many, many apps to act this way.
A couple of years ago there was a similar kerfuffle over Dragon Dictation when Nuance was transmitting Contact information to their servers as well. Nuance did this, it turns out, so that its server-side voice recognition services could better understand the names of your friends and family.
Path, it turns out, did this so it could notify you if your friends and family were already using, or started using, their service and offer to connect you in the app as well. (Though the "open transmission" part was concerning -- hashing or otherwise encrypting the data between iPhone and server would have been a good idea.)
It could have been any of a number of other apps in Path's place, however, if they'd been discovered first. Many of them are now updating, adding security if they weren't already, and custom-making request popups for user permission before transmitting Contact information. And that's a good thing. But it exposes a problem with the way Apple currently handles user privacy on the iPhone.
If an app, any app, even a built-in Apple app, wants to know your location, it has to ask for permission. If it wants to send you Push Notifications, it has to ask for permission. If it wants to access Twitter integration, it has to ask for permission. If it wants access to any of your personal information, however, like Contacts, it doesn't have to ask at all.
Apple should change that, of course. They should require that apps ask permission to access Contacts -- and Calendars, and any other personal data -- and insist any information be transferred in a secure manner, and never be stored permanently on a developer's servers.
Just like with Push Notifications back before iOS 5, however, their popup requester system doesn't scale. Right now, if you launch a new Twitter app for the first time and you get popup after popup, asking you to tap to approve Twitter account access, location, and Push Notification. Imagine when Contact access, Calendar access, and conceivably other information is added to the list. As the number of popups grow, the likelihood that a user will read and consider each one falls precipitously. They'll just start tapping through to get to their app.
Master your iPhone in minutes
iMore offers spot-on advice and guidance from our team of experts, with decades of Apple device experience to lean on. Learn more with iMore!
There's a school of thought that says inattentive users deserve what they get -- if they don't read, they abdicate their right to complain later. Apple doesn't usually subscribe to that school of thought, however. That's probably why they've kept permission requesters to a minimum for now.
Just like with Push Notifications, however, a better solution exists outside popups, and Android could once again be drawn upon for inspiration.
When you browse an app on the Android Market, whether via the web or in the Market app proper, there's a clearly defined place see what permissions that app will require. Arguably, Android presents way too many permissions and users might not bother to read them any more than they would a popup, but having them there as a permanent reference is invaluable.
for iOS 6, Apple could do what they did with Notification Center in iOS 5, remove the cumbersome nature of popups, simplify Android's implementation, and, when an app launches, present a simple sheet of toggles allowing a user to pick and choose which ones they're willing to grant access to.
Things like storage access are more noise than information, but Contacts and other areas that touch on personal information should absolutely be there.
Likewise, the permissions sheet could be kept available in the settings for the app (or in the general Settings.app), so users could easily change them at any time. Under special circumstances, if a service is absolutely required for an app to work -- for example, location is required for a photo editing app to access potentially geo-tagged photos in the Camera Roll -- then a popup could be generated explaining the situation.
Adding a list of permissions each app requires to the App Store, on device, in iTunes, and on the web would be a nice-to-have as well.
Path deserved the push-back they got for doing what they did with Contacts, but Apple deserves push-back for letting them do it in the first place.
Apple has shown a relentless drive to tackle the rough edges of iOS in recent releases, and as iPhones and iPads become more powerful and apps more sophisticated, privacy becomes one of the rough edges they need to get a handle on quickly.
They've used Privacy as a differentiator from the competition in the past, and Notifications and Location Services in iOS 5 are a huge leap forward when it comes to granularity and usability. Hopefully Apple brings it all together, and gathers up the loose ends like Contacts, in iOS 6.
Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.