Solipsism Gradient

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

Back from our 2-month trip - Valparaíso to Sydney. There’s a 13-hour jet lag to get rid of, so for now, here’s just our updated world map:

A full status update will be posted soon.

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!

In the same vein as A Kerning Game, this test makes you drag around bezier control points to make characters look optimal:

Shape Type

This is trickier than the previous one, since you have to consider what the style of the font might be like. (They tell you the name of the font but I suppose looking it up would be cheating…). I scored only 81 out of 100.

Been some time since I posted a test and this one is rather specialized:

KERNTYPE a kerning game

You must drag the middle letters into the optimal position – the leftmost and rightmost won’t move. It’s been many years since I played around with font design, and so I scored only 85 out of 100.