Solipsism Gradient

Recently someone figured out an attack against in-app purchasing on iOS. Only a few days later Apple, with commendable speed, put up a page detailing how to counter this crack by implementing better receipt checking.

Now there’s news that a similar attack also works on OS X. For this, users have to install two bogus certificates, point their DNS at the cracker’s server, and run an auxiliary application while making the in-app purchase; this builds an apparently valid receipt inside the application bundle. (Of course this means that the user is trusting those certificates, that server and that application to be otherwise innocuous – not a good policy! And it asks you for your admin password while you’re connected to that server, too…)

So how to implement better receipt checking on the Mac? The details are different, in that OS X in-app receipts are stored inside the application bundle, inside the application’s original receipt from the Mac App Store. Furthermore this receipt has a known format and is signed by 3 certificates:

• “Mac App Store Receipt Signing” (SHA1: 4A 7B 3A 17 00 A4 DA 4A D4 EA 43 3A 83 61 43 2E CF 1C A1 AF)
• “Apple Worldwide Developer Relations Certificate” (SHA1: 09 50 B6 CD 3D 2F 37 EA 24 6A 1A AA 20 DF AA DB D6 FE 1F 75)
• and the “Apple Root CA” (SHA1: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60)

the latter can be found, of course, inside every Mac user’s System Keychain. All this was easily obtained with my RB App Checker Lite utility (ahem). 🙂

Apple’s currently recommended receipt verification code, however, does not contain any recommendation to check the certificates used to sign the receipt; it does check if the receipt is for that particular application (otherwise people would just copy a receipt from another app) and if the receipt was generated on that particular computer (otherwise one could just copy the app from a friend’s computer).

No doubt Apple will now recommend to all OS X developers that their receipt verification codes also check the certificates – and in fact, that’s what my apps are already doing. The certificates are, after all, available from the same parsing process recommended in the above link. At the very least, I recommend obtaining the SHA1 fingerprints of all 3 certificates (openssl has a SHA1() function for that) and checking them against the list above. And once that’s done, obtaining the app’s own signing certificates, and checking them, is also advisable, even if the app is signed with a Developer ID.

I’m not giving specific code examples here, to avoid people copy&pasting it into their apps and offering a clear path to hacking the binary. The usual precautions to make binary hacking more difficult (though it’ll never be impossible) apply, of course.

In a surprise move by Apple, Mountain Lion (aka Mac OS X 10.8) was announced early and in an unorthodox manner.

Their new infrastructure seems to be working well – I downloaded and installed the beta very soon after the announcement. It’s working well (for a beta) in a VMware virtual machine after following this hint.

Let me comment briefly on the “iOSification of OS X” question. Having consistent app names (and, to some extent, user interfaces) between similar applications on both iOS and OS X is a good thing. Greater integration with iCloud was also pending, and here too users need a consistent interface on both platforms. Beyond that, there seems to be little evidence that the operating systems themselves will suffer anything but a benign cross-pollination of features and APIs.

As a developer, I’m more interested in what code signing, the upcoming Gatekeeper and sandboxing requirements for the Mac App Store mean for future applications.

Code signing has been a feature of Mac OS X for some time now. The details are tricky but, in essence, executable code can be signed using an “identity” backed by a “trusted” chain of certificates. Such a certificate is a variation of the ones deployed for “trusted” websites – those whose addresses start with “https:”. Obtaining a so-called “self-signed” certificate and signing an application on OS X is quite easy, and several of my applications have been signed in that manner.

On the downside, anyone can strip such a signature and substitute another one; and checking for that is not easy for the user. Here’s part of my current Klicko product page:

To check that Klicko’s signature is intact, open Terminal, paste in the following command, and press the Return key:

codesign -dvvv -r- /Library/PreferencePanes/Klicko.prefPane

(assuming that you installed Klicko for all users; otherwise, type a tilde (~) before the /Library part.) You should see several result lines in the Terminal.Authority=Rainer Brockerhoff should be present, and identify the author. The last line should end with …root = H”4cbb97c74336f7ee6aa566122a5e7688e1c725dc” and uniquely identify the author’s signature. Now run the following command:

codesign -vv /Library/PreferencePanes/Klicko.prefPane

If the Klicko bundle is intact, this should display valid on disk; otherwise you’ll see code or signature modified. In the latter case, throw it into the Trash.

Not something that a non-techie user would do; and the system doesn’t (yet) complain if you try to run an unsigned application (or one whose signature or executable has been tampered with). Even so, on current systems there are benefits to running signed code: parental controls and keychain access are example cases.

Code signing has been mandatory on iOS from the very beginning – it won’t run applications not signed by a registered developer, backed by Apple’s own trusted certificates. The whole “jailbreaking” paradigm stems from that feature: normally, only apps from Apple’s App Store may run, and Apple can revoke an application’s certificates if the application misbehaves.

Enter Gatekeeper. As far as is known, it has three levels, selectable by the user in System Preferences, allowing the user to run applications that come from:
1) the Mac App Store only (same as on iOS devices);
2) from the Mac App Store and identified developers;
3) from anywhere (same as on current and previous systems).
It’s of course unknown which of those levels will be default when 10.8 goes golden.

Gatekeeper is triggered by the well-known “quarantine” attribute set on applications and disk images downloaded from the Internet. After the usual dialog alerting you to that fact, if you’ve set Gatekeeper to level 1 or 2, the application’s signature is checked; if it’s not backed by the corresponding trusted Apple certificate, a further dialog advises you not to run that application. There’s no override option unless you opened the application from the contextual menu (instead of double-clicking). Also note that this doesn’t happen with applications copied from external drives.

Parts of Gatekeeper are already available on 10.7.3 but must be turned on with a Terminal command. The most restricted level isn’t available, and for an improperly signed app the complaining dialog curtly advises you to “move [the app] to the Trash”; it even offers a button to do so. Although this dialog doesn’t seem to occur on 10.8, some developers are considering it a bad sign of things to come.

But it is the intermediate Gatekeeper setting which is the most important; hopefully it will be the default. So what is meant by “identified developers”? Currently, this is someone who paid the annual $99 fee to be part of Apple’s Mac developer program. As I am in that position, I’ve already requested and downloaded my code signing certificate, and will use it to sign my future applications – those published outside the Mac App Store.

The benefits to myself are obvious. Anybody who downloads my applications through the usual channel – directly from my website – can be assured that it is signed by myself, that it hasn’t been tampered with by a third party, that I’m a registered developer, and that Apple certifies that all this is true. Still, some additional care needs to be taken, both by Apple and by the user. Specifically, when 10.8 comes out it should have an easily accessible information window containing the following information: (sorry, no time to make a graphic mockup)

<Application name and version> is signed by <developer name> developer ID number.
<Link to developer/application site>
<List of certificates and their expiration dates>
Apple disclaimer (for non-Mac App Store applications).

This information should be shown on first run – perhaps on request from the “quarantine” dialog – and from somewhere in the Finder. Note also that Apple can revoke a developer’s certificate; it’s as yet unknown if that will affect already-downloaded applications (as I think it does on iOS) or not.

As I said, the user can take steps to run the application even if Gatekeeper advises against it. Unless this option is removed when 10.8 goes out of beta – and it would make no sense at all for Apple to remove it – it’s a welcome step for serious developers. And it’s a practical intermediate solution for applications or system plug-ins that don’t fit into the Mac App Store’s restrictions; specifically, regarding the impending MAS requirement for turning sandboxing on. More on that in my next post.

[Updated to fix an error regarding Gatekeeper on 10.7.3.]

This appeared on xkcd a a few weeks ago: (click to embiggen)

many other developers will sympathize.

So, I’ve been developing a system to pass you, gentle app user, arbitrary applications. Since, as I said before, a group of Mac utilities is in the works – with the first four even having icons and all – of course I thought to “save time in the long run”.

It’s been more than 20 minutes though, for which I apologize. Things have been unusually complex for me this year, not to mention a couple of recent health scares (all solved, I hasten to mention).

Returning to the condiments apps. My intention is, of course, to write an ever-expanding suite of small utilities, though Apple still hasn’t published details on how to pass info from between apps in such a suite if they are on the Mac App Store. (And there’s the upcoming app sandboxing deadline to consider – an added complication.)

Anyway, all apps will work in a similar manner: file(s) are dropped onto the app’s icon, or selected from the standard Open Panel. Then something will be done to those files – information summarized, files counted, permissions checked and optionally changed, whatnot; all expected functions should be reasonably obvious from the UI.

So we have a host of common functions, namely, implementing the App Store receipt checking, sandboxing considerations, receiving dropped and opened files, scanning over them (and perhaps over their contents, if they’re folders), showing the About Box and some help, and doing all that in a consistent manner.

I’m happy to report that everything along those lines is now working perfectly, and with the new workspace facility in Xcode 4, expanding from one to several apps will be a piece of cake. Let’s leave the culinary metaphors aside for the moment and ponder how I’ll can deliver – considering that my record regarding past deadlines has been not so good. (OK, abysmal.)

The answer is obvious: take a cruise. In recent years, everything significant I’ve released had been mostly written and polished on a cruise ship. No distractions, no phones, almost no Internet, no relatives (haha)… and I can impress my fellow passengers by saying “well, I’m making money for the next cruise here on board!”.

So, for over a year we’ve been planning a major cruise – it might be our last long cruise for the foreseeable future, even. And I’m very happy that we leave early tomorrow to return in the last days of January 2012. (Should give us time to prepare for the Mayacalypse, anyway.)

I’ll be posting from underway without saying too much about destinations, to add to the suspense. We should have occasional – though expensive – Internet onship, so email etc. should work. Our next stop should be Santiago del Chile. Stay tuned!

If you missed it, here’s part 1.

Now, as I said, hardware details are becoming interesting only to developers – and even we don’t need to care overly about what CPU we’re developing for, now that we’re used to both 32-bit and 64-bit, big-endian and little-endian machines. (Game developers and players, of course, are a different demographic.)

As Steve Jobs said, it’s all about the software now. Here, too, too much emphasis on feature details can be misleading. I don’t really care whether Apple copied the notification graphic from Android, or whether it was the other way around. What’s important is that user interfaces are evolving by cross-pollination from many sources, and this is particularly interesting regarding iOS and OS X (note that the “Mac” prefix seems to be on its way out).

The two operating systems have always have had the same underpinnings in BSD Unix/Darwin and in several higher layers like Cocoa and many of the various Core managers. In their new versions, APIs from one are appearing in the other, and UI aspects are similarly being interchanged; compare, for instance, the Lion LaunchPad against the iOS SpringBoard (informally known to iOS users as “the app screen”).

Apple is not “converging” OS X and iOS just for convergence’s sake. Although desktops, laptops, tablets, phones and music players are all just “devices” now, the usage and form factor differences must be taken into account. Remember Apple’s 2×2 product matrix some years ago: desktops and laptops, consumer and pro machines? It hasn’t shown up lately, and we really need a new matrix; the new one should probably mobile and fixed, keyboard and touchscreen.

Don’t be misled by appearances! Yes, the LaunchPad looks like SpringBoard, but that doesn’t mean that we’ll have touchscreen desktops soon – rather, both interfaces are, in fact, a consequence of the respective App Store, being an easy way to show downloaded apps to the lay user. Apple is, however, exploring gesture-based interfaces and no doubt we’ll see the current gestures evolving into a universal set employed on all devices, the same way common keyboard shortcuts have becoming engrained. A common thread here is that hardware advances like touchpads, denser and thinner screens, better batteries and faster connections are becoming the main innovation drivers technologies, like processor speed and storage size used to be.

A subtle and very Apple-like aspect of this sort of convergence has become visible when the iPad came out. While some scoffed that the iPad was “just a larger iPod Touch”, in fact the iPod Touch had been, all the time, just a baby, trial-size version of the iPad! The Touch, the iPhone, and even the older iPods were an admirable way of getting the public used to keyboard less interfaces, and the iTunes Store was a similar precursor to the App Store. This means that when the iPad came out there was a legion of users already trained to its concepts and interface; an excellent trick, and one that only Apple could pull off.

Now we see that, in a similar way, the iPad and its smaller siblings are preparing the general public to migrating to larger, more powerful, devices which look comfortingly similar in many ways. Few consumers think of their iPhones or iPods as computers, even though they’re as capable as the supercomputers of 15 or 20 years. Now that desktops and laptops are just devices – and you won’t need a so-called computer anymore to set up your smaller devices – very soon this new class of “devices with keyboards” won’t be thought of as computers either, and the term will be used only for servers and mainframes, as it was in the old days.

I, for one, welcome our new post-PC overlords… 🙂

Yesterday, Steve Jobs announced that in a few months, Apple will open an App Store for Mac OS X, following much the same model as the previous – and hugely successful – App Store for iOS.

Two things are immediately obvious: first, the Mac OS X App Store won’t be the only way for users to purchase, download and install applications on their Macs; the previous, time-tested ways will continue to be allowed. Second, the App Store (as the name states), is for applications only – and only for applications of a certain kind.

The long list of prohibitions and cautions exclude, often by definition, system preference panels (like my own Quay), kernel extensions or apps that use them, complex application suites that install background processes, and in fact, anything but a plain old-fashioned self-contained application would be hard-pressed to observe all the guidelines. In fact, as others have observed, most of Apple’s own applications are non-compliant.

The huge difference from the iOS App Store is that developers are perfectly free to write software outside the guidelines, and users are perfectly free to install them. What the new App Store is promising to be is, in effect, a fenced-in garden where a certain type of user can download and install a certain kind of application while getting the warm fuzzy feeling they know from the iOS app store.

In fact, my hunch is that Mac OS 10.7 (Lion) will have an interesting change to the “Accounts” panel in System Preferences. Today, you have four types of user accounts: Administrator, Standard, Managed with Parental Controls, and Sharing Only (aka Guest). I think that all but “Administrator” accounts will allow the user to install applications only via the App Store, and that the Managed and Guest accounts will have an option restricting that user to only run applications from the App Store.

Which may not be such a bad idea after all.

For the developer, it seems that it won’t be allowed to have the same application sold over the App Store and outside it; perhaps not even different versions of the same app. That also makes sense to me. In other respects, the same old arguments apply to both the old and new App Stores: price erosion must be avoided, marketing your app in the long term can’t be left in Apple’s hands, and so forth.

As for myself, I still haven’t had an idea for an iOS app compelling enough that hasn’t been done already, and so far that same argument applies to Mac OS X apps that would fit into the guidelines; my interests lie, still, in doing utilities that enhance the system – not allowed on iOS, still very interesting on Mac OS X.

While reading the links pertaining to the previous post about a “back” button for the iPad – and, incidentally, for the Mac – it occurred to me that such a capability might be built into a future version of my Klicko utility. Which is Mac-only, of course. For now, Apple doesn’t allow any sort of utilities for the iPhone/iPad, more’s the pity.

I’m rather overloaded at the moment, moving out of my apartment only a few days before going off to WWDC, and I’ve got an iPad app prototype to work on, too; but I’ll definitely look into this as soon as possible. I think that most of the infrastructure, in fact, is already in place inside Klicko.

I did download the Universal Back Button App, but didn’t have time to check out how it works; at any rate, it seems to be quite different in implementation.

Brent Simmons, author of NetNewsWire, writes:

On Macs we have a long-standing culture of apps working together.

…

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app.

…

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

I was thinking about the same issue, coincidentally, and one idea which occurred to me is to use the equivalent of the http referrer URL (often misspelled as “referer” for historical reasons).

For  a standard http request the referrer is the URL of the document containing the clicked link, so you can get back to that document by clicking on your browser’s “back” button. Now, this isn’t really contained in the URL itself – rather, the browser appends this as one of the fields in the http request headers – but the analogy is interesting.

For this to work locally between applications, the referrer URL would need to be set into the URL targeted at the called application. And indeed, there is a -[NSURL setResourceValue:forKey:error:] method that, in theory could add any key/value pair to the URL. (Currently only the “scheme” property seems to be available, though.)

Update: Mike Abdullah points out in the comments that, in practice, this method applies properties to the file a file URL points at, not to the URL itself. Drat.

On the receiving side, the “referrer” value would have to be pulled out from the NSAppleEventDescriptor that the application gets with the ‘GURL’ event.

All this needs filing enhancement requests and Apple would have to do the required twiddling inside their code base – or rather, bases, as this would be useful to have both on the iPhone/iPad and the Mac side. It would take a long time, if it’s done at all.

The alternative would be to developers to, informally, establish a convention for incorporating this into the URL itself. So we’d have something like:
calledscheme:///the/url/parameters&?REF=callingscheme://some/url/to/return

Probably the second part would have to be suitable encoded/escaped, too. Maybe this would be a good topic for discussion at WWDC?

So, to start things going again… I was looking at my RSS feeds for the first time in almost 5 months, and read Dan Wood of Karelia fame explaining about Converting Rich Text to TEXT/styl resources for an SLA on a Disk Image.

My own workflow for building a release disk image uses a small tool I’ve written for that. You can download it here. Here’s the help text it prints out if you run it without arguments:

   Add one license at a time to a (unflattened) disk image.
   Usage: AddLicense /path/to/TheUnflattened.dmg Language /path/to/TheLicense.rtf
   Languages supported: da nl ko ja fr it fi pt sv en es de nb
   You can also use long equivalents like English, French etc.
   The first language added will be the default language (usually English).

Here's an actual usage example from a build script:

   hdiutil unflatten "$SOURCE_ROOT/My.dmg"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" English "$SOURCE_ROOT/EnglishLicense.rtf"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" French "$SOURCE_ROOT/FrenchLicense.rtf"
   hdiutil flatten "$SOURCE_ROOT/My.dmg"

and I use the “flatten” and “unflatten” arguments to hdiutil to massage the disk image.

The trick (as Dan points out in his post update) is that you can use ‘RTF ‘ resources instead of TEXT/styl. I received this interesting tidbit through oral tradition; I’m not a 100% certain, but I think it was through some code that Marko Karppinen showed me a few years ago. Pass it on.

If there’s interest, I may clean up and publish the source sometime, though it uses all sort of gronky old APIs (Resource Manager etc.).

Update: the link above now downloads the complete Xcode project. I also included it on my source code page.