The controversy that erupted when it was discovered that the social network Path was accessing and uploading iPhone users' contact databases without permission has served to publicize the fact that many other iOS apps are accessing user data in a similar fashion. Concerns over user privacy have prompted US Congressmen to press Apple on the issue, but developers tell Ars that the problem could largely be fixed by Apple itself.

Path used an API provided by Apple that allows developers to access all the data in a user's contact list, including name, address, telephone number, e-mail address, and more. Path used this information to automatically connect users with their friends already using its iOS app. Unfortunately, Path was accessing that information without first asking the user for permission, a specific no-no according to Apple's developer guidelines. Worse still, Path was storing this information on its servers without encryption, which presents an additional level of unnecessary security risk.

Path immediately apologized and modified its app to ask for user permission before uploading the contact database, and changed its policies so that user data isn't permanently stored. But developers have discovered that many social networking apps access this same database in a similar way, and have begun to speak out about it.

Tapbots developer Paul Haddad, who tested a range of popular iOS apps himself, says that the apps for Foursquare, Instagram, Facebook, Twitter, and Voxer send some or all of a user's address book data back to their respective servers. Google+, Apple's own Find My Friends, Skype, Yahoo Messenger, Quora, Textfree, and AIM, on the other hand, do not.

The Verge did its own testing and discovered other apps that access and send a user's contact data to their servers, including LinkedIn, Gowalla, Foodspotting, Angry Birds, and Cut the Rope. The worst offender, however, is Hipster—the app not only uploads contact information without user notification, but does so without any kind of secure connection at all.

(Ironically, a University of California at Santa Barbara study last year showed that jailbreak apps access user data far less frequently than Apple-approved apps in the App Store.)

Haddad told Ars that all the apps he tested now alert users that their information will be accessed and sent back to home servers, and that all the information is being sent using SSL encryption. However, none of the information is hashed, opening up the potential for the traffic to be intercepted and used by hackers. Furthermore, that information may be stored on servers that could be compromised and the information stolen.

"I bet many users would say that their address book is more sensitive than their location," Stand Alone developer Patrick McCarron told Ars. "So I can see wanting to know when an application accesses it. A developer hiding the fact that they transmit your address book data in a privacy policy or EULA is not something I'd call a customer friendly practice."

Apple has now implied publicly that it will modify the APIs to require explicit user permission for access to the contact list. Though the change will ensure that users are aware that contact information is being accessed, it does nothing to address the concerns of exactly which data is being accessed, or what happens to it after it is sent to third-party servers.

"When these apps say 'contact data,' do they mean just e-mails? Or everything, including mailing addresses?" Haddad asked. "How long is that data being used for and what's the purpose?"

Better security through better user experience

Developers certainly deserve some of the blame for the current blowup, both for not communicating with users and not being more careful with user data. However, Apple put the onus on itself to police developers and make sure they adhere to Apple's guidelines. The real fix, developers said, will have to come from Apple; they argue the company should require that certain sensitive data be hashed before transmitting and overhaul iOS's permissions system.

For instance, a modified contact API "could provide the same information as the existing API call, except it would provide salted and hashed fields so that developers can use those to match other users of that app," McCarron said.

(A hash function is a series of mathematical operations that transforms data into a unique though seemingly random number called a hash. In other words, a suitable function might turn the name "John Doe" into "987634A65F45665DDA." The important concept here is that any unique combination of input to the function will produce a unique hash.)

Instead of needing to transmit or store the entirety of a user's contact database, an app would simply need to maintain a unique hash based on contact information for each user. "I would know that the same data results in the same hash for anyone else using my app," McCarron added.

To further protect the data, each app could be required to provide its own "salt," a random number used by the hash function, so that each app generates its own set of unique hashes for a given input. That way, there would be little chance that different developers could share data and correlate any details to a specific user.

Even with Apple's proposed required notification fix, combined with the hashing that developers suggest, managing an app's permissions will quickly become a problem for the user.

"Depending on what features developers use, an app can end up showing multiple warnings on launch, and that's really annoying from a user perspective," Haddad told Ars. "Currently there's alerts for accessing Twitter accounts, Location, and Push Notifications. If you add in Contacts and use the current setup, users might end up launching an app where they would have to accept four different alert panels before they could start using it. It just doesn't scale well."

Stand Alone's Chris Cieslak agrees. "At this point, Apple’s going to have to revamp permissions dialogs like they had to for notifications in iOS 5," he said.

How exactly Apple might do so is anyone's guess, but Tapbots' Haddad has an idea. "I think a better scenario would be a single alert shown right before any of those particular features are needed, Haddad said. That's similar to what Android does today; users are presented with a list of special permission an app requires on install, and you can choose to accept all of them or not install the app at all.

Haddad's idea has a unique twist, however. In addition to a list of permissions, users would be able to control an app's access to each feature individually. "There's lots of applications that I may want to install, but don't want to let it access my location data," he explained.

Having granular control over what bits of sensitive information an app can access will definitely help users be more aware that their data is being used. That won't help users control how the data is used once access is given, but perhaps it will give them pause to consider whether or not they trust the developer with that information in the first place.