Solipsism Gradient

Yesterday evening RB App Checker Lite was approved for sale in the Mac App Store. Whew; it’s been a difficult couple of weeks, but it’s done. Now to relearn my php-fu and do a better product page, and of course restart work on other apps in the RB Utilities suite. Next in queue are “RB File Counter”, “RB File Alias” and the non-lite version of RB App Checker.

 

 

News on the RB App Checker Lite front. Version 1.0 (179) is out; check the product page for release notes.

The previously published version was 1.0 (171) – note I’m just incrementing the build number for now, this is mostly for keeping this version in sync with the one submitted to the Mac App Store.

Speaking of the MAS, my first submission was finally rejected for a bug with Services registration (after 7 days “Waiting for Review”, which is not too bad). So I’ll be resubmitting tonight, with that bug hopefully solved, and several new others fixed and new features added.

The most interesting new feature is checking for embedded provisioning profiles.  iOS apps will always have one, but you normally won’t see such a thing in a Mac application. However, both .xcarchives and apps “built for archiving” will have an embedded profile (unless you’re signing with your Developer ID).

Feedback welcome!

Update I: ehrm, make that version 1.0 (181). Only the icon has changed; Apple objected to my using the “generic application” icon as part of my own.

Update II: yes, the new icon is just a stopgap, will be redoing the details in the next build.

RB App Checker Lite is now functionally complete and I decided to simultaneously publish the 1.0 version here – it’s free – and on the Mac App Store. In the “About Box” the version appears as 1.0 (171).

If you already have one of the public betas somewhere on your hard drive, better remove it before unzipping this version – otherwise the Services Manager may become confused about the correct version to run.

One interesting new feature is that you now can run RB App Checker Lite on Xcode archives (.xcarchive bundles). This will also work for iOS archives, by the way.

I’m still working on more and better documentation and perhaps some sample screenshots on the product page. I suppose I also should add a new support forum.

Regarding the Mac App Store version, before actual review there still seems to be some problem regarding developer profiles and certificates — somewhat ironical for this specific application! Still, this being my first submission to any of the App Stores, it’s to be expected. Stay tuned for news.

Inspired by my recent musings about OS X 10.8 – specifically, the need for a way to check application signatures – I’m releasing the first public beta of RB App Checker Lite. Please follow the link to download.

RB App Checker Lite will be an easy way for anyone to check any executable – application, command-line tool or framework – for signatures. Also, for an app downloaded from the Mac App Store, it will show you the receipt and check everything for validity.

This is also the first of my forthcoming RB Utilities application suite. Here’s the application icon:

The icon series was designed by Sérgio Bergocce. The cube will be common to all applications, my logo is of course on the left, and the right-hand side will symbolize what each app does; the colors will try to symbolize price and geekiness level. 🙂 In this case, light blue alludes to the “Lite” part, and of course that means the application will be free.

I’ll try to distribute all free utilities over both the Mac App Store and my own site; non-free utilities are intended to be MAS-only, if possible. The ultimate intention is to substitute my very old XRay utility by a group of small, focused programs. More on that later…

I had just published my previous post about Mountain Lion and Gatekeeper when Apple announced the third postponement of the sandboxing deadline for the Mac App Store, this time until June.

This was expected; given the announcements and the changes in the sandbox details (including some unannounced ones which I can’t comment on), a postponement was inevitable. In fact, my hunch is that at WWDC 2012 a final postponement will be announced, to coincide with the golden master of 10.8; or, at the very least, 10.7.4 will be back-fitted with the same Gatekeeper and sandboxing capabilities. This latter option has a potential pitfall; Xcode doesn’t like applications setting their minimum system version to a point release.

A brief recap of the sandbox is in order. If the developer turns on sandboxing, the application will run inside a protected environment. The user’s home folder is substituted by a per-application container where parts of the original home are reflected by symbolic links. Certain folders, such as ~/Library and ~/Documents, are not reflected. A sandboxed application’s system calls are closely monitored and restricted. The intention is that the application cannot interact with other applications, or with other app’s documents – not even with their preferences. However, some parts of the file system can always be read, basically to allow the application to use system resources.

These restrictions can be selectively eased either by a signaled user intention or by a list of so-called “entitlements” set into the application signature. Entitlements can allow access to iCloud, to selected hardware such as networks, cameras or printers, to user databases such as calendar or address book, or to parts of the file system outside of the application container such as music, picture or movie folders. Access to files can be granted as read-only or read-write.

User intentions can be signaled by actions such as dragging & dropping icons from the Finder onto the application’s icon or windows, or by selecting files/folders from the standard open or save panels (and there are entitlements for that option). This opens a temporary breach in the sandbox for that run; starting with 10.7.3, this access permission can be stored into a bookmark file for later use by the application.

Temporary exemptions can be granted to allow the application permanent access to any part of the file system, however Apple advises that such exemptions may not be allowed for apps in the Mac App Store.

Many other actions are restricted by design, and there are no entitlements to allow sandboxed apps to send AppleEvents to other apps, to use the Accessibility APIs for controlling other applications, and so forth. Add that to other restrictions already in place for the Mac App Store – such as not allowing privilege escalation by asking for an administrator password, system preference panels, etc. – and it’s understandable that developers are viewing the forthcoming sandbox requirement with trepidation and even anger.

On the other hand, for the user, sandboxing has its advantages. Losing data by program bugs or malicious code is restricted to the few places where read-write access is granted. Applications that “phone home” won’t be able to do so unless network access is allowed by an entitlement. If the entitlements are carefully chosen and restricted to the exact functionality of the app, everything should be well.

Unfortunately, the current entitlements are relatively few and more related to Apple’s initial ideas about what type of app should be on the Mac App Store – a game or relatively simple document-based application, perhaps. Now that Gatekeeper will be allowing “identified developers” to sign applications, Apple should also encourage these developers to use the sandbox. Well-known developer Daniel Jalkut says that the sandbox should be expanded:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out…

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps…

Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions.

I agree fully with Daniel but would like to expand his proposal even more. We need more fine-grained entitlements that also encompass things that are currently done by older methods. For instance, to interact with other apps over the Accessibility APIs, application’s binaries need to be blessed with the old Unix setgid bit – or the user has to be oriented to allow all and any applications to do this. This would be easily solved by a specific entitlement. No doubt some entitlements might be restricted to administrator-level users. All in all, expanded entitlements will be in the general interest.

All that’s missing is an easy way of communicating to the user what entitlements the sandboxed application has set into its signature. Rather than do this in the security preference pane, I’d like to renew the idea I mentioned in my previous post: an information panel that’s shown on the first run for a signed application (and easily found by the user for re-checking thereafter). Besides showing information about the code signature and the authoring developer, this panel should also show a concise explanation of the entitlements requested by the application; with that information, the user can fully decide whether running that app will be worthwhile. Hm, why does this game want access to my Address Book, to the Internet, and read/write access to my entire hard drive? Looks suspicious…

This would take care of applications signed by identified developers. Unsigned applications that run without a sandbox should rightly be viewed with some suspicion. I don’t see many arguments in favor of anonymously-authored applications, but in any case, with the upcoming model, the user always has the option to make exceptions.

There remains great controversy about what was, until a few days ago, the main use for the sandbox: in Mac App Store applications. There was no incentive for non-MAS apps to be sandboxed, and Apple seemed to be unyielding in expanding the available entitlements – the gist on the developer forums seemed to be “either fit in the sandbox as it is or don’t sell over the MAS”. There are temporary exceptions and some (very few) developers got personal workarounds, but it all feels very constraining. In my opinion, it’s extremely worthwhile for developers to file feature requests for the sandbox outside the MAS. After all, it’s in Apple’s own interest to see wider sandbox adoption, and the hope is that some of those new entitlements will – after some time – flow back to benefit MAS apps.

Who knows, perhaps Apple will, in time, allow identified developers to sell iOS apps outside the App Store? It all depends on how successful that model is on the Mac. After all, confluence should go both ways!

Update: I just found Uli Kusterer‘s article about the sandbox which makes several of the same points, including one I’d forgotten to mention above: entitlements could easily refer to other applications just by mentioning their bundle ID (and perhaps, distinguishing between sending AppleEvents to that app, accessing their preferences or sandboxed files, and so forth).

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

Herewith a much-delayed status update.

Our cruise has been quite interesting, there still are two weeks to go. To make a long story very short, we’ve visited Robinson Crusoe Island, Rapa Nui (a.k.a. Easter Island), stopped off Pitcairn (but were unable to go ashore), then Raivavae, Papeete on Tahiti, Moorea, Bora Bora (all in French Polynesia), Rarotonga and Aiutaki (Cook Islands), then Nuku’alofa on Tonga, Levuka and Suka on Fiji, and finally Norfolk Island (which belongs to Australia).

After that, the ship stopped at a variety of ports on New Zealand: the Bay of Islands, Auckland, Tauranga, Napier, Wellington, Picton, Lyttelton (the port for Christchurch), Dunedin, and (today) the Stewart Islands. Soon we’ll be on our way to Tasmania, visiting Port Arthur, Hobart and Devonport, finishing off with two days each in Melbourne and Sydney, both of course in Australia. From then on it’s a long flight back, with a two-day layover in Buenos Aires. We should be safely home by the end of January.

Whew.

On the app development front, much progress has been made. The generic app framework is mostly ready for prime time – it works well with two of the three application types that I plan to release, and I’ll start testing the third type tomorrow. The architecture looks very plug-in like. However, the current incarnation of the Mac App Store doesn’t allow selling plug-ins, so the generic app is a static library linked to what would otherwise be the plug-in; there are some standard nib and graphics files, and specific files for each application. I’m quite satisfied that this will make it easy to implement new apps down the road.

Details on the apps themselves are still not ready for release, as I first plan to do a short but intense private beta program as soon as I get back home – the on-ship Internet has download speeds very like in the old 28800-baud modem days, and the upload speed is almost zero. If you’re an interested fellow developer, feel free to email me and I’ll be in touch.

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!