Can I Get Your Address?
July 27th, 2012Mac OS X’s centralized Address Book empowers developers to offer users features that go above and beyond what would be possible in the absence of such a resource. For example, an envelope-printing utility on Mac OS X doesn’t need to demand that you painstakingly type in the name and address of your friend before mailing a letter, you can search for them and automatically select from a list of matching addresses. It’s magic, it just works, and it makes a Mac a Mac.
Many other examples of Mac software just working are also based in accessing the Address Book, but instead of needing access to the whole thing, it’s just the “Me” card that is of interest. This is very useful for example if a map app wants to offer you easy directions home. A very common use case for accessing the “Me” card is when an application has good reason to pre-populate personal fields in an inquiry form of some kind: for example, a feedback or crash reporter dialog. In this case, putting the user’s email address in the field for them saves a step and prevents a possible typo.
Starting in Mountain Lion 10.8, Apple has dramatically increased security protections around the contents of users’ Address Book data. On the face of it, this is a good thing, as it protects against applications that either surreptitiously or stupidly access and upload the contents of address books to web servers without permission. The flip side is that fairly innocuous requests for the “Me” card are now met with a foreboding dialog:
Yikes! What is Red Sweater Crash Reporter and why does it want my contacts!? Sounds fishy. In fact, all it wants is the “Me” card, but there’s no way for it to let the user know this. Or is there?
Thanks to Cabel Sasser’s tweet today, I learned that there is in fact a way to express intent, albeit with a very crude mechanism. You can’t specify intent on a call-by-call basis, but you can publish in your application’s Info.plist a single string that will be conveyed to the user as an explanation for your need of Address Book data. The key is NSContactsUsageDescription, and it’s very lightly documented in Apple’s Info Property List Key Reference:
NSContactsUsageDescription (String – OS X). This key contains the localizable description of the reason why an app is requesting access to the user’s contacts information in the Address Book database.
It would be far preferable if there were an API mechanism through which an app could request specific content from the Address Book, along with a dynamically stated explanation. But this is better than nothing. Tweaking my crash reporter’s Info.plist, I end up with this:
Incidentally, if you’re a developer trying to add this to your own app, you’ll find it frustrating that the nature of this dialog provides you only one chance to get the terminology right. As soon as you click “OK” or “Don’t Allow”, that’s the last time you’ll ever see this dialog. Unless you happen to know about this magic little command line incantation (thanks to Jim Correia for reminding me):
% tccutil reset AddressBook
That clears out all permissions for your Address Book access, causing the panel to appear again the next time any app, including yours, tries to access contacts.
July 27th, 2012 at 2:53 pm
Weirdly, the manpage of tccutil says “July 27, 2012″…
July 27th, 2012 at 2:53 pm
I believe you can reset the access warnings on a per-application basis. Go to System Preferences -> Security & Privacy -> Privacy and select “Contacts” from the list on the left. You can then turn access on and off as desired.
July 27th, 2012 at 6:19 pm
You can turn application access on and off in System Preferences, but you won’t see the warning again unless you use tccutil.
July 28th, 2012 at 5:06 am
Personally I actually find it a bit creepy when apps want to be helpful and prefill those things.
July 28th, 2012 at 11:07 am
What if the crash reporter opened an unfilled ‘from’ form and had an “auto-fill’ button. This way those wanting the convenience of auto-fill could have it for the work of one click. Users would likely deduce, having clicked, why the crash reporter wanted access and wouldn’t get creeped out by the permission dialog box.
By adding one click to the UX perhaps other problems are solved more smoothly?
July 28th, 2012 at 12:52 pm
Cheers to Sasser and you, that info.plist setting will come in quite handy to explain Address Book acces in Bookpedia, I use it to create a list of possible borrowers.
July 29th, 2012 at 8:42 am
Thanks guys, at WWDC this was mentioned indeed but I didn’t find anything in the docs after coming home. A related question: does anybody know if there’s a similar key for the core location permission dialog (this app wants to know your location?), expressing intent would be very helpful there too.
July 30th, 2012 at 1:35 pm
And, of course, just because a developer says “Your address will be used to autofill….” doesn’t mean they won’t slurp the entire contents of the AB, and send it to a server in Russia.
July 30th, 2012 at 2:10 pm
I have to say with 10.8 I’ve been kind of amazed at the number of apps that want access to my Address Book data. I have a feeling once this dialog is added to iOS it will be even more shocking.
July 31st, 2012 at 10:20 am
Sort of related, is there a way to preempt this dialog in iOS apps? For instance, upon installing the app, before this dialog comes up, can you as an app developer present the user with a screen that first explains the prompt, which they’ll then dismiss and get the real prompt? Or does Apple control/mandate that the prompt is the first thing that displays?
July 31st, 2012 at 11:21 am
Here’s an idea to help people that think big brother or a un-savory phisher is after their data.
Create a dialogue that states you can enter the following user data… or by clicking authorize the app will pull and pre-fill the data from your address book. I’m not sure if this would be able to replace the Apple defined prompt for access.
July 31st, 2012 at 12:26 pm
It only takes one idiot to mess up the fun for everybody (thanks PATH).
Please think this through. As a user if I want a dialog or want to be contacted at all I’ll initiate a communication with you that makes it explicit that they want a response, say a service request. If I got an email that was generated by a crash report, that would be creepy not cool.
If there is a field of any kind and it isn’t filled in the person doesn’t want you to have that information! If I was presented with the proposed dialog, or any dialog that doesn’t make sense to me, I’m going to hit “don’t allow.” Is it truly necessary to have ANY contact information for a crash reporter?
Finally, if they are too lazy to type an email address you can’t design a program that is easy enough to use for this person.
July 31st, 2012 at 1:25 pm
Raed – I appreciate your perspective but the fact is that after conducting my crash reporter in this manner for years, I have had dozens if not hundreds of delighted customers let me know how it feels to get feedback and to have their crash followed upon. I have never had one customer express anger or a sense of being “creeped out” by the current behavior.
I suspect that the folks who would find it creepy typically take care to not send the crash report at all, to delete the email address before sending, or are cautious enough about this kind of behavior that they don’t include a “Me” card in their Address Book.
August 3rd, 2012 at 6:58 am
Cool, to answer my earlier question whether the usage description is also available for the other services like location, calendar etc, this turns out to be the case.
Coincidentally while entering the NSContactsUsageDescription key in the plist editor inside Xcode 4.4, I noticed that Xcode replaces the key name with a nice “Privacy – Contacts Usage Description”, clicking on that reveals an auto-complete and shows the other ones. See https://mekentosj-private.s3.amazonaws.com/privacy_plist.png
Pretty slick as now I can also tell my users why I’d like to have their location to put their location on the map.