Code Signing on the iPhone and on Mac OS X

Mike Ash of Rogue Amoeba has written a fantastic article about code signing, and about how Apple is using it in Mac OS X and on the iPhone.

if Apple doesn’t sign your iPhone app, it does not run. 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.

Actually, if you haven’t already, stop right here and go read the article. Don’t worry, I’ll wait.

Done? Good.

Personally, I don’t mind Apple signing applications they sell on the iPhone app store. What I do mind is that Apple does not give me a way to write code, run it unsigned or self-signed (with a non-Apple certificate) on my own iPhone, and give it (again, unsigned or self-signed) to my friends who have iPhones. In other words, I want to be able to sign code with a non-Apple certificate, and I want a way to tell the iPhone to accept all code signed with a given certificate, even if that certificate has nothing to do with Apple. There are several reasons for this.

First of all, I recognize that Apple is under no obligation to make it easy for me to run applications on the iPhone. Still, I think it’s wrong for a company to serve as a gatekeeper, imposing its own morals (if a company can even be said to have morals) on the users of its devices. A technology company should enable people, not disable them. Telling its users what applications they are allowed to run is ultimately hurting them, and hurting progress. While I can understand that media companies have an incentive to hurt progress, tech companies should avoid going down the same road; in the end, it will only hurt themselves.¹

Second, it hurts the iPhone. Apple’s guidelines effectively disallow many perfectly legal applications. In his article, Mike mentions porn. Porn is an important market force. It’s no coincidence that pornographic web sites make up a huge part of all web sites, and pornography makes up a large amount of all internet traffic. I understand that Apple doesn’t want to sell pornographic material on its store, but by not allowing Apple-unsigned code to run on iPhones, they’re not only keeping porn out of their store, they’re keeping porn out of the iPhone entirely². And this is not the only genre of applications affected; Apple’s guidelines forbid applications which run in the background, which affects things like social networking software, VOIP clients or chat applications. By keeping these apps out of the store, Apple keeps them out of the iPhone; many groundbreaking applications which could have made the iPhone a rule changer are effectively forbidden because the iPhone only runs code signed by Apple.

Third, it’s bad for application quality. Typically, developers run beta tests to find bugs in their applications. How can a developer run a beta test if running code on a beta tester’s iPhone requires that the code is signed by Apple?

Finally, how do I send review copies to magazines, or free copies of my app to friends?

Requiring code to be signed by Apple is a dangerous path to follow. Unfortunately, Apple already seems to have plans to require signed code on Mac OS X. That, by itself, is quite inconvenient, but not necessarily a bad thing; it gives users the security of knowing where code comes from. However, requiring code to be signed by Apple even on Mac OS X would be a tremendously bad move, and would probably ultimately hurt Apple, its developers, and its users.

Update: Rogue Amoeba has now started filing bugs against these restrictions. Good idea.

March 8th, 2008 / Tags: iphone, sdk, code signing, mac os x, apple, rogue amoeba software, mike ash / Trackback

The iPhone SDK: First Thoughts

Yesterday, Apple unveiled the software developer kit for the iPhone. A lot has been written about this already. As always, John Gruber has a comprehensive overview.

Here are my thoughts on this:

• First of all, interest in this seems to be tremendous. Yesterday, after the announcement, something happened which I’ve never seen before: Apple’s dev servers went down under the onslaught of interested developers.
• All iPhone applications will be sold through Apple’s store. There’s no other way to get on the iPhone.¹ Apple has some general rules about what applications they accept; the rules, however, are somewhat unclear. Apple has said that they won’t allow porn and malicious applications. Ryan Block asked whether they would allow SIM unlocking software. The answer, of course, was no. While it was fair to ask the question since it forced Apple to clearly come out against SIm unlocking software, I would have preferred if he had asked something a bit more interesting. For example, Apple has stated that their store is the only way to get software on the iPhone. Does that mean that a third-party application would not be allowed to install software? This question might seem a bit dumb at first, but package management systems like Fink or DarwinPorts are valid third-party applications which - on the Mac side at least - are even supported by Apple. Will they not be allowed on the iPhone?
• Will the iPhone Human Interface Guidelines be enforced, or are they optional? The guidelines say that ”Only one iPhone application can run at a time, and third-party applications never run in the background.” This means something like an AFP server is out of the question. A specific iPhone application idea I’ve been contemplating is a kind of ad-hoc mobile social network. The application would periodically send your position to a server, and would then be able to tell you about people using the application near your location. Such an application would need to be running in the background; it seems Apple would not accept this.
• The application I mentioned above highlights another issue: Presumably, Apple will not allow demos which can be turned into full versions by directly buying a serial number from the developer since that goes around Apple’s store. Further, Apple will probably not allow software which is free by itself, but requires some kind of subscription that is paid to the developer.
• Seems Apple mainly spent the last year making formerly public APIs private. Compared to the “unofficial” SDK, Apple’s official SDK can do a lot less. This could mean two things: Either Apple doesn’t want developers to do the things they removed from the public API, or they aren’t yet happy with the interfaces and want to stabilize them before they make the applications public. Also, official third-party applications are forbidden from using private SDKs.
• I’m a registered SonyEricsson developer. Interestingly, just after the Apple event, SE started running a survey “on the quality and relevance” of their worldwide developer programs
• Finally, it seems I was right in my prediction that Apple will enforce compliance to API rules not through a sandbox, but through its approvement process.

All things considered, the official SDK is a mixed bag. It’s better than some people feared, but worse than some people hoped. Hopefully, Apple will open iPhone development further at some later date.

Further Reading ———- TidBITS has an extensive article on the subject, while Ars Technica provides a short summary. Macworld has some developer reactions, which typically range between “goodness” and wanting to kiss Steve Jobs “full on the mouth.”

March 7th, 2008 / Tags: Apple, iPhone, SDK, OS X / Trackback

iPhone Usability Study

inUse, a swedish usability firm, has published the results of an extensive usability study comparing the iPhone to three “traditional” cell phones. Unsurprisingly to everyone who has ever used one, the iPhone proves to be vastly superior both in user’s ability to complete tasks, and in user satisfaction. The iPhone’s success is mainly attributed to the fact users can directly manipulate objects on the iPhone’s screen. From the report:

What is it then that makes the iPhone different? Most importantly, it has removed one level of abstraction by allowing the user to act on objects using the finger directly on the phone’s surface.

Talking about the study, Jakob Nielsen writes in his newsletter:

Thus, I like to say that the iPhone is the “Macintosh” of mobile, because it’s the first mainstream direct manipulation UI with an interaction style similar to a mouse-driven GUI. Other phones are the “DOS” of mobile user experience, because they rely on keystrokes.

This study might seem flawed at first, because only a small number of people were tested. However, the study is sound since it is not a quantitative study. The goal here was not to create a statistical analysis of the tested interfaces; the goal was to find user interaction issues, and to compare the phones based on the issues found. Finding user interaction issues requires only a small number of test subjects. Here’s a graph from Jakob Nielsen, plotting number of test subjects vs. percentage of found usability issues:

As you can see, testing a given task with only 4 people will find around 75% of all usability issues in this task. Nielsen has an article explaining this phenomenon.

March 3rd, 2008 / Tags: Apple, iPhone, OS X, usability / Trackback

iPhone SDK Prediction

John Gruber has an article in which he talks about what Apple will announce on Thursday; specifically, what features the iPhone SDK will - or won’t - provide. He writes:

If it’s true that the dock connector is off-limits, that’s unfortunate, but also not surprising — clearly a big part of what Apple’s been working on in advance of this SDK are ways to sandbox applications for security and control of resources.

His suspicion that there will be a sandbox is based on this article by Jeremy Horowitz. But Horowitz writes:

Under current plans, SDK developers will be prevented from interfacing directly with Dock Connector-based accessories connected to the iPhone or iPod touch

He doesn’t explain how developers will be prevented from interfacing with the Dock connector. A bit further up in his article, Horowitz writes:

The most controversial aspect of Apple’s SDK plan is its intention to formally approve or deny all SDK-based software releases for its devices. Our sources confirm that Apple will act as a gatekeeper for applications, deciding which are and are not worthy of release, and publishing only approved applications to the iTunes Store

Personally, I find it unlikely that Apple created a sandbox for third-party apps. Adding sandboxes to existing environments is hard. Java’s sandbox was part of the design from the get-go; Objective-C, on the other hand, is basically C plus a bunch of features adding support for object-oriented programming. Attempting to sandbox C seems - at first glance - a bit futile.

In my opinion, a more likely solution to preventing stuff Apple doesn’t want is not through a sandbox, but through the approvement process. I would not be surprised if developers get full access to the iPhone’s APIs, but Apple will simply not publish software which doesn’t adhere to their guidelines.

On the other hand, sandboxing Objective-C is not actually impossible. One possible solution to sandboxing C in the iPhone would be to run third-party apps in a VM. Apple owns LLVM, which could possibly be used to sandbox Objective-C code in the iPhone. According to John Siracusa, Apple “recently did some extensive work on the LLVM ARM backend.” He suspects it’s because LLVM was used to improve performance on the iPhone; maybe it’s for the SDK?

We’ll see next Thursday, I guess.

March 3rd, 2008 / Tags: Apple, iPhone, SDK, OS X / Trackback

dotfiles vs. the invisible bit

When trying to engage people in a text you’re writing, a common approach is to introduce the concept you’re discussing using a narrative, a short story vaguely related to the topic at hand. Joel Spolsky is a master at this. He used to serve in the army, so he often introduces articles by starting with an army story. Hey, I can do that, too, I also did military service! ¹

I used to serve as a medic and driver. This is probably the most laid-back thing you can do in the army. In a combat situation, medics, especially those who are also drivers, are typically not risking their lives, so there’s no need to drill them until they put the word of their commander above their need for self-preservation. Doing service as a medic is akin to working in a highly professional, focused company; hierarchy doesn’t count for too much.

As it turns out, we did not have enough lieutenants in our corps. Strangely, we ended up getting a lieutenant from the infantry. Needless to say, he thought his infantry approach to leading worked everywhere, and promptly started his first day by yelling at us, which was greeted by blank stares, followed by roaring laughter. At first, the poor fellow was rather confused by our insubordination, but he eventually figured out that talking to people worked a lot better than yelling at them.

The point of all this is that just because something seems to be the same doesn’t mean that it is.

Most operating systems support the concept of “invisible files.” Basically, an invisible file is a file that the user can’t see using the standard file browser. But the similarities end there.

Unix

On many Unix-like systems, files whose name starts with a dot are not shown to the user. Obviously, users can easily add dots to names and make files invisible. Just as easily, they show invisible files again. Typing

ls -a

in the Terminal will list all files except for . (the current directory) and .. (the parent directory). Other than not being shown to the user by default, files starting with a dot typically behave just like every other file.

In other words, this is a way for the user to get rid of clutter; to make files she doesn’t normally want to see invisible. It’s a way to trim down long file listings, so only relevant files are shown.

Mac OS 9 and earlier

Apple also had invisible files in their pre-OS X systems. Whether a file was invisible was defined by its meta data. To make a file invisible, a bit could be set on the file. That would make the file invisible in all views; in Mac OS 9, there is no built-in way to see invisible files, or to make them visible.

In other words, invisible files in Mac OS 9 were a way for the system to hide files from the user. Typically, these were files that the system needed; files which the user was not supposed to see or tinker with. The invisible bit was a flag which allowed the system to keep files away from users.

Mac OS X

So when Apple bought NeXT and started working on OS X, they came upon a problem: On the one hand, OS X was supposed to be a Unix-like system. It has the BSD subsystem, it has a Terminal, it has ls -a.

On the other hand, it also had to support many concepts from Mac OS 9. HFS, Apple’s file system, wasn’t going anywhere. The invisible bit was still there.

So, like the infantry lieutenant yelling at medics because that’s all he ever knew, Apple decided that Unix dot files should behave like Mac OS 9’s invisible files. And just like that, files starting with dots were not visible anymore.

Unfortunately, this is a bit of a problem. While Apple took the concept of hiding files whose name starts with a dot from Unix, they left the semantics from Mac OS 9 intact. In other words, files which the user made invisible behave as if the system didn’t want the user to touch them. In fact, Mac OS X actually prevents you from starting a file with a dot:

And if you do manage to start a file name with a dot, you’ll never see the file again using Apple’s default software. This is just plain user-unfriendly. It’s my system, and I should be able to use whatever name I could possibly want.

Apple took the Unix syntax for invisible files, but kept the Mac OS 9 semantics.

The Problem

Why is this a problem? Because dotfiles and invisible files are not the same. Here’s an example:

Due to reasons I might some day discuss in another article, Mac OS X stores some meta data in files named .DS_Store.² Many folders in Mac OS X contain such a .DS_Store file. .DS_Store files sometimes contain names of files stored in the folder.

As you can see from the name, Apple intended .DS_Store files to be invisible. These files are not supposed to be seen or opened by users. So Apple put a dot in front their name. Unfortunately, they originally neglected to also set the invisible bit. This becomes an issue if you do something like using an FTP client to mirror a local folder to a network. The FTP client might not know that the .DS_Store file is supposed to be invisible, thus happily copying it to a public web server, where it can then be opened and viewed by anyone. Obviously, it’s typically not a good idea to publish file listings on the Internet. Soon after the issue became public, Apple set the invisible bit, and developers creating FTP clients changed their code so dotfiles were ignored during mirroring.

Which, of course, isn’t the right thing to do, either.

Often, server configurations are stored in dotfiles. These are files that are supposed to be editable by administrators, and they are supposed to be mirrored to servers, but they start with a dot because you typically only edit them once, and then leave them be. An example of such a file is “.htaccess”, which contains directives telling the web server Apache such things as which directories are password-protected.

Changing FTP clients to ignore dotfiles means these files are not mirrored to the server anymore. Which means that if an administrator decides to upload a password-protected directory, the directory may be password-protected on his local installation, but mirroring it to the server will only mirror the directory’s content, and leave it unprotected on the server.

As has become obvious, many issues stem from Apple’s decision to treat dotfiles and files with the invisible bit set the same, when in reality, they are different concepts.

dotfiles are files the user wants to be invisible. Files with the invisible bit set are files Apple wants to be invisible. One is a way for users to manage their files. The other is a way for Apple to prevent users from accessing files. Mixing the two concepts only causes problems and confusion.

The proper solution would be to treat files starting with a dot just like every other file. Let users start files with dots. Don’t make them invisible. If a file needs to be invisible, set the invisible bit. Like the infantry lieutenant who had to stop treating medics like infantry soldiers, Apple should accept that forcing everyone to adhere to their vision may end up being detrimental.

February 24th, 2008 / Tags: invisible files, dotfiles, Apple, Mac OS X, Mac OS 9, Unix / Trackback