Chris Dixon

Some thoughts on the iPhone contact list controversy and app security

1. I’ve heard rumors that lots of apps have been uploading user contact lists for years. One person who knows the iOS world well told me “if you download a lot of apps, your contact list is on 50 servers right now.” I don’t understand why Apple doesn’t have a permission dialog box for this (that said, I’m not sure that’s the best solution – see #4 below). Apple has dialogs for accessing location and for enabling push notifications. Accessing users’ contact lists seems like an obvious thing to ask permission for.

2. I don’t know what the product design motivations are for uploading contacts, but I assume there are legitimate ones. [commenters suggest it is mainly to notify users when their friends join the service].  If this or something similar is the goal, you could probably do it in a way that protects privacy by (convergently?) encrypting the phone numbers on the client side (I’m assuming the useful info is the phone numbers and not the names associated with the phone numbers since the names would be inconsistent across users).

3. Many commentators have suggested that a primary security risk is the fact that the data is transmitted in plain text. Encrypting over the wire is always a good idea but in reality “man-in-the-middle” attacks are extremely rare. I would worry primarily about the far more common cases of 1) someone (insider or outsider) stealing in the company’s database, 2) a government subpoena for the company’s database. The best protection against these risks is encrypting the data in such a way that hackers and the company itself can’t unencrypt it (or to not send the data to the servers in the first place).

A bad outcome from this controversy would be to have companies encrypt sensitive data over the network and then not encrypt it on their servers (the simplest way to do this is to switch to https, a technology that is much more about security theater than security reality). This would make it impossible for 3rd parties (e.g. white-hat hackers) to detect that sensitive data is being sent over the network but would keep the data vulnerable to server side breaches / subpeonas. Unless Apple or someone else steps in, I worry that this is what apps will do next. It is the quickest way to preserve product features and minimize PR risk.

4. I worry that by just adding tons of permission dialogs we are going back to the Microsoft IE/Active X model of security. With lots of permission popups, users get fatigued and confused and just end up clicking “Yes” to everything. And then the security model says: If the user says “yes”, and the app uses “best practices” like https, it can do whatever it wants. We saw how this played out with the spyware/adware epidemic on the web from 2001-2006 and it wasn’t pretty.

 

  • http://www.twitter.com/gcsf Gary Chou

    Perhaps what we need is a version of the Hippocratic Oath for Engineers.

    • http://www.facebook.com/nbonaddio Nik Bønaddio

      There are too many cases of profitably being unethical for that to reasonably work, sadly.

      • http://www.twitter.com/gcsf Gary Chou

        Dare to dream, Nik! Dare. to. dream. :)

        • http://www.facebook.com/nbonaddio Nik Bønaddio

          Going well so far, my friend. When are you coming by our new offices for lunch?

  • http://graysky.org Mike Champion

    I thought for #2 it was so that they could more easily do the “Your friend Steve just joined” push notifications.

    • http://www.cdixon.org chris dixon

      Yeah, that makes sense. I was also trying to guess about the more general case since this seems to be widespread practice.

      • http://mikelewis.me pescatello

        Yep, the only way to let people know if one of your friends have joined is to know who your friends are and have that stores. This is incredibly common

  • http://www.kidmercuryblog.com kidmercury

    iphone platform governance isn’t good enough. no one has good enough platform governance, although i think amazon is going to be the best of the worst, at least according to my personal preferences. the only way platform governance can be improved is if there is a greater focus on niche models, not the one world approach of amazon, apple, google, facebook, twitter, etc. platforms with no focus on customer segmentation are vulnerable to niche platforms focused on a specific customer type. 

  • http://MeetInnovators.com Adrian Bye

    how about they don’t get to access our contact list.

    this is just like tell-a-friend viral invites from ~2004

    • http://www.cdixon.org chris dixon

      seems like a legitimate request especially for a communications app. do you want the apple Phone app to have access to contacts? do you want 3rd parties to be able to compete with Phone?

      • http://MeetInnovators.com Adrian Bye

        apple phone app doesn’t need to upload my contact list to a server

        • http://www.cdixon.org chris dixon

          agreed. but from a security point of view it is impossible to know if an app is uploading contacts if they encrypt it over the network. hence if you want to protect contact lists at the OS level, you need to do it by blocking access.

          • http://MeetInnovators.com Adrian Bye

            true.  but with the effort apple goes to prevent the iphone from being jailbroken it would seem they could protect our contact data a little better.

            at any rate, i use whatsapp and i like it and its only useful because they scan my contacts list.

  • http://twitter.com/Alternate1985 Nick Mango

    Kik became hugely successful using this trick. Apologize later. You do what you gotta do. You’re not taking the info and using it maliciously, you’re doing it to grow faster.

    Peter Cooper was on Founders Talk the other week and talked about when he started ruby weekly, he launched with #4. Sneaky stuff. I personally have no problem with that, cause I’ve done things like this before. I actually have a lot of respect for people who do risky things like this. But users are different. When you’ve never had to get the ball rolling on a venture, you tend to fly off the handle on stuff like this. Obviously the Peter Cooper situation is different than the contact list stealing, but it’s along the same lines. 

    Here’s that interview with Peter Cooper. http://5by5.tv/founderstalk/30 

  • Greg Hao

    The problem here seems to be (as concerning #4), if we’re going to keep anything private (or force user acknowledgement), it would be their most private information on their phone, eg their contact information.

    So, if AAPL already forces apps to seek permission and display pop ups, then this is the most basic one?

  • http://www.facebook.com/scoraymond Scott Raymond

    Re #3, Path (and other apps I know of that were doing this) have never had this problem — they always uploaded the address book over HTTPS. Of course, you’re right that this doesn’t matter too much; it mostly makes bad-behaving apps harder to detect.

    IMHO, a good compromise would be for iOS to provide something like SHA1(app_id, email) for each contact — that way, apps could provide low-friction friend-matching, with far less potential for abuse.

  • http://pulse.yahoo.com/_PPN3OZY3PSAT6IFPI3EKT4S63Y Samuel

    What they need, IMHO, is to add badges to the app store.  ”This app uses location”, “This app displays ads”, “This app contains in-app purchases”, “This app accesses the address book”.  That way people know before they buy, and the permissions can be put right into the sandbox and protected via the signing process.

  • http://twitter.com/echoecho echoecho

    hey Chris – there’s a pretty significant problem with #2 that many commenters (including the dude talking to Dave originally) missed. IF you want to scale your business internationally – just hashing locally on the device and then comparing the hashes server side will not work…unless you duplicate international number cleaning on every client.

    By number cleaning I mean the process of converting 07832 555121 (in say a UK user’s address book) to +44 7832 555121

    The US version of this problem are the differences between +1 212 555 1212 and 212 555 12121 or even 001 212 555 1212

    To use WhatsApp as an example – clearly the main aim of duplicating the database is exactly what you and some commenters have already identified – telling you that one of your friends just joined ….(and simultaneously telling them)

    What companies like WhatsApp do is quite a bit more intrusive than just using this information for spamming any new friend with a “hello” request – is the fact that they’ll say stuff like “Last use by Jonathan yesterday at 6pm.” – even if that communication at 6pm was NOT with you.

    In other certain aspects of personal data and behaviour get communicated with no questons asked.

    You are completely correct that ALL you need to compare is a phone number – and in point of fact you don’t really need to store it. You just need to compare it every so often – so there are clearly better and more elegant ways to organise this than the

    Spam.
    Apologise. 
    Ask user for permission to spam – and assume user will agree.
    Rinse and repeat…

  • http://almaer.com dalmaer

    Someone needs to solve the issue of privacy without popups. When I was at Mozilla there was a fair amount of work, including clearing up the communication side of things (having CC like iconography for privacy).

    There are a couple of different use cases for getting access to something.

    a) needed for the app to work: e.g. an address book manager without access to your contacts isn’t good. for this, you may as well ask on install.

    b) minor side benefit: e.g. there is a form on some help page where it would be nice for the user to select their contact. not needed for the app to work at all. for this, asking for the permission at install is AWFUL (note: this is why Android’s model sucks so bad). I have run into this myself. We came up with a nice way to select the users contact when sending them a product. Typing on a mobile device sucks, so instead, select from the list and you are done. A good system wouldn’t even ask for a permission here (at either install or when it happens) as the user is giving a clear message by tapping on a button that says “select from contact list”. We had to turn this off on our Android app because people were scared and wondering “erm, why do you need my contacts???”

    There is much room for improvement here!

    • http://profiles.google.com/hackbod Dianne Hackborn

      Android already lets you bring up a dialog for the use to select a contact, returning it to the app with a temporary permission to access that one contact item, without the app needing general contact reading permissions.  It turns out this is not used much.  I think there are a number of reasons — we haven’t done a good job advocating it to developers, it is just easier for developers to get the contact permissions and direct access contacts as needed, and this UI isn’t sufficient for a lot of cases (such as auto-filling contacts in the “to:” field of an e-mail message).  For the last point, we’d definitely like to provide a better mechanism, but having a more deeply integrated UI into the application that still securely protects the contacts is pretty tricky.

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | TechCrunch

  • Pingback: Some thoughts on the iPhone contact list controversy and app security — nPost

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Kantier

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Champlin News | Champlin Local News

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Vadnais Heights News

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Robbinsdale News

  • Pingback: iPhoneNation.com: Apple News and Technology Insiders – “We’re So So Sorry”: An Apology Form Letter For Startups

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups « Go Digital Apps

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Minnetonka News

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | New Brighton News

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups |

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | iyaan.info

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | PRO-BTC

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | TechDiem.com

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Bitmag

  • http://valwriting.net/term_paper term papers

    Great Great!!!

  • http://www.facebook.com/itsDavidAbraham David Abraham

    The Address book read feature needs to be removed and blocked period.

  • Pingback: “We’re So So Sorry”: An Apology Form Letter For Startups | Startup Help

  • Pingback: Social apps & doing the right thing — Tech News and Analysis

  • http://twitter.com/aliix Alex Neth

    “https, a technology that is much more about security theater than security reality”

    That is not true. I’m assuming someone told you that transmitting data securely (which is what https does) is only part of the solution, but https is not “security theater.”

    It is nearly impossible for a hacker to intercept your credit cards, and in this case address book, in transmission because of https. Without https, it would be quite easy for hacker with access to your network or any node in between you and the destination to get that data. So https is actually extremely important and effective for data in transmission, when it is most vulnerable due to the number of unknown and uncontrolled places it passes through.

    What’s true is that storing data encrypted is also important, however I would say that is far less important – it is much easier to get access to the transmission than to the storage. Further, encrypting data does no good if the encryption keys are not secure, and the server application will need access to those keys. Anyone who gains access to the application server will not be far away from accessing any encrypted data which the application can access.

    As for solving #4, we need a single easily accessible permissions page for each application where users can enable or disable each permission and clear indication of what permissions are granted and when they are used.

    • http://www.cdixon.org chris dixon

      I say it is theater not because I don’t think network communications should be encrypted (I state explicitly they should), but because the way SSL has been marketed has led users to think if they see the green lock in their browser the website is safe. In fact the website can be run by bad people, have a terrible privacy policy, do bad things to users’ data, computers etc. Overcoming this false sense of safety was one of the biggest challenges we had when we were fighting spyware/adware at SiteAdvisor and then at McAfee (which acquired SiteAdvisor).

  • Pingback: Mobile Address Book—Much Heat, Little Light | TechCrunch

  • Pingback: Mobile Address Book—Much Heat, Little Light | Montevideo News

  • http://biggovernment.com/author/mwarstler/ Morgan Warstler

    Chris, isn’t it easier to just:  1) ask if you want your email findable?  2) routinely ask user if they want to check list of findable for new friends. 3) purge immediately. 4) grow user base / user experience slower.  I mean Skype would have grown faster if it did it the Path way. What’s wrong with slower?  Doesn’t it force start ups to work harder to create value?

    • http://www.cdixon.org chris dixon

      I think that’s probably preferable, but it should be enforced by Apple.

  • Pingback: Mobile Address Book—Much Heat, Little Light | Новости мобильных технологий

  • Pingback: iPhone Games » Mobile Address Book—Much Heat, Little Light

  • Pingback: Mobile Address Book—Much Heat, Little Light | PRO-BTC

  • Pingback: Mobile Address Book—Much Heat, Little Light | | AdWords WhizAdWords Whiz

  • Pingback: Mobile Address Book—Much Heat, Little Light - The Review Blog

  • Anonymous

    I stumbled onto you blog after searching for “iPhone contact list security.”  

    I receive my share of phishing phone calls (who does’t?), but it just dawned on me that the spoofed caller ID numbers I’ve seen for the past year are all from the relatively limited number of area codes found in my contact list.

    I almost never agree to location services for iPhone apps (google maps is the exception).  I never agree to app requests such as FB that want me to share my info, contacts or otherwise.  And the contact list is on my iPhone only, not my laptop (except in the iPhone backup).

    I’d love to know who I should blame for the apparent breach of my contact list.

    • http://www.cdixon.org chris dixon

      I guess Apple and app makers.

  • Pingback: Mobile Address Book—Much Heat, Little Light | NokiaBattery

  • Pingback: Mobile Address Book—Much Heat, Little Light | Startup Help

  • Pingback: Mobile Address Book—Much Heat, Little Light | iyaan.info

  • Pingback: Mobile Address Book—Much Heat, Little Light | Digital Gadget dan Selular

  • Pingback: Social apps & doing the right thing | Freeex Blog

  • http://precisionsignz.com/ political campaign signs

    The information was really awaited for me since inception of google plus. Today I will set the button on my business website

  • Pingback: Apps uploading address books is a privacy side-show compared to DPI

  • Pingback: Controversy, journalism, disclosures and the future of web content - KyleLibra.com

  • Pingback: Apps Uploading Address Books Is A Privacy Side-Show Compared To DPI | iyaan.info

  • Pingback: Apps Uploading Address Books Is A Privacy Side-Show Compared To DPI - SocialEnterprise.com Beta

  • Pingback: Inside the iPhone Contact List Scandal | Startups