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.

 

And then, suddenly, it works

The other day a friend was demoing a new app he was working on. My first reaction was: “Yeah, yeah. This is nicely executed version one of those ideas I’ve seen 50 times.” My second reaction was: “But I could say that about pretty much every successful startup I’ve seen over the last 10 years.”

Most of the time, important new ideas don’t succeed on the first attempt or even the first ten attempts. But then they do, and it seems to happen suddenly. It’s hard to tell why this is. It’s probably a combination of timing (riding some fundamental shift in technology or culture), and execution (getting the product just right).

An idea getting tried over and over tends to be a positive signal (which is one reason that competition is overrated). It’s very easy when you spend lots of time around startups to get cynical. You could tweet and blog predictions that every new startup will fail and how the ideas are derivative and you’d be right 95% of the time. The hard part – and what matters for founders and investors – is figuring out the right mix of timing and execution to finally get it right.

Maximizing capacity utilization as a startup premise

In stark contrast to other major airlines, Southwest has been profitable for 40 years. If Southwest had one core “startup premise” it was this: for every second the planes sat on the ground, their airplanes and people were costing them money but not generating revenue. So Southwest designed an airline from the ground up that maximized capacity utilization. They avoided the hub-and-spoke system that led to cascading delays. They removed meals to reduce ground crew times, along with assigned seating so passengers would hurry onto the plane to get good seats. They used only one aircraft type to reduce maintenance times.

Some of the most interesting startups today are founded on the same premise of maximizing capacity utilization. Being information technology startups, their method for doing so is generally by matching demand for capacity with supply of un-utilized capacity. AirBnB lets people rent out unused space, increasing the utilization of their homes. Uber lets drivers rent out their unused time, increasing the utilization of their cars and labor. Services like TaskRabbit are trying let people fully utilize their “labor capacity”. Over time, services that increase capacity utilization tend to drive prices down (even if, at first, they sometimes have higher prices).

Whenever Southwest would begin servicing a new city, it drove prices down so dramatically that economists began referring to it as the “Southwest Effect“. One particularly remarkable aspect of the Southwest Effect: when Southwest began servicing a city, it would stimulate new business activity – and thus air travel – to such an extent that even Southwest’s less efficient competitors ended up benefiting.

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.

What jobs are users hiring your product to perform?

One of Clay Christensen’s favorite concepts is that instead of dividing your customers into segments and asking which features each segment would like, you should think about what “job” the customers are “hiring” you product to perform. Here is an example:

A fast-food restaurant chain wanted to improve its milkshake sales. The company started by segmenting its market both by product (milkshakes) and by demographics (a marketer’s profile of a typical milkshake drinker). Next, the marketing department asked people who fit the demographic to list the characteristics of an ideal milkshake (thick, thin, chunky, smooth, fruity, chocolaty, etc.). The would-be customers answered as honestly as they could, and the company responded to the feedback. But alas, milkshake sales did not improve.

The company then enlisted the help of one of Christensen’s fellow researchers, who approached the situation by trying to deduce the “job” that customers were “hiring” a milkshake to do. First, he spent a full day in one of the chain’s restaurants, carefully documenting who was buying milkshakes, when they bought them, and whether they drank them on the premises. He discovered that 40 percent of the milkshakes were purchased first thing in the morning, by commuters who ordered them to go.

The next morning, he returned to the restaurant and interviewed customers who left with milkshake in hand, asking them what job they had hired the milkshake to do. “Most of them, it turned out, bought [the milkshake] to do a similar job,” he writes. “They faced a long, boring commute and needed something to keep that extra hand busy and to make the commute more interesting. They weren’t yet hungry, but knew that they’d be hungry by 10 a.m.; they wanted to consume something now that would stave off hunger until noon. And they faced constraints: They were in a hurry, they were wearing work clothes, and they had (at most) one free hand.”

The milkshake was hired in lieu of a bagel or doughnut because it was relatively tidy and appetite-quenching, and because trying to suck a thick liquid through a thin straw gave customers something to do with their boring commute. Understanding the job to be done, the company could then respond by creating a morning milkshake that was even thicker (to last through a long commute) and more interesting (with chunks of fruit) than its predecessor. The chain could also respond to a separate job that customers needed milkshakes to do: serve as a special treat for young children—without making the parents wait a half hour as the children tried to work the milkshake through a straw. In that case, a different, thinner milkshake was in order.

There are at least three obvious ways to apply this concept: 1) when searching for startup ideas, think about jobs people want done that they can’t currently get done, 2) when thinking about how to fix or improve your product, understand why existing users are hiring your product (or should be hiring your product) and try to improve those experiences, 3) when analyzing markets, segment companies by the jobs they are hired for. Sometimes products that might appear similar (e.g. two photo sharing apps) are actually hired for very different purposes, and are therefore misclassified as competitors.