Mac 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.

Before Mountain Lion 10.8 shipped, I had received reports from one customer that MarsEdit was crashing each and every time he attempted to access the network. For an app like MarsEdit whose entire raison d’être is to access the network, this is quite an unfortunate obstacle.

The public release of Mountain Lion has only confirmed that the problem, while rare, is significantly wide spread that I’m sure it affects at least dozens of my customers, hundreds of the customers of my colleagues, and probably thousands of Mac users worldwide.

The tell-tale sign of this crash is it occurs only as the app attempts to connect to some network resource, and the crashing thread always culminates in some stack trace involving CoreSchedulingSet or EmptyCoreSchedulingSet C++ objects.

Here’s one example, with just the crashing thread a few stack frames deep:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-priority
0  com.apple.CFNetwork              0x00007fff8d26cc92 CoreSchedulingSet::
			copyWithUpdatesReleaseSelf(CoreSchedulingSet
			const*, CoreSchedulingSet const*) const + 104
1  com.apple.CFNetwork              0x00007fff8d26c995
			CoreSchedulingSet::copyWithAdditionReleaseSelf(__CFRunLoop*,
				__CFString const*) const + 71
2  com.apple.CFNetwork              0x00007fff8d2cfac6
			__executionContextSchedule_block_invoke_0 + 44

And another, where the non-main thread crashes in an EmptyCoreSchedulingSet destructor:

Thread 3 Crashed:: Dispatch queue: com.apple.root.default-priority
0  libsystem_kernel.dylib            0x00007fff8d089212 __pthread_kill + 10
1  libsystem_c.dylib                0x00007fff913b2b34 pthread_kill + 90
2  libsystem_c.dylib                0x00007fff913f6dfa abort + 143
3  com.apple.CFNetwork              0x00007fff8fd8c928
			EmptyCoreSchedulingSet::~EmptyCoreSchedulingSet() + 60

Google searches, and some chat I’ve seen on Twitter, suggests the problem is certainly not limited to MarsEdit. Even Safari is vulnerable to these crashes in the affected configurations.

So what are the affected configurations? I’m not sure. Anecdotally, it seems like you’re more likely to see the problem if you are connecting in an institutional network such as a school or a large company. One customer also mentioned that he crashes when connecting through the Thunderbolt ethernet adaptor, but is able to connect without issue through the WiFi interface for his Mac.

I am posting this here in an attempt to document the known symptoms and scenarios for this crash, in case it helps other developers and customers who run into the issue.

I hope that Apple will issue a fix for this in 10.8.1, if not sooner. It sounds like this is affecting an awful lot of customers and as far as I know there is no workaround, short of changing the circumstances of how you are connecting to the internet by using a different interface or moving to a different location.

Update: I am now convinced by putting the pieces together and correlating my experiences with those of folks including the support crew at Agile Bits, that this is issue is related specifically to the “Auto Proxy Discovery” and “Automatic Proxy Configuration” settings in Network preferences. If you have one of these options checked, you are very likely to crash in MarsEdit, Safari, Tweetbot, and any number of other apps that rely on Apple’s networking libraries.

I recommend turning off the Auto Proxy Discovery and Automatic Proxy Configuration features in 10.8 unless you are on a network where using them is strictly required.

Click here for detailed instructions.

In light of the apparent link to a commonly used proxy configuration, and the growing number of apps confirmed as affected by this issue, I am hopeful that we’ll see a fix from Apple sooner than later.

Instapaper developer Marco Arment responded to the latest installment of John Siracusa’s famously elaborate Mac OS X reviews with an amusing, fairly elaborate review of the review itself. Each is worth reading, or at a minimum, each is worth reading later.

Siracusa’s article is particularly suitable to archiving for later perusal, as it clocks in at a whopping 24 “web pages.” Arment estimated it took him around two hours to read. Given my busy schedule and poor attention span, I suspect this will be split up into several shifts, reading a little bit when I get the chance.

Multi-page articles used to be a bugaboo for Instapaper. Faced with an article like Siracusa’s, it would happily save it to your reading list, but when you sat down to dig into the story, you’d be vexed to find you were stuck with only the first of 24 pages. Happily, in March of this year, the Instapaper bookmarklet was updated to support multi-page archival.

I have an Instapaper keyboard shortcut wired up, so when I’m looking at a page I want to read later, I just press control-p, and up comes Instapaper’s friendly “Saving” panel. When it’s saving a multi-page article, it updates the UI while it cranks through the pages.

I pressed the keyboard shortcut on Siracusa’s article, and settled in for a relatively long Instapapering lull. To my surprise, the save panel appeared and disappeared almost instantly. Uh oh, has Marco screwed up multi-page archiving for a canonical example of its usefulness? On an article that he himself has drawn additional attention to?

Nope. All the pages are there. I confirmed through Instapapaper that the complete, gloriously long article would be waiting for me on my subway ride later this morning. Kudos to Instapaper!

But how did it happen so quickly? Does Marco special-case certain popular pages like this in an effort to boost perceived performance? Or perhaps one of the subtle improvements over the years has been some kind of automatic server-side de-duping of archives. This would save Marco a bunch of space on his servers while also improving performance for users.

Archiving Advice

However Instapaper did it, archiving John Siracusa’s review of Mountain Lion 10.8 with Instapaper was, ahem, instant and complete. Would archive again.

Now that Safari 6 is available as part of Mountain Lion 10.8, and as a software update for Lion, I can finally explain the rumblings I made months ago about an extension facilitating feed subscription directly from Safari.

The motivation behind my foray into Safari extension development was my early adoption of Safari 6 during the beta phase. I noticed they had removed the long-standing, built-in “RSS” button near the URL bar. This button makes it easy to subscribe to an RSS or Atom feed for a blog, or any other site that offers such a feed.

I’m disappointed by Apple’s decision to remove the button, but when life hands you lemons …

My beta-quality, more-or-less unsupported Subscribe to Feed extension adds a handy button to the toolbar that, when a page offers RSS or Atom feeds, can be clicked to easily open the feed:// link, which should automatically open your favorite news reader.

I hope this extension fills a void for those of you missing the beloved RSS button from Safari 5 and earlier.

Updates:

• Since I posted this on Wednesday (the day Mountain Lion 10.8 was released), the response has been overwhelming. I didn’t realize there would be so much interest in restoring the functionality of the Safari RSS button.

  The interest has been so strong that more than a couple people have installed the extension apparently unaware of its purpose. The gist of the extension is to make it easy to subscribe to RSS and Atom feeds in an external application, separate from Safari. For example, it will open in NetNewsWire, Reeder or any other application on your Mac that claims to support “feed:” style URLs.

  Some folks who are just getting in to desktop RSS readers are discovering they don’t have a “default app” setting on their Mac, and Apple no longer provides a simple UI inside Safari for setting the default. The best solution I know for this issue is to download and use the venerable RCDefaultApp to set a default RSS reader for your Mac.

• A number of users who use Google Reader through the browser would like it if there were a way for this extension to automatically subscribe in Google Reader instead of through a Mac client. I’m not sure exactly how this would work but I bet it’s possible with a preference in the extension that would offer the ability to open a Google Reader URL for subscribing. This is a little ambitious though, so if you want this feature and happen to be able to code Safari/JavaScript solutions, please send me a proof of concept for subscribing to Google Reader from JavaScript on a web page, and I’ll see if I can integrate it into the extension.
• On August 2, 2012, I released Subscribe to Feed 1.0b4, addressing a number of issues from the initial release.