Marco.org

I'm : creator of Instapaper, technology writer, and coffee enthusiast.

iOS Address Book access should prompt the user for permission

The popular Path app was caught uploading and permanently storing people’s entire address books on Path’s servers. People were upset, but what’s scarier is the bigger issue: apparently, this is a very common practice among popular apps.

It’s easy to set Path on fire for this, but accessing the iOS Address Book is essential to most “Find my friends on this service” features. Indeed, I use the Address Book for a similar feature in Instapaper as well. But there’s a big implementation difference between my method and Path’s.


The two Instapaper features that access the Address Book

Instapaper accesses the Address Book for two features:

  1. The “Add ‘Read Later’ by Email” option in Settings, which creates a new Address Book contact with the customer’s special email-in address. This feature operates only on the device and does not send any information to the Instapaper servers. And the only reason it even reads the Address Book at all, rather than just writing to it, is to check for an existing copy of the “Read Later” contact so it doesn’t make a duplicate.
  2. When searching for new friends in the Friends section, I offer a “Search Contacts” option. This sends (over SSL) a list of email addresses to an Instapaper server, which issues a single SELECT statement on the user database to find any matches. That’s it. The list of email addresses isn’t stored (the query isn’t even logged), and only email addresses are sent, not anybody’s name, phone number, address, or other information.

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.

This, apparently, is not a common implementation courtesy.

We can’t prevent services with poor judgment or low ethical standards from doing creepy things with the data once it’s sent to them. We can’t even realistically use App Review to only permit access to the Address Book fields (email, name, phone, etc.) that are justifiable for any given app to access, because there are too many gray areas.

But Apple can, and should, assure users that no app can read their contact data without their knowledge and explicit permission. I don’t know why this hasn’t always been required, but it probably isn’t a good enough reason to justify the erosion of user trust in iOS apps that this could cause.

Apple needs to change the Address Book API to require user permission first, like Core Location and Push Notifications do. I don’t care how many applications break as a result. Not requiring user permission to date should be treated as a security hole and patched promptly.

Fixing “Previous Track”

I often accidentally hit the wrong button in the iPhone music-playback control bar, because they’re too close together since the introduction of AirPlay:

When playing music, the behavior of these makes sense (for the most part), since it mimics the behavior of CD players:

When you’re listening to a podcast or audiobook — anything “bookmarkable” that remembers its playback position, rather than starting from the beginning each time it’s played — the behavior of the “Previous Track” button has a significant side effect:

If your finger slightly misses the “Play/Pause” button, probably the most commonly pressed button in this group when listening to podcasts or audiobooks, it is very likely that you’ll hit one of the buttons next to it.

Accidentally hitting the “Next Track” button is a minor annoyance, but its behavior is reasonable.

But the “Previous Track” button loses and resets my playback position, which is extremely frustrating and disruptive to listening. And there’s no “Undo”.

It’s a form of data loss: not in the traditional sense of needing to recreate a document, but because it requires me to take additional time to manually restore the correct state after the disruptive, non-undoable result of a very simple accidental action.

I know this is a tricky design problem, but my proposed solution is simple:1

Stop making the “Previous Track” button behave like it does on CD players, where tapping it first brings you to the beginning of the current track, and tapping it again within a short time goes to the previous track. Even on CD players, that was often annoying.

Instead, make it behave just like the “Next Track” button in reverse: always just seek to the previous track. If the previous track is bookmarkable, resume from its last-played position, and if not, play it from the beginning.

People who actually want to reset the playback position of a bookmarkable file before it’s finished, which is probably a very uncommon action, can simply drag the progress scrubber all the way to the left.


  1. This is admittedly dodging the exacerbating factor that the buttons are too close together. But the position-losing behavior of “Previous Track” even annoys me when I’m using the iPhone remote-clicker or my car’s controls to change tracks. It’s primarily a problem with the universal behavior of “Previous Track”. 

Against the wall

Google dominated search and online ads with a lot of great engineering and hard work, then they leveraged their search dominance and more great work to build a strong presence in webmail, maps, and many smaller categories.

Geeks like us commended them for how well they operated their business, seemingly (mostly) living up to their geeky, feel-good “Don’t be evil” motto1, “winning” by releasing (mostly) quality products that catered to our geeky preferences while gaining huge marketshare.

But social networking never worked well for them. The battles between social giants bought Google some time, but now, Facebook has established themselves into as strong of a position in social networking as Google holds in search and advertising. As Facebook extends its social dominance into more areas that may threaten Google’s profits and relevance, Google knows it has to fight back and is finally making a strong attempt. But, unlike when Microsoft realized it was late to the web over a decade ago, Google’s big attempt to invade social networking with their own Google+ product hasn’t worked.

It’s the first time that Google has largely failed against a threat of this magnitude.

It’s easy not to “be evil” when you’re ahead. But when you’re backed into a corner and your usual strategies aren’t working, it’s easy to get frustrated, scared, and angry, and throw previously held morals and standards out the window.

People with very strong values can maintain their standards and dignity even under immense pressure. But that’s no easy feat. And every time we get a peek into Google’s leadership, from intentional patent infringement and anticompetitive aggression to selling out net neutrality and now tarnishing search relevance, it’s increasingly clear that Google’s upper management is willing to do a lot of “evil”, even by Google’s own previous standards, to get their way when they’re not winning.


  1. In the first version of Bullshit, I had misquoted the “Don’t be evil” motto as “Do no evil”, and a reader complained by email that I was being too strict. The difference between the two is subtle but important.

    “Do no evil” is a much stronger statement: don’t do anything “evil”, whatever that means.

    “Don’t be evil” allows a lot of wiggle room and equivocation. What does it mean to be evil? Can you still do evil here and there without being evil overall? Doing evil seems more concrete and easily verifiable by others, but being evil sounds like the kind of label you’d be able to escape if you only do evil occasionally, or if you think what you’re doing is justifiable. 

Ads via The Deck