At WWDC ’06 I was looking over the session list and picking out all of the ones they didn’t announce ahead of time when one of them stood up, extended its finger, and poked me right in the eye. “Code Signing”. There wasn’t much of a description, but there didn’t need to be.

The place was packed. I was obviously not the only one to think this was an important session. And for good reason: we are starting to see how code signing is gradually but deeply changing the nature of the platforms we work on.

Code Signing Background

Like most technologies, code signing itself is neutral, or ought to be. It can be used for good or evil. Code signing is basically a way to cryptographically prove the origin of a particular piece of code, nothing more.

The way things are built today, there are really two kinds of code signature. Or more accurately, there are two types of certificates used to sign code. There are self-signed certificates, where the certificate is created by the signer and has no connections with the outside world. This sort of certificate says absolutely nothing about the signer, but it lets you know that two pieces of code were signed with the same certificate, and therefore presumably by the same person. And then there is code signed using a “real” certificate, which is itself signed by a certificate authority. This means that the authority vouches for the identity of the certificate owner, generally by obtaining some sort of government identification from them. If you have code signed with this kind of certificate, you have good assurance that it was signed by the person whose name appears on the certificate, and is thus as trustworthy as they are.

Apple currently uses these capabilities in a few beneficial ways. There are several pieces of Mac OS X which depend on knowing the identity of an application. For example, the keychain tracks per-application access privileges. The Leopard firewall can be set to only allow access to certain applications. Parental Controls allows a user to determine which apps another user is allowed to run.

Many of these things existed before code signing (which is to say before Leopard), but they were relatively fragile. Every time you updated an application the system would have to treat it as if it were a new application. With signed applications, the system can see that an update came from the same people and should therefore have the same level of trust as the old version, so it doesn’t have to re-prompt the user for keychain access or any of the rest. This is good for users and it’s good for developers.

(There is a certain amount of faith involved here. Anyone who has used enough software should know that the next version of something isn’t always equally trustworthy. Apple’s decision to always give new versions the same level of trust is interesting and not entirely obvious, but this is a subject for another day.)

Apple also uses code signing in some odd ways. For example, OS X includes a function called task_for_pid() which, among other things, is basically the gateway for things like mach_inject. Back in the old days, basically early 10.4 and below, this could be called on any process owned by the same user as the caller. Sometime in the 10.4 days this changed to require the caller to be either root or part of the procmod group. This makes sense; code injection is dangerous and requiring approval from the user is a good thing. On 10.5 the rules are the same for unsigned apps, but signed apps can get a free pass. This is strange. Apparently Apple believes that having a signature automatically makes an application “good”, or that merely being accountable is enough of a barrier.

Code Signing Going Forward

Apple clearly plans to take this further. Here is a choice quote from Apple:

SIgning [sic] your code is not elective for Leopard. You are *expected* to do this, and your code will increasingly be forced into legacy paths as the system moves towards an “all signed” environment. You may choose to interpret our transitional aids as evidence that we’re not really serious. That is your decision. I do not advise it.

This makes sense for APIs such as the keychain where being able to identify the source of code is useful. But how many such APIs are there on the system? Where else can you be forced onto legacy paths for having unsigned code?

Apparently the answer is “everywhere”:

In order to achieve the nirvana of only running valid code, the system must completely refuse to run unsigned code. Since that would really have ruined third party developers’ Leopard experience, we don’t do that in Leopard (except for the Parental Controls and firewall cases, where we surreptitiously sign unsigned programs when they are “enabled” to run).
Eventually you will all have signed your recent releases, and we’ll have fixed all the (important) bugs and closed all the (important) holes, and a switch will materialize to this effect – to refuse (at the kernel level) to run any code that isn’t valid.

What purpose does this serve? Remember that being signed only tells you about the origin of code, it doesn’t tell you if that code is good or not. And self-signed code doesn’t even tell you that: it only lets you determine that two pieces of code signed by the same entity actually came from that entity.

The iPhone SDK

The answer to this might be found in the iPhone SDK. Just released, it offers a development environment very similar to the desktop edition of Mac OS X. All the standard UNIX stuff is there, many APIs are the same, and many (such as the GUI parts) are similar but adapted for the mobile environment.

However, the environment is different in one important way. Apple is the gatekeeper:

Phones will only run apps signed by Apple. It also applies FairPlay to the package.

Even for local development, you need to get the code signed. The iPhone SDK is free, but by itself it won’t let you load apps onto an iPhone. When you pay Apple the $99 to enroll in the program, they send you a certificate which can be used to sign your applications. However, they will only work on iPhones which have been provisioned with this certificate.

To distribute your application to other people, you must go through Apple, and Apple has explicitly stated that they are going to be vetting the apps before they give their blessing. Steve Jobs identified six types of bad behavior which would cause them not to sign an app:

Illegal

Malicious

Unforeseen

Privacy

Porn

Bandwidth hog

Some of these make good sense. Malicious apps and apps that violate your privacy are bad. But then again, Apple’s definitions of these may not agree with yours. Bandwidth hogging apps are something which need to be regulated to keep the EDGE network up and running, assuming that this only applies to EDGE. On the other hand, there are cell phones which can run any code without vetting by the manufacturer and none of them have destroyed a carrier’s data network. Apple probably has little choice but to block illegal apps, but once again Apple’s definition of illegal is not going to be everybody’s. I can only assume that they will be applying the legal standards of California, USA to all apps, even if the developer is in Lithuania and the user is in Italy.

And then we have “Porn”. You have to wonder why this is on the list. As long as the application doesn’t hide its nature there’s nothing harmful about it, it’s generally legal, and a porn application can be just as well behaved toward the EDGE network and toward the user as any other application. Apparently this is on the list just because some people think it’s morally wrong. Apple may or may not believe this, but they at least think enough people will that it’s not worth allowing. So now Apple is making moral judgements of the apps they sign.

The most worrying one on the list, of course, is “Unforeseen”. This is basically a catch-all intended to give Apple an out in case anything comes up which they don’t feel like letting onto the device. Maybe some new class of evil app is developed which doesn’t quite fit into the above categories and Apple needs to block them. Or maybe Apple just doesn’t feel like having any competitors in a particular market, and wants to shut them all out.

Compare this to the current situation on the Mac. I can develop, distribute, and install programs which Apple has never even heard of. I have absolute freedom to do as I wish in this regard. This means that I have the freedom to install bad stuff which will destroy my system or spy on me. But it also means that I have the freedom to install good programs which Apple wouldn’t approve.

The Future

Ultimately I think the trend is bad. Code signing itself is a neutral technology, but it gives incredible power to the system vendor, and that power is just waiting to be exercised and abused. I believe that the iPhone is serving as a testbed to see how users and developers will react to an environment with ubiquitous code signing and control. If it goes well I think we can expect to see our desktop Macs gradually move in this direction as well. Judging by how badly Apple’s developer servers were flattened during the SDK release it seems like there’s no way it won’t go well.

I’m sure it will be a gradual process. If 10.6 ships and suddenly nothing will run without Apple approval there will be a huge revolt among users and developers. In 10.5 it’s pretty much innocent. In 10.6, given what Apple has revealed, I would expect to start seeing some restrictions in place. Perhaps initially there will be some APIs which are only available to signed applications. At some point Apple will decide that there are some areas of the system which are too dangerous to let anyone in, even when signed. Perhaps you will begin to need Apple approval for kernel extensions, or for code injection, or other such things. Then one day Apple may decide that unvetted code is too dangerous. Maybe advanced users could still be allowed to use it, but a setting may show up, “Allow unapproved applications”. It will, of course, be off by default.

Would life really be so bad in such a world? After all, even in the worst case, hacks would no doubt appear to disable the signature checks. But at this point the ecosystem has been severely damaged. Any application which requires such a scary setting to be changed is not going to get a very large audience. This is bad news for the developer. And with such a reduced audience, the amount of such software made is going to be much less, which is in turn bad news for the user. It could very well be a wonderful environment for the average Joe whose every need is met by Cupertino-approved wares, but it’s certainly not the kind of environment I want on my desktop.

70 Responses to “Code Signing and You”

Uli Kusterer says:

One reason for the porn exclusion could be international law. For example, in Germany, distribution of pornography via mail order or online is severely restricted, you have to prove you’ve done age verification (though this is usually done through credit cards, which Apple could do, too), etc. etc. If you consider all the differing (and conflicting) laws on this topic that exist internationally, Apple may just have decided that this was more hassle than it’s worth …

Christian says:

Paul says:

I believe the issue you guys saw with commenting was related to Live Preview + WP-Cache. I’ll have to see what I can find, but it shouldn’t bite you right now.

Uli: For some things, this might be so. But for instance, Apple has said they’ll block VoIP over EDGE. Is that beneficial to users? Or just to Apple and/or AT&T? And as noted, “Unforeseen” is a catch-all. Will they use it to block apps that users want? Say, per Gruber’s example, the Amazon MP3 store?

Steven: I don’t have a slew of examples off-hand, but the Amazon MP3 store is a darned good one. As well, as I noted in a couple of the links from yesterday, maybe they won’t allow Airfoil, because it mucks with AirTunes. Or maybe they wouldn’t let us make a ringtone editor, because they sell ringtones. How about a radio player? They sell music, why should they let people stream it? Most anything we’ve considered seems like potentially, they’ll say no.

As a developer, that stinks, of course, but I think it’s also a very bad thing as a user. I’ve seen comments to the effect of “Well, there’s lots of crap on Palm, this will keep it off”. I don’t think that’s so, but even if it is, so what? You don’t have to use the crap, and some people won’t think it’s crap at all. Giving people choice is the basis of the best power structures, and unfortunately, it looks like we’re not seeing that here.

Kalle says:

Regarding code signing… I’m hoping the adverse reactions even inside Apple in the light of disabling a thing like MacPorts from installing and updating a bunch of nice stuff would prevent the whole thing from happening.

Regardless, telling them explicitly that it’s not gonna fly is welcomed!

Mark Hughes says:

For the desktop user, security and accountability is a huge benefit. Right now there are no viruses and very few trojans for the Mac. With code signing, trojans become difficult bordering on impossible, and can be tracked and shut down if they do appear. The Palm is a great example of what happens with an unprotected development space. It’s a big ecosystem, but it’s full of crap, 90% of which is useless or dangerous.

A developer always has the option of self-signing an app and running it. A normal person, who would want to be protected from malicious apps, wouldn’t have that option (or could turn off all protection and live dangerously).

Yeah, this is a big change from previous OS’s, but it improves the Mac experience in ways that outweigh the annoyance for most people.

leeg says:

Mark has hit the nail on the noggin here. As a paid-up FSF member I expect to be able to be free to run anything on my computer. A lot of other people don’t care, they want their e-mail and web programs to run without sending their credit card number to Nigeria. And if code signatures give Apple an easy way to assure that, while also claiming extra revenue from the developers who have to buy in to the deployment program (I’m not saying that’s on the cards for the Mac though…), then they’ll jump at it.

Rob Meyer says:

I’m torn. I feel like the eventual direction of code signing is critical for a platform like the iPhone, but it sucks that it can be used to inject politics, morality, or vendor revenue prediction as well. A double-edged sword for sure.

Bottom line, I’d rather have the SDK out there, even with Apple control, then not have it.

Side question; once the firmware requires code-signing, isn’t that going to then require some wizard-level hacking on the part of the existing dev community to get back in? You’d have to find an OS-level exploit right? And it would have to be exploited via an application that got past Apple security and posted on the store for signed execution.

Dominik Wagner says:

While the possibility for Apple to not-allow any App as they see fit is rather scary i am wondering much more about the practical implications.

just have a look at versiontracker/macupdate: what herd of people should check all this before it will be added to the store. I see a serious bottle neck coming up. Starting with the “avialable to a limited number of developers in the U.S. and will expand to other countries in the coming months.” bit. Since the Emulator runs on x86, doesn’t even simulate core location, the accelerometer or opengl and on some corners even the underlying OS shines through is pre-developing without a key kind of pointless. I’d guess they will be so overwhelmed with the response and handling of the U.S. developers alone that we sad european folk will just be left behind.

That is really troubling me.

Mike says:

Mark: The difficulty of trojans depends greatly on just what sort of signing regime is implemented. Anything which allows self-signed apps is not even a speedbump, and even regimes which allow arbitrary official certificates won’t do much. A regime in which Apple is vetting every single app before allowing it to run would help, but even this will depend on just how thoroughly they’ll check. The general feeling right now is that they are not going to check things very thoroughly simply because they won’t have the manpower, and that most of the protections will rely on being able to shut off distribution after the fact. Even if they do their utmost to check every app for trojans, a simple clock-based on/off switch will defeat it.

I’m worried that so many commentators on this issue are seemingly ignorant of Sturgeon’s Law. 90% of everything is crap, and forcing everyone to go through Apple isn’t going to change that. It may be successful in changing the nature of the crap to be somewhat less evil, but it’s not going to result in an iTunes App Store full of nothing but awesome.

I addressed the ability to disable checks in my article, but just to recap, I think that it will do a vast amount of damage to the application ecosystem simply by having it on by default, so that having the option is a hollow victory. In any case, the iPhone does not have any such option. You either pay your $99 to Apple and wait for their approval or you only run apps from those who have. (Or, of course, you hack the device as people have already been doing for quite some time.)

leeg: As I said, this may well be fine for the hypothetical “average Joe”, but that doesn’t mean I have to like it, or that I think it’s even a good thing overall.

Rob: I think everyone agrees that this SDK is better than no SDK, and I’m no exception to that. But it’s a somewhat meaningless statement: any official way of making apps is better than none, but that doesn’t make it good. As for your other question, to my knowledge this is what has been done with iPhone “jailbreaks” so far anyway, so not much would change in that respect. OS and app level exploits are guaranteed to exist as long as humans are building them. But the population of people willing to jailbreak their device is likely to shrink significantly once the App Store opens, so the audience for developers on the fringes will likewise become much smaller.

Pete says:

I find it very alarming that Apple will act as a gatekeeper and says what people can and can’t have. For me it’s a restriction on my freedom. Of couse, game consoles are even more closed systems than the iPhone, but it seems not many people are worried about this.

For example, who’s gonna pay for the certificate to get open source apps on the iPhone? Will Apple allow one developer’s certificate to be used to sign thousands of FOSS apps? Is ScummVM an interpreter that’s banned by the SDK licensing terms?

I’ll seriously consider if I’m going to be interested about the iPhone if it’s going to look like Apple will be exercising it’s power too restrictively.

The iPhone is a mobile computing platform for me. Technically it is the best, years ahead of others, but politics can ruin it for me.

LKM says:

Excellent article. I recognize and agree with all the issues you’ve mentioned. I’m thinking of something much more immediate, though: How do I beta-test my application? I can’t give it to my friends to test unless I have Apple sign it. Can I get Apple to sign code which is then not sold on the store? Why can’t I use my own, non-Apple certificate to sign my code, and then simply tell an iPhone to accept code with that signature? That would keep iPhone secure (since you would have to add the certificate to the list of accepted certificates), and it would give developers a way to run their own code without Apple being involved, and to give applications to their beta testers or friends.

How do I give out review copies to Macworld or other magazines? Do I simply refund them for the money the app cost on the store?

Snafu says:

The most obvious one would be your generic Strip Poker game and porn screensaver, but then you have, for example, the Japanese erotic game genre (which, by the way, is full of amateur-developed titles). So this is not quite that minor an issue, commercially speaking, I guess.

Josh Bryant says:

One thing I can throw in the discussion is the aspect of customer support. I may even go as far as saying this is probably Apple’s primary reason.

You can imagine the myriad of support calls and appts because some app broke some poor users phone. The stock answer of “we don’t support 3rd party applications” or “A 3rd party app caused this so we can’t help” won’t do much because in this case the customer has downloaded it from iTunes which has the appearance of Apple giving the app their stamp of approval – whether technically they have or haven’t.

I know there are tons of points on this aspect … but I at least wanted to introduce it into the conversation because I’m sure its a top one that’s being weighed internally @ Apple.

Mike says:

Josh Bryant: You make a good point, and indeed I would never expect Apple to allow arbitrary apps on any iTunes-based store. The problem isn’t that Apple restricts what’s available through the iTunes store, but rather that Apple provides no alternative venue whatsoever. In a reasonable world, you could go through Apple’s vetting process and get listed on the iTunes App Store, or you could bypass Apple and sell directly. In the world we have now, you either go through Apple’s vetting process or you do not distribute your app in any form.

It’s also interesting to compare with the iTunes Music Store. As we all know, Apple allows you to put music on iPods from any source, not just iTMS. And in fact the iPod’s file format handling is rather buggy in places, something we here at RA get exposed to more than most. A badly formed file can cause an iPod to become sluggish or even crash. But despite this, Apple doesn’t appear to feel any need to restrict the music which can be placed on the device just to keep people from breaking their iPods with bad files.

Patrick says:

I’m worried that so many commentators on this issue are seemingly ignorant of Sturgeon’s Law. 90% of everything is crap, and forcing everyone to go through Apple isn’t going to change that.

If we’re quoting Sci-Fi laws, I’m surprised that you’re unaware of the First Law of Kipple: “‘Kipple drives out nonkipple.” Where kipple is defined as useless crap that self-perpetuates.

The 90% of crap that is on the Mac is not that comparable to the 90% of crap on PalmOS or Windows because user expectations for non-kipple are much higher on the Mac. The First Law of Kipple trumps Sturgeon’s Law because the latter is not comparable between sets. Even well-established companies on the Windows side of the fence pump out crap that would get you laughed out of Macupdate or Versiontracker.

I don’t disagree with most of what you say, but I do think that the ” iTunes App Store [will be] full of nothing but awesome” for some values of awesome.

Tom says:

I don’t think excluding “porn” is an unreasonable move for Apple, since they are the also the distributor of these applications. I’m sure Apple doesn’t want to be in the business of distributing porn, regardless of the question of “morality”.

Paul says:

Tom: But that’s the problem – Apple is the ONLY distributor of applications. They set themselves up that way, but it’s not as if that’s a requirement. If they have their own store, but developers can get on in another way, then their limitations are fine – it’s their store. But as it is, they’re the only way in, which means any limits they set affect everyone, with no way around them.

Rob says:

Michael Mrozek says:

Microsoft implemented the same idea when they first made the XBox. All XBox games are digitally signed by Microsoft, and the console will refuse to play unsigned games, which means Microsoft can distribute the SDK to anyone that wants it while still maintaining complete control over who they let actually market software for it.

VM says:

The iPhone is only one of many smart phones. As a user if you do not approve of Apple’s restrictions on apps that the phone will run don’t buy one. As a developer if you do not like Apple’s restrictions develop for MS. No one is holding a gun to your head. On the other hand the evolving iTouch/iPhone ecosystem can provide an excellent source of income for many independant developers which IMHO is a very good thing.

V.M.

Adrian says:

‘And then we have “Porn”….Apparently this is on the list just because some people think it’s morally wrong. Apple may or may not believe this, but they at least think enough people will that it’s not worth allowing. So now Apple is making moral judgements of the apps they sign.’

I suspect you’re off track here Mike. It’s probably a decision based on taste, not on morality. That sounds much more like Apple.

Akbar says:

VM, I don’t see the point of your comment. No one said they were forced to develop for iPhone. They WANT to, but they don’t want to be shut out because Apple’s the one letting in apps. “Love it or leave it” is such a childish notion. They’re trying to change things.

Mike says:

Akbar: You got it right on the nose, thank you. The iPhone is a great device. It has wonderful (and very powerful, despite what many people are saying) hardware, beautiful design, and nice software. It is, however, killed for me by politics. First by the forced dependence on AT&T, then by the prohibition on third-party software, and now by this sort of halfway world where some third-party applications are vastly more equal than others. I’m very much aware that nobody is holding a gun to my head. I don’t have an iPhone, and I only just got a Touch for development work. But it has such potential to be a great platform, I want it to be a great platform, but it isn’t one. So instead of just watching this happen, or switching to some other vendor, I am going to do what I can to change it.

Even more to the point, the general thrust of my article and my biggest fear isn’t that the iPhone will end up being a sub-par platform because of this. If that happens it’s no big deal. I’m not particularly invested in it. My biggest fear is that it’s going to serve as a testbed for desktop Macs, and that in a year or two or five we’re going to wake up and realize that they have become as locked down as the iPhone. The infrastructure is there and the culture is there. Apple’s intent is unknown, but this is something which can happen.

rafa_n says:

michiman says:

I would already have bought an iPhone if it wasn’t restricted to one particular net carrier. I was going to get an iPod Touch instead as soon as they bring the 64GB version. This policy will keep me from buying one. If Apple continues like that, they are digging the grave for a great product.

Anders says:

Ztheiphoneman says:

If you want to develop shareware applications that you would like to make money on, then yes, going through apple would be the only way to reach an audience that would be able to pay for your stuff. But if you wanted to develop a wifi sniffer or an amazon mp3 store, or an AIM clone (apollo). You do not have anything stopping you now or in the future. Everyone can already 1 click update to iphone 1.1.4 with a custom installer that bypasses any store apple would have…. also… checkout iphone owned. iphone dev team has already bypassed the code signing procedure at an OS level. so you can patch and install your own .ipsw from ITUNES that allows unsigned code. if you want to develop for iphone without apple you have and never will be blocked… if you want to sell your apps to people on iphone, then you have to go through apple. OR.. you have to set up your own website that lets people pay for the software, you send them it, and have to rely on them knowing how to jailbreak and unlock their phone… which is everyone who isn’t on AT&T in the US with an iphone, and a handful of enlightened AT&T users.

Giovanni says:

“Let me repeat that: if Apple doesn’t sign your iPhone app, it does not run.”
–
That is the end of my iPhone. Apple will do this on Macs as well if it works out for the iPhone, this is not hard to predict.
All for my personal security and moral integrity, of course.

conigs says:

While in general I agree with the tone of the article, I have to question the quotes from “Apple” you mentioned in the background section. Clicking on those links takes me to comments made by “Perry The Cynic” who does not appear to be an Apple employee.

Could you elaborate on how you extrapolated these comments to be from Apple?

Jason says:

I knew that code signing was coming with Leopard, but I had no idea of Apple’s plans to eventually restrict the use of unsigned apps. Although they might manage to get it right somehow, the very idea of mandatory code signing gives me a bad feeling deep in my gut.

I would actually like a special opt-in “Apple Certified” program for the desktop, which would create a happy walled garden of “safe” apps for the typical user. They could even start distributing Mac apps over iTunes as well, making those kinds of apps even easier to install and find for the typical user (I should patent this business method before Apple makes any moves!) If Apple starts blocking unsigned apps by default, however, it would be enough to scare me off this platform completely!

—ryan says:

>Apple doesn’t appear to feel any need to restrict the music which can be placed on the device just to keep people from breaking their iPods with bad files.

Yes, but you also don’t pay $70 a month for your iPod to work. If a bad app takes down your *phone*, there will be some massively pissed people and that threatens the continued revenue streams, not just the purchase price of future hardware.

Mike says:

conigs: I’m not sure what you saw to indicate that Perry isn’t an Apple employee. To the best of my knowledge he is one. Aside from the obviously authoritative tone of his posts which I quoted, a bit of googling will find Perry authoring a Mac OS X man page about security, talking about WWDC from the perspective of an Apple employee, and sporting an apple.com e-mail address on a mailing list called “opensc-user”.

—ryan: I also don’t pay $70/month for my iPod Touch to work, but all of these restrictions hit it just as much as they would an iPhone. In any case I don’t see the point of this argument. If I pay a monthly fee for a service needed for my device to work, does that somehow make the device less mine? I maintain that I should be able to load the software I wish onto the devices I own. If it’s difficult because the device isn’t designed for that then it’s one thing, but if it’s difficult because of artificial restrictions meant to keep me safe from myself then I’m not going to be happy about it.

Greg says:

This “bad app” red herring really pisses me off. Every smartphone platform in existence to date has permitted unsigned applications, and nobody’s phones have crashed due to them. No networks have been destroyed by VoIP over EDGE or EV-DO. The solution to “bad apps” is to say “We’ll vet some apps and put them in the App Store, but we won’t vet every app. If you want to install an unvetted app, you’ll have to self-sign it.”

This whole thing would be about 1000 times less odious if Apple would let you sign things with your *own* cert and put them on your phone. I shouldn’t have to pay Apple $100 for the privilege of running my apps on my phone.

hrissan says:

Guys, most people in the world would sell their freedom for security, you should know. And you should know also nothing can stop “rebels” from breaking rules even for the price of their life. You cannot stop rebels but you cannot also make significant money working in their interest. So I’m happy using unlocked jailbreaked iPhone in the middle of Siberia and planning to sell my software through iTunes store. I do not afraid code signing on Leopard as well. Nothing can stop me from running whichever software I like to. So have peace in your soul and be happy. :)

AkitaOnRails says:

Risking being called a fanboy, let me point the obvious: Apple is a corporation that needs consumers to survive (profit). Signed apps is not a new trend. The technology is available in most platforms for years. It doesn’t take too much to lock down an entire system (not perfectly, there’s always loopholes, but I digress).

The Mac market is competing with a huge mass of Windows and another good slice of Linux in the market. Unless they eventually become ‘the’ dominant platform, there’s no reason to commit suicide that way. Ok, we don’t know what Apple is thinking. But think for a second: you run the company, what would you do?

The smartphone market on the other hand, has no clear leader. It is very dilluted between several different players, Apple being the most recent of them. Consumers (not developers or alpha geeks) see it differently as well. It is not a PC, it is a cell phone primarily that can also serve as a communication device and sometimes as an entertainment toy. It will not replace their PCs, no consumer expects that. They expect it to be a trusty companion on which they can depend on.

Most people doesn’t give a crap about downloading Apache on the phone, or Python, or Amarok. No one likes multiple choices. They bought the device for what’s in there. Safari works well most of the time, there is little reason for – on a cell phone – have Opera, Firefox and whatnot. The basics are already there. Some people would like to customize it a bit more, for that they will have some alternatives in the App Store (not Firefox, though, for what I heard). No one is gonna complain for what is not there. They will complain though if they pay money on something that doesn’t work as advertised, and it doesn’t matter where it came from, the first brand hurt on this will be Apple’s. I can already see the magazine titles “Apps delivered for iPhone makes consumers unhappy. Apple to blame”.

So, better be safe than sorry. As this is not a certain market you go by the book: you start with a tighten up leash. For instance: june 2007, no way to develop anything. You hear the market, you hear the feedback. Mar 2008: you get the SDK, but there are constraints.

If the market – mass of consumers, not hobbists – demands more, and it starts to become bad PR, what would you do as CEO? You loose the leash a little bit more. That’s the dynamics.

For now, as a developer, we can choose: do we want to profit on the iPhone market? So, in a myriad of thousands of possible legal apps to make, why choose exactly those that are banned? Feels childish to me. Make a Wallet app, games, calculator, calendars, todo lists, notes app, whatever. Leave the porn for another day.

It leaves us nowhere being paranoid. We waste time instead of spending it thinking on the next big app to develop.

Bottomline: maybe the iPhone is a test bed to tighten up Mac OS in the future? We can’t say for sure. For one thing is certain: that would be suicide, people would simply migrate back to Windows or Linux or whatnot. It’s that simple.

But while you’re in a world of hurt if your computer crashes & loses your data, it’s a whole different, non-physical world of hurt than what happens if your phone dies while you’re stuck on a snowy road in upstate NY.

As for image…you don’t carry your computer everywhere and use it constantly while you’re out on the town. But your phone does go everywhere, and it becomes an image-maker for Apple. And I guess they don’t want porn to go with that image. I don’t think they should forbid porn, but I see what their thinking is.

Mike says:

Jason: I don’t think Apple will require signing all OS X apps someday, but I fear it. The trend is in that direction. The only question is where it will stop. I don’t want to sit around waiting to see what happens, I’d rather draw attention to it and do what I can to stop it early.

People know that PCs are tech-y devices that crash, get viruses, etc. They generally come to the Mac to get away from all that stuff, and for good reason. I don’t know what Apple’s thinking is, but I can certainly see that they may believe greater protections are needed to preserve this reputation as the Mac gains popularity.

As for having your phone die while you’re stranded somewhere, there are two solutions for this. One is to have a reasonable operating system: a good OS should not allow arbitrary apps to stuff up the device, and you don’t need draconian code signing restrictions to accomplish this. And the second is to limit your personal exposure to dodgy apps. If you’re going to be putting iffy apps onto your phone then you should realize that this may make it less reliable, but that should be your choice to make.

Akbar says:

@Akita: Might Apple open things up? Sure and that’s the point here, to convince them that they need to do so. But to call the desire to make any app “childish” is just foolish. Rogue Amoeba is arguing for an open market, Nd that’s not childish in the least.

The idea that people won’t complain about what’d missing is certainly wrong but its not even the point. There have been countless times when people thought what we had was good enough. Then along came a better search eninge, google, or a better way to buy music like the iTunes store. It seems to me that the desire here is the same, to be free of constraints.

LDJessee says:

The problem I have is after working for months on what I think is going to be a great application. I polish it, remove bugs, tweak it and get it all ready for this summer. When the time comes, I am told no, for whatever reason. What do I do about all the time spent on the application? My investment in their programming language, API structures, etc was wasted.
What recourse, what alternative do I have when Apple says no? Maybe they will be good enough to give me a valid reason and it is something I can fix or program around. What if it changes the feel of the application and now it is like everyone elses out there?
I have a feeling if they get to overzealous, someone will sue, probably with support from the FSF.

AkitaOnRails says:

This obviously not the same matter, but somehow reminds me of the Tivoization problem. Of course, that one was because of maybe GPL infringement, and the opinions will never be unanimous. Even Linus Torvalds has argued that it is appropriate for TiVo to use digital signatures to limit what software may run on the systems that they sell. Torvalds has stated that he believes the use of private digital signatures on software are a beneficial security tool. (wikipedia)

Brian Erdelyi says:

Code signing as a technology is neutral, however, Apple choosing to enforce usage reeks of inevitable misuse. DRM is not cool.

This also affects the iPod Touch which may run on a completely private network where Apple has no authority or jurisdiction to asset their authority. Has the legal system failed us completely that we need a new judge, jury and executioner (aka Steve Jobs)?

This is also anti-competitive and creates a monopoly for obtaining and distributing software.

What’s malicious (or legal) to one person may not be malicious (or legal) to another. If I provided informed consent for an application to run I should be permitted and accept the consequences of doing so. I happen to be a security professional and use various tools to sniff network traffic, manipulate network data in transit, perform vulnerability assessments and even penetrate systems. Many of these tools are labeled malicious and sometimes illegal even though they have a legitimate use. iPhone or iPod Touch could make an excellent tool to help do some of this work where a notebook computer may be impractical.

I also believe this will enable Apple to further lock down the iPhone and prevent unlocking while forcing us to use particular carriers (a practice which I believe is illegal in some parts of Europe).

Fuck you Apple for telling me what I can or cannot run on my iPhone or iPod Touch.

GeorgeT says:

From looking at the app restrictions and the iTunes store being the only official distribution option, I think apple is getting greedy. They make lots of money from carrier contracts and they have realized that iTunes music doesn’t just sell more iPods but also makes them money on it’s own. I seriously think they should rethink their strategy, or android might overtake them. It’s really a shame because the sdk seems great.
George T

Wikiwikiman says:

If the only “normal” way to install an application on your iPhone is through Apple and/or the iTunes Store, what am I supposed to do if I would like to develop some very personal application and use that – as the sole user – on my own iPhone? Call it a hack or a kludge, call me a hobbyist: if it’s something useful to me, why shouldn’t I be able to put it on a device that I own? Not every good idea can be implemented as a web app – especially those that are somehow linked to a function on an altogether rich platform like the iPhone.

I can understand, even applaud, the benefits of code signing – but code signing is NOT code distribution. I think we’re all better off if the two remain separate…

Jason says:

Mike said: “a good OS should not allow arbitrary apps to stuff up the device”

Well…yeah. But how many consumer-oriented OSes actually are that robust? A game from a big company can still lock OS 10.4 hard (though I don’t personally game much).

“If you’re going to be putting iffy apps onto your phone then you should realize that this may make it less reliable, but that should be your choice to make.”

Ahhhh, protecting the clueless phone user from themselves ;) Since Apple will likely never actually pre-test apps themselves, the signing is useless from a protection perspective. You can have a signed app that still kills you. And until the word gets back to Apple and it’s revoked, it will nail others too.

So what’s your position? No form of signing with any kind of implementation is good at all? What I actually like is…ALL code gets signed, with a gatekeeping authority, whose only role it is to verify that you are who you say you are so you can always be tracked down. By the end user, the OS maker, etc. Nothing else though…no selective signing (unless known to be illegal or malicious). As for revocation…what I prefer is, a user can decide, “revoke all apps by creator xyz on my system”.

ethan says:

This is identical to how verizon uses the brew structure to manage their app stack.

GM talked to us about delivering sales information via cell phones but brew is not useful for enterprise level apps. They would not put an app only for GM sales guys on their app stack so there was no way to get it on the cells. GM had a corporate licensing via verizon so there was no options. They were more interested in games and stupid ringtones.

It’s the same with apple-they are doing nothing different from the industry.

Ben K says:

I am very weary of the possible restricted future of code signing as well, but I’d rather have a pretty clear policy as Apple seems to put down for the AppStore, than the frivolous policy of MacUpdate to accept or deny applications at will.

Mike says:

Wikiwikiman: You can pay your $99 and be able to at least put it on your own device. But, as should be obvious from my post, I think this is a poor situation.

Jason: You make a good point about OS X still failing to protect itself from everything. The system-wide fragility of the OpenGL stack never ceases to frustrate me. As for my position, I want the restrictions to be optional. I’d also like the default position to not require Apple approval, but that’s secondary. Mainly I just want to be able to put the software I want onto the device I own without feeling like a criminal.

ethan: I agree completely that Apple is not doing anything different from the rest of the cell phone industry. And that’s a big problem, because the (American) cell phone industry completely blows.

Ben K: Keep in mind that I can easily get software for my Mac without ever laying eyes on MacUpdate, but it is not possible to bypass Apple’s App Store.

Anonymous says:

>I also don’t pay $70/month for my iPod Touch to work, but all of these restrictions hit it just as much as they would an iPhone.

You got me there. I hadn’t considered that angle. I agree with you. I too would prefer if we could load whatever we wanted. I was trying to decipher why Apple would establish the limits that they have.

Perry The Cynic says:

A system that runs unsigned programs will also run modified copies of a signed program after the attacker has stripped off the (now broken) signature. Thus you cannot be sure that you’re running only “intact” programs unless you prohibit running unsigned ones. Put differently, in a Code Signing driven environment, access must be white-listed; it cannot be black-listed.

There may well be APIs in the future that will not serve unsigned clients. That by itself is not a restriction. Signing code is free, and it’s anonymous if you want it to be. You don’t gain or lose anything by signing your code, except protection from alteration by someone else (not the developer). For APIs that are interested in stability of identity (as e.g. the keychain APIs), that’s all that is needed.

APIs that want to express policy restrictions in terms of developer identity can do so. In fact, we expect a Mac’s administrator to want to do this. Note the flow here – the developer provides information about identifying his code; the administrator uses this information to decide what to run (and how). The administrator is the ultimate authority on a Mac’s security policy. I don’t expect that to change. (DRM is the exception, of course – Apple is legally required to keep you from hacking DVD Player.app, for example.)

A policy of “run anything signed” is actually the null policy – it does not restrict anything (except developers who refuse to sign their code for some reason, I suppose – but a motivated user can sign such developers’ code himself just fine). In practice, administrators will pick more restrictive run policies – but what policy they pick is their business, and Apple’s job is to make it easy to do reasonable things (and possible to do even weird things :-).

The phone is different. I understand the fears and worries and concerns, and I can’t meaningfully answer them here. For all practical purposes, at present, Apple plays the role of the administrator on a phone, and its user is just an ordinary user. I get that you don’t like that. Be sure to let Apple know.

But please understand that from where we sit, the case for Code Signing on a Mac – in the service of its administrator/owner – is very compelling. In a sense, the Mac is living on borrowed time – viruses and worms and other nasty bit-critters will surely come our way, and going to an all-signed environment is one the most potent weapons we have to keep your systems from being overrun. I realize this capability *could* eventually be abused in various ways, and I trust you’ll all keep Apple honest about it. But it can also be a powerful force *for* you.

Oh, and to put that to rest: I do work for Apple, and I designed and implemented Code Signing in Leopard. If you think it’s going to usher in a black wave of OS fascism, you have every right to blame me – it was, pretty much, my idea.

Cheers
— perry

Bertie says:

My point of view on the above issue: I agree that “a lot of other people don’t care, they want their e-mail and web programs to run without sending their credit card number to Nigeria”, so for them having signed application is fine. But on the other hand other people would like to be able to run whatever software they want on their iPhone (without being obliged to jailbreak it, I mean). For example, I’d like VoIP, and I’m not sure Apple would allow it…

The *only* problem is that Apple is the one to decide which program is “good” or “bad” (for them, not generally speaking).

Signature in itself would be OK, if any developper was able to sign and distribute its own software on the iPhone, which means without going through iTunes. Average users would then buy their software from iTunes and will therefore have Apple’s check on it (for what it’s worth, we don’t know how Apple will check that the code is not malicious: pre-check seems impossible, and post-check not very good); Other more adventurous users could buy their iPhone software somewhere else.

Unfortunately that’s not what we’re heading for.

Bertie says:

@LKM
I think you’ve got a good point about testing and alpha/beta releases.

@Brian Erdelyi
“I also believe this will enable Apple to further lock down the iPhone and prevent unlocking while forcing us to use particular carriers (a practice which I believe is illegal in some parts of Europe).”
Yes, this is illegal in France (where I live). You cannot force people to buy two products at once, i.e. in our case an iPhone and a monthly GSM plan. You must allow people to buy them separately. For the iPhone it means an unlocked iPhoned at 750€, an iPhone on the Orange network with no plan at 650€, and an iPhone with a two year Orange plan at 399€ (+ the price of the plan).
Normally for the same reason it should be possible to buy a PC with no operating system (Windows…), but the consumers associations are having a hard time trying to enforce this. When I buy a PC I get a license for Windows in a sealed enveloppe. If I refuse the license I should get a refund of the Windows OS (while keeping the PC). But this refund is impossible to get, and actually it is impossible to know the price of Windows on top of the hardware’s price in the first place.

rvr says:

i think you’ve made some good points in this post, and the concerns are valid. i believe, and i hope my faith is deserved, that locking down os x in this fashion, even if done gradually, would create such a backlash that apple would look very bad for doing it. i also think they know this. the platform has been successful and has continued to survive, especially during the dark years before jobs returned, in no small part due to the vibrant community of developers like r.m., and the core of users who have high standards in the apps they use. i must believe that apple recognizes this. i know they sometimes walk the fine line between supporting the developer community and cannibalizing it (by incorporating things as os features, etc), but i think they know if would not be in their best interest to severely piss them off or constrict the ecosystem so much.

i also hope that apple recognizes this will be the best course, in the long run, for the iphone. is it more likely that the mac ends up going the direction of the iphone, or the iphone ends up going the direction of the mac. we can only wait and see. what’s clear to me is that the community is the best place, in the long run, to vet apps and give them recognition. there will always be more manpower than one company can afford, and there’s a big advantage in having a wide range of people providing opinions. i hope apple sees it this way as well, and that the iphone ecosystem can evolve in this direction.

Nathan de Vries says:

Welcome to the world of mobile phones. You’re new here, aren’t you? :)

This has been a problem since the beginning of time. Applications need to be signed with the manufacturer or phone provider’s certificate in order to get access to integral functionality (camera, phone book, filesystem etc.). Then the phone provider decides to get greedy (*cough*T-Mobile*cough*) and strips manufacturer certs off the phones so that developers need to pay twice to play. Things get greedier and greedier as you go up the chain.

So yeah, this is not new; the whole certificate industry is messed up.

Companies like Adobe, Apple (in this case), Microsoft, Thawte, Verisign etc. have all positioned themselves so that a) they get paid under the false premise of security, and b) they retain the role of gatekeeper. Look at Microsoft: back in the late 90s they owned 5% of VeriSign’s equity. Should it come as a surprise that VeriSign is the only acceptable certificate authority for signing device drivers under Windows?

Code signing for developer identification is a good idea (I like Thawte’s Web of Trust concept), but the idea of needing to pay dozens of profiteering gatekeepers for my iPhone app, J2ME app, Symbian app and SSL-enabled web app is ridiculous. Only problem is, the issue is much bigger than Apple-targeted development.

Brian Erdelyi says:

@Bertie: Yes, France is the country I was specifically thinking about. I see a lot of similarities with code signing and selling DRM’d music that has been a hot topic in Europe.

As others have mentioned, I think this will oppress users and suppress the innovation of new applications that haven’t been conceived yet.

I think this is extortion. Some developers may be unable or unwilling to pay $99 or 30% to distribute applications. Even if signed, there is no technical reason that an application must be distributed by Apple (others are already deveoping and distributing applications now). They too are a software development company and this gives them an unfair advantage over others… it’s clearly a conflict of interest.

I like the idea of code signing so I can identify the source of an application but not so it can be used against me and force my usage of an application. Consumers should not be forced to delegate the responsibilities of informed consent to a third-party.

I like the idea of a repository for downloading applications but not one that creates a monopoly and restricts my choice to obtain software elsewhere.

Mike says:

Perry The Cynic: Thanks so much for stopping by. I really appreciate your efforts to keep the lines of communication open.

I appreciate that this infrastructure is targeted at giving the user more power over his own device, and if that’s where it stays then I’m quite happy with it. However, the sudden appearance of the iPhone SDK, using code signing to completely lock down the device, makes me pessimistic. Maybe it is fundamentally different, maybe Apple would never dream of doing this on a “real” Mac, but it makes me paranoid.

I find it a little odd that you describe an environment which only runs signed code as “nirvana”, yet at the same time admit that the simple possession of a signature is meaningless. If you accept anything that’s signed, then an attacker can merely re-sign the app after modifying it. You gain no protection from alteration, only some small form of accountability over it.

I’m also somewhat doubtful about how well this will protect from viruses and worms. All the worms will be signed in such an environment, and will appear as legitimate as they always have. A user may have to take some action to approve them, but he intends to take that action anyway since he will have to do it for any new application. It may allow an administrator to save his underlings from themselves, but that case is significantly more rare than a user who owns his own machine.

My understanding of how code signing is implemented is that it won’t detect an application whose security has been compromised by means of a buffer overflow or other such exploit. It may limit the damage which can be done by such an application once it has been compromised, but then we come back to having the exploit code re-sign any applications it modifies. Certainly you’d be able to exploit Safari’s image handling to upload all of the user’s credit card numbers to a server in Uzbekistan without needing to hit any other apps.

If Apple can resist the temptation to turn this into a tool of evil then I think it can be a good thing, although of course it is far from a panacea. But I’m afraid that the iPhone has demonstrated that Apple may not be very temptation-resistant.

One last note: I think you meant to say, “Apple is legally required to make a totally half-assed attempt at keeping you from hacking DVD Player.app”.

Devon says:

I can see how Apple can think of this as a good thing in an enterprise environment but in a home environment I should be the only one that says what can run on my computer.
If they want to have a sandbox account in 10.6 where only signed apps can run to “protect” you from viruses and trojans using code signing and only trusting root authorities, that might be an OK feature.

However, if they think they’re going to make this the default that I can’t even run my own program I just wrote without signing up for a developer account and getting a valid Apple issued certificate, I’ll just be dropping the Mac for good(been using it since my IIci). I don’t think it’d ever come to that but I’m just putting that out there.

I was initially excited that I could buy an iPhone and put my own apps on it but now that I have to pay money for that privilege even if I don’t plan on selling any applications, that really stinks. I understand they want to keep the iPhone stable for the majority of users but there should be a way for people do do what they want with the device without resorting to hacking. If it does come down to hacking the iPhone to get my own apps on there without being signed I will do it. The pre release iPhone OS 2.0 already got hacked to run apps without Apple’s signing so I’m hopeful for the future.

I shouldn’t have to be forced to run Windoze Mobile or Google’s phone OS just so I can put my own apps on the phone.

zanyterp says:

There is already a system that implements the idea of “turn it all off unless it is approved and the re-approved,” similar to what the “allow unapproved applications” might be and is one of the more…disliked features in a competing OS: the user account control (or whatever the UAC acronym expands to) in Vista.

But I could be wrong and it wouldn’t be that annoying or concerning (the warning is identical sounding when you disable it to be able to use your computer without being asked 5 times if you really want to run that application).

And I too would have issues with needing approval from a 3rd party to run ALL my applications. Let me trust the company that writes it and go from there.

Mark says:

I fully understand the nature of this essay, as well as the comments, so I realize that the following statements are somewhat simplistic:

Why do we need porn *apps*? Users can already put as much porn on an iPhone/Touch as RAM will allow, so what’s the big deal? I’m sure there might be a few clever ideas out there for a game or something, in which you undress a model as you score points (or whatever), but is the blocking of such apps really a great loss?

Many iPhone users are teens, so I’m sure that politically, Apple scores points for blocking “porn apps.” But in reality, who needs porn in the form of an “app”?

I do understand that the point, here, is freedom of choice: we should be entitled to install whatever we like on our devices. Of course I get that. I just don’t think the porn example is the best example, in particular — especially since (a) it’s already doable and (b) code signing doesn’t affect current functionality at all.

Carry on… :-)

Chris says:

No, code signing is definitely NOT innocent on 10.5. Mac OS X will actually modify programs if you’ve enabled the application-level control of the firewall. Thus it will modify all online games. If the service you’re using to play the game online checks your application to make sure you’re not cheating, it will always fail because the program has been modified.

For example, we’ll take a look at Starcraft. If you enable the firewall and set it to allow Starcraft to have incoming connections, Mac OS X will append some junk (obviously not junk, but looks like that to me) to the file “Starcraft (Carbon)”. The first time you attempt to connect to Battle.net after installing or updating Starcraft, Mac OS X will prompt you to cancel or allow. Bothersome, given the fact that Starcraft is full-screen usually, but not a problem compared to what happens next. Because Battle.net has already checked your program, you will be allowed to connect and play games. However, the application has already been modified, and subsequent attempts to connect to Battle.net will return an “unidentified application” error. After discovering this I turned off my firewall and stuck to Little Snitch for my filtering needs.

In other words, code signing is not inherently neutral the way it’s implemented Mac OS X; it’s actually inherently negative.