Thoughts from an iPad

John Gruber:

Maybe the answer to the iOS address book situation is to require the user to grant explicit permission through a dialog box, but it’s not a slam-dunk decision. Every dialog box has a cost.

That’s one answer, sure. But I think you’re solving the wrong problem. I think theres an inherit flaw in how all of the APIs come together and the assumptions developers are allowed to make when it comes to privacy.

Marco:

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.

When I had to access the address book I felt the exact same way. Most users, however, don’t care. Going back to Apple’s basic concept: it just works. Location, unlike address book, is time-sensative. There is a specific time associated with the location. Depending on how wide of a span worth of data you have, the creepier you can be (e.g. calculating speed, possible routes, destinations, etc). He goes on:

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.

Come on. I’ll meet you half way: give users an option to decide this on an app-by-app basis, but not by default. A little toggle in Settings.app to lock down the address book with a bunch of on/off toggles for each app that pop-open below.

And he goes on:

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.

Consider this from a development perspective, oh mighty developer. Every application that uses a single ABAddressBookRef or any related function breaks. Except wait, they linked to AddressBook framework. So when AddressBook framework can’t talk to Apple’s hooks, AddressBook framework causes your app to crash. The only way to see this is to update your dev tools and realize none of the function hooks exist anymore. Or maybe they do exist, but Apple is blocking the thread so that it can popup the UI alert. The only way this is possible is to deprecate AddressBook framework as is, for the whole course of iOS 5.1, or even iOS 6. And provide the new alternative as the “go to” method. In iOS 7, they can finally remove it. Alright, sounds good. 2 years later.

The only logical reason for you to take my knife from me is that you think I’m a terrorist. You’ll smile and shake your head at the dopey terrorist, and you’ll go tsk tsk, and then you’ll let me through to board my flight.

So, TSA, answer me this: why are you allowing suspected terrorists onto planes?

The problem with this is that you’ll never get your answer. I actually just wrote a paper about this in my current issues class. The TSA is one of America’s many security theaters. Perceived security, to make us feel safe. Because that’s all that really matters.

However, consider that someone who was a terrorist stole that knife from you. Then he is able to get on the flight without any issues, and maybe cause an even bigger panic than before. Food for thought.

Update from Google:

Today we’re starting to roll out a fix which addresses a potential security flaw that could, under certain circumstances, allow a third party access to data available in calendar and contacts. This fix requires no action from users and will roll out globally over the next few days.

Security researchers at the University of Ulm say the attack has been tested on Android versions 2.1 (Nexus One), 2.2 (HTC Desire, Nexus One), 2.2.1 (HTC Incredible S), 2.3.3 (Nexus One), 2.3.4 (HTC Desire, Nexus One), and 3.0 (Motorola XOOM) along with the native Google Calendar, Google Contacts, and Gallery apps (or respective synchronization services).

• Until Android 2.3.3 the Calendar and Contacts apps transmit any request in the clear via http and are therefore vulnerable to the authToken attack. This affects 99.7% of all Android smartphones (stats from 2nd of May 2011). Since Android 2.3 the Gallery app provides Picasa Web Albums synchronization which is also not encrypted.

• Since Android 2.3.4, the Calendar and Contacts apps are using a secure https connection. However, the Picasa synchronization is still using http and thus is still vulnerable.

• Our sniffed authTokens were valid for several days (14 days for a sniffed Calendar authToken), which enables adversaries to comfortably capture and make use of tokens at different times and locations.

My thanks to John Gruber for his two-cents and bringing this to my attention:

I’m sure most Android handsets will be updated to version 2.3.4 or later very soon, so no worries.

This is sarcasm people. Sarcasm.