PathGate and Best Practices for Implementing “Find Friends”

8 Feb

Yesterday, somebody discovered that Path and other mobile apps upload the entire address book contents of a user’s phone to their servers. If you’re not familiar with the backstory, read the links above.

Path’s Reaction

Since the whole thing unfolded, Path acted quickly, apologized to their users, released an update that (partly) addresses the issue, and deleted all the address book content off of their servers.

I know the guys at Path well, and I’m sure they had only the best intentions in mind. In my opinion, they handled this about as well as they possibly could have after the news broke.

Some people gave Dave Morin some grief for this statement:

2. This is currently the industry best practice and the App Store guidelines do not specifically discuss contact information. However, as mentioned, we believe users need further transparency on how this works, so we’ve been proactively addressing this.

In saying that, he is mostly correct. Apple’s App Store guidelines do not specifically discuss contact information, and most apps that implement “Find Friends” functionality using the internal address book do it this way.

The one point that I disagree with is the “best practice” statement. I think what he meant to say here is “common practice”. Why? It’s been handled in a better way in the past. How do I know this? Because we built it, over 3 years ago.

A Better Way

The point of uploading the user’s address book information to the Path servers is to match potential friends who are also using Path, and notify the user when one of their friends joins. I think that’s good functionality and users appreciate it.

Over 3 years ago, we were working on the now defunct Brightkite iPhone app, and were building similar functionality to help our users find their friends on the service. When we were discussing the implementation, the first iteration inevitably lead to the same strategy that Path is using: upload the user’s address book information to our servers so we can do the matching.

But it didn’t feel right. I could already see the headlines about the privacy issues once people discovered what we were doing, very much like the headlines we saw yesterday. So we tried harder, and gave the whole issue some more thought. It didn’t take very long before we realized that we didn’t actually need the actual phone numbers and email addresses of people to match them; we just needed their hashes.

For those unfamiliar with hashes, a hash is the result of a one-way function that takes some input (in our case, an email address or phone number) and spits out something that looks like this:

2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

The important characteristics of a hash are:

  1. Identical inputs will yield the same hash
  2. It is virtually impossible to deduce the original input from a hash if a strong hashing algorithm is used.

So, instead of sending a user’s address book contents to our servers, we only sent the hashed entries (with some normalization, such as lowercasing strings, and cleaning up phone numbers prior to hashing).

Then, we could just compare the hashes on our servers and inform our iPhone app that entry X in a user’s address book matches Brightkite user Y, all without ever “seeing” any actual phone numbers, names or email addresses. This enabled us to implement the same “Find Friends” functionality that so many apps nowadays use without compromising the privacy of the address book.

Apple’s Share of the Blame

Lastly, I wanted to take this opportunity to point out that Apple is to blame for some of this situation as well:

  1. As Dave stated, Apple doesn’t have any clear guidelines around accessing and using the internal address book.
  2. iOS doesn’t prompt the user for permission when an app tries to access their address book information.

I’ve had Apple developer evangelists actually tell me that in order to make signup to our apps easier, we should look for the “Me” card in the address book and pre-fill the signup form. While that seems like a great idea at first, I can’t help but wonder how people would feel if they saw this being pre-populated (“How do they know my personal information?!?”).

With regards to prompting for permission, this one just seems plain silly. iOS prompts you if an app wants to use your location, or wants to send you push notifications, but not if it wants to access your address book. Even my old Nokia 6620 did that, in 2004 mind you.

I would feel better if Apple added such a prompt, and I think they will, eventually.

Conclusion

While we didn’t opt to offer address book friend finding in Forkly (yet), I hope that this blog post helps those who are looking to implement such a system in their own apps.