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.

 

Building products from improvised user behaviors

For a long time, there were niche communities of “lo-fi” camera enthusiasts: people who shared photos taken on old cameras that had interesting ways of filtering shots. The iPhone app Hipstamatic popularized lo-fi filters, selling over 1M copies. Because Hipstamatic lacked sharing features, many users took pictures with Hipstamatic and then shared them using other apps. Then came Instagram, which combined lo-fi filters and easy sharing. Instagram has been downloaded 15M times and has apparently crossed over to mainstream users.

Instagram built a product devoted to a job that users were previously performing improvisationally using multiple products. This is a common pattern for popular software and services. Before Twitter, people shared interesting links through email or “link round-up” blog posts. Tumblr’s short-form blogging/re-blogging was inspired by an “unintended” use of long-form blogging platforms like WordPress. Before Foursquare, power socializers sent out mass text messages with their locations (in fact, Foursquare’s predecessor Dodgeball did exactly that).

New startup ideas are all around you, in the improvised behaviors of people you know. It takes a keen product eye, however, to notice these improvisational behaviors and recognize which ones are worthy of being developed into standalone products.

App store shenanigans

I’ve downloaded and tested a few hundred iPhone and iPad apps.  One thing that I’ve noticed is that many of the top rated and ranked apps are pretty scammy.  Take for example “Night Vision.”

It’s a top app in under Utilities for both paid and free iPhone apps.

If you actually download and test the app, you’ll find it doesn’t work at all. In fact, I found it made objects darker, not brighter.  See these photos with and without the app of the exact same room in the exact same lighting.

The app tries to get you to download other apparently scammy apps.  I’m guessing this kind of “cross selling” is how Night Vision got  most of its downloads.

Another clever trick they play is when you look at the app customer ratings on the iPhone App Store you see that it has 4.5 stars:

But when you look on the desktop web you see the overall ratings are vastly lower and that they seem to game the system by releasing “new versions” to reset their ratings and then probably paying people to write positive reviews:

Companies like TapJoy let you pay to get in the Top 25, and then once you are there you can get “organic” downloads by being on the toplists.

Another platform, another way to game it.

Web services should be both federated and extensible

One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs.  APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”

The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).

In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on non-Facebook.com websites.

Consider the following scenario.  Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.

With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:

1) Embed Facebook widgets in Gowalla.  These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo.  Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.

2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.

3) Host an instance of SimpleGeo’s servers internally.  This requires heavy technical integration, undermining the main benefit of APIs.

In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo.  The data flow would look something like this:

(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above.  You could implement this today, but it would create user experience challenges.  For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).

Allowing websites to be federated and extensible will open up a whole new wave of innovation.  Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen.  Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process.  Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.

* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites.  I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.

Should Apple be more open?

It is almost religious orthodoxy in the tech community that “open” is better than “closed.” For example, there have widespread complaints about Apple’s “closed” iPhone app approval process. People also argue Apple is making the same strategic mistake all over again versus Android that it made versus Windows*. The belief is that Android will eventually beat the iPhone OS with an “open” strategy (hardware-agnostic, no app approval process) just as Windows beat Apple’s OS in the 90′s.

With respect to requiring apps to be approved, consider the current state of the iPhone platform. There are over 100,000 apps and thus far not a single virus, worm, spyware app etc. (I don’t count utterly farfetched theoretical scenarios). As a would-be iPhone developer, I can report firsthand that the Apple approval process is a nightmare and should be overhauled. But what’s the alternative? Before the iPhone, getting your app on a phone meant doing complicated and expensive business development deals with wireless carriers. At the other end of the spectrum: If the iPhone OS were completely open, would we really have better apps?  What apps are we missing today besides viruses?

With respect to the strategic issue of tightly integrating the iPhone/iPad software and hardware, a strong case can be made that Apple’s “closed” strategy is smart. Clay Christensen has given us the only serious theory I know of to predict when it’s optimal for a company to adopt an open versus closed strategy for (among other things) operating systems. The basic idea is that every new tech product starts out undershooting customer needs and then – because technology gets better faster than customers needs go up – eventually “overshoots” them. (PC’s have overshot today – most people don’t care if the processors get faster or Windows adds new features). Once a product overshoots, the basis of competition shifts from things like features and performance to things like price.

The key difference today between desktop computers and mobile devices is that mobile devices still have a long way to go before customers don’t want more speed, more features, better battery life, smaller size, etc. Just look at all the complaints yesterday about the iPad – that it lacks multitasking, a camera, is too heavy, has poor battery life, etc. This despite the fact that Apple is now even building their own semiconductors (!) to squeeze every last bit of performance out of the iPad. Until mobile devices compete mainly on price (probably a decade from now), tight vertical integration will produce the best device and is likely the best strategy.

*It’s worth noting that Steve Jobs wasn’t the one who screwed up Apple. Jobs co-founded Apple in 1976. He was pushed out in in May 1985 when the company was valued at about $2.2B. He returned in 1996 when Apple was worth $3B. Today it is worth $187B.