A Sandbox In Every Walled Garden

The Apple wold seems to be throwing a wobbly at the announcement that sandboxing will be required for all apps in the mac os app store.  People are discussing what might be a better solution, and if we might eventually only ever be able to install applications from the walled garden of the apple store .

It all gave me a sense of Deja Vu.  Weren’t we having the same thoughts over in Microsoft land a few months ago?  Are Apple developers really that out of touch about what is going on on other platforms that they haven’t noticed the parallels?  Apparently yes – I hav’t seen the words Metro or WinRT mentioned in this discussion.  Which is odd, because surely how the competition is trying to solve the same problem – and going down the paths which have Apple devs so up in arms – can feed into their strategy for how to approach our brave new world.

So, herewith, a cheatsheet aimed at showing the parallels:

What Apple Have Announced?

Mac OS apps for the Mac Os App store will have to implement sandboxing – which is to say, they will have to list a set of capabilities that their app requires, and then not make any calls which require capabilities they have not listed.  It appears (from people saying that this currently buggy and affects AppleScript) that this is enforced at runtime.

What Apple Have Not Announced That People Are Scared Of?

It might seem only a short way from there to declaring that the app store becomes the only way to install apps on your Mac.  And only a short way from there to giving Apple the chance to have a kill switch on every Mac Os application.

What People Have Suggested As Alternatives?

Certification.  Specifically having per developer certificates signed by Apple, so that if someone does something bad, Apple can revoke their trust in the developer certificate.  And ditching the whole sandboxing idea.

What Have Microsoft Announced?

If you want to use the new Metro UI, you can only use a subset of Win32 calls alongside calls to the new WinRT runtime.  Furthermore, you must specify a set of capabilities your app will be using at compile time.

The only way to install your apps will be via the new Windows App Store (this isn’t strictly true… there is a way to install developer signed apps on a developers own machines, and we are expecting to hear a way for enterprises to install apps which will presumably be more than just the App Store)

To get your apps into the app store, your app will have to pass a set of tests.  Microsoft will run these tests, but they also provide them to developers, so that developers know if they will pass.  Once MS have validated you pass the tests, MS will sign your app and put it in the app store.

One of the tests that MS will provide is to ensure you make no calls which are not allowed by the set of capabilities you have requested.  In short, the sandboxing is done prior to signing, rather than at runtime.  (This has some security issues, specifically in the area of self modifying code.  I presume MS plan to handle this via legal and social means, rather than technical)

Oh, and all your old Win32 Apps will continue to run unaffected – but not via Metro.  You will even be able to install Win32 apps via the App Store.

Have Microsoft Ever Done Anything Like This Before?

Yes.  We’ve had driver signing for years – each driver type has its own set of functions it is allowed to call, and there are any number of testing hoops you have to jump through in order to pick up a signature.  Just check my twitter stream to see how much pain WHQL causes me every so often.

This means Microsoft have experience of the real world implications of trying to manage a certification and signing scheme.  The main implications being “for every rule we lay down, there are exceptions”  generally many exceptions – there seem to be as many special cases as there are drivers.  Half of the fun of passing WHQL is convincingMicrosoft that a set of rules they require drivers to obey are wrong, or insufficient, or just plain shouldn’t apply to your driver.  The good thing is that Microsoft can usually be convinced.  Eventually.

Now, I’ve no idea if Microsoft’s driver signing experience will feed into their App signing experience, but there are enough similarities between the processes for me to guess there has been some communication beween departments on this issue.

Are Microsoft Doing Anything That Seems Wrong?

The biggest problem seems to be requiring that things are signed.  Because once you require apps to be signed, you need to sign every script you run (or just sign scripting languages – in which case you’ve lost most of the security you were aiming for).  It looks like the solution to this involves dev certificates which so far are only available via Visual Studio.  So all development will involve Visual Studio in one way or another.  (Incidentally, PowerShell has had signed scripts since day one – maybe there is some intention to integrate that architecture – but I don’t see a straight forward path).  It may be that all scripting will stay on the Win32 side of the fence.

Is there anything Apple could learn from Microsoft?

Firstly, MS are allowing old apps to continue to work with no changes.  There is no Win32 walled garden.  All the changes are only for people who want to use the new WinRT hotness.  Now, we’ve no idea if anybody will want to use WinRT, but MS do seem to be providing us with a world where people get to make the choice between two different environments.

MS are also allowing the same of old-style apps via their app store.  It seems that this will be more ‘providing a link to your companies website’ and less ‘a full integrated install experience’ for Win32 apps.  As far as I can see, its a way MS can make money while still saying ‘do this at your own risk’.  I’m guessing here that anything distributed this way may have to be an MSI – if so, you might just be giving the app store the ability to uninstall apps which turn out to be dangerous.

MS realise that there are exceptions, that app stores and enterprises won’t mix (think bespoke software), that admins have to have some control over what users install, that perhaps some software won’t fit into the model they are testing for.  Apple have always wanted to provide the user with the best experience, whereas MS are more about providing the developer with the best way to ship their software.  Apple is about fitting in around how Apple work, whereas MS is more about MS fitting in around how your application works – and we see this with the attitude towards signtime vs runtime tests for sandboxing. With Metro, MS is trying to learn from Apple, Apple could probably stand to learn a few things from MS too.

Are there any other thoughts

Moving to OS X bought Apple a whole load of developers who wanted Unixy tools on a reliable machine with a nice UI.  OS X comes with many many scripting languages which are able to access the core of the system and do everything a compiled program can do.  Do we honestly think that apple are going to restrict those scripting languages so that scripts can no longer access the system?  That one move would cause a major rupture in the dev community and harm Apple significantly.  MS can get away with it (if you want to develop for Metro, use Iron Python on top of the CLR and you’re happy – if you want to run a script, theres Win32), but without a new hotness to tie all these changes to, Apple would just be taking developers favourite toys way – and suffering the tantrums that follow.

Of course, most mac users don’t know or care abou what a scripting language is.  These will be the people who use the app store.  Just like Itunes makes it easier to get music (so fewer and fewer people bother buying CDs and ripping them to fill their iPod), the App store makes it easier to get your apps – your average user won’t consider getting apps any other way.  There is no need to restrict the techie few that the Mac software ecology depends upon.

And is Signing the answer?

Signing isn’t a flawless solution to all your problems – assume you have a killer app your system depends upon – lets say “Photoshop” for the mac.  Assume the manufacturers of Photoshop were to bring out another piece of software Apple didn’t like (I’ll call it ‘flush’).  If apple wanted to revoke the signature for flush, they could either revoke the signature on every release of flush ever made (and on the new applications ‘flish’ and ‘flosh’ that might be submitted thereafter), or they could revoke the developer’s signature and loose their killer app (and annoy many customers in the process).

Signing also requires that certificate lists are kept up to date on every system involved (or that you have reliable internet connectivity all the time)

But signing does allow for technical, legal and social means of deciding which apps to allow to run.

Most notably though – signing is really really irritating to have to do all the time – especially if you’re scripting.  I can’t see it as a real solution to the problem if you want to keep developers hanging around.  What you need is to just let people write their scripts and get on with using their machines…  By all means make developers go through some sort of hoop once to be able to script and install their own software (lets say by joining a group, or turning off a particular feature of their user account), but don’t come up with a technical solution that will only irritate.

You must be logged in to post a comment.

© Ben.Cha.lmers.co.uk
CyberChimps