iPhone App Uploads Users' Entire iPhone Address Books

An I've Been Mugged reader alerted me about this. In his blog, Arun Thampi has documented technically how the Path iPhone app uploaded his entire iPhone address book and contact information to its servers without notifying customers nor gaining their permission. Arun's described his experience:

"I was thinking of implementing a Path Mac OS X app... I started to observe the various API calls made to Path’s servers from the iPhone app. It all seemed harmless enough until I observed a POST request to https://api.path.com/3/contacts/add. Upon inspecting closer, I noticed that my entire address book (including full names, emails and phone numbers) was being sent as a plist to Path."

The comments section of the blog post includes a conversation between Arun and Dave Morin, CEO of Path. During the discussion, one user raises the relevant issues and questions:

"1. Why are you uploading the actual address book data, rather than (say) generating hashes of the user's email addresses locally, then uploading just those hashes... 2. Why wasn't this an opt-in situation to begin with? Isn't that against Apple's own T&Cs? 3. How can we have our contact information deleted from your servers, if we wish to do that?

It is good that Morin apologized on behalf of Path. He also wrote in the comment sectionr:

1. This is a good alternative solution which we'll look into. Thanks for the idea. 2. This is currently the industry best practice and the App Store guidelines do not specifically discuss contact information... 3. As I mentioned in the previous answer, we are rolling out this functionality for 2.0.6. In the meantime, if you would like your data deleted from our servers please contact our service team at service@path.com..."

During the discussion, a user cites the relevant sections of the App Store's terms and conditions (Adobe PDF):

"I'd say that 17.1 and 17.2 of the approval guidelines specifically forbids what you are currently doing: 17.1: Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used. 17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected..."

The additional issues I see:

• Almost all of the comments are by people who aren't lawyers. I am sure that a lawyer will weigh in on this soon.
• The opt-out process Morin describe sounded cumbersome to me, as if it was created in haste after the fact. The system default never should have been to auto upload customers' entire phone books.
• It's great that Thampi found this problem. However, one should not have to be a computer programmer or website developer in order to verify that smartphone apps don't violate either the app developer's policies or the app store's policies.
• As social networking and app companies innovate, it is critical for the industry to figure out where the line is between users accepting data collection to enable convenience versus too much data collection. This makes it difficult to impossible to gain trust among users about the safety, security, and reliability of mobile device apps.
• I look forward to reading Apple's response about why it didn't reject the Path iPhone app.

Both C/Net and Wired summarized well the situation. C/Net said:

"Apple, of course, has learned the hard way that it needs to be strict about how iOS apps use, share, and distribute users' private data..."

And Wired said:

In fact, Facebook was caught doing the exact same thing that Path is currently taking heat for, over two years ago."

Comments

[system integration solutions]

very interesting information thanks for sharing

[Jhon Martin]

thanks for posting this informative article i like that.

Facebook Development