iPhone and lockin

| Comments (6) | DRM SYSSEC Software
OK, I have to admit that the Not Yet Released Device Potentially To Be Known As The iPhone (NYRDPTBKATi) looks pretty sweet, but the level of lockin significantly detracts from the overall coolness. There are actually two issues here, one bogus and one real.

DRM
The bogus one, raised by Randall Stross in the Times is the FairPlay DRM:

Here is how FairPlay works: When you buy songs at the iTunes Music Store, you can play them on one and only one line of portable player, the iPod. And when you buy an iPod, you can play copy-protected songs bought from one and only one online music store, the iTunes Music Store.

The only legal way around this built-in limitation is to strip out the copy protection by burning a CD with the tracks, then uploading the music back to the computer. If youre willing to go to that trouble, you can play the music where and how you choose the equivalent to rights that would have been granted automatically at the cash register if you had bought the same music on a CD in the first place.

This is, of course true, but sort of irrelevant. First, you're quite free to buy physical CDs and rip them yourself. iTunes will even rip them for you. At least with the iPod and presumably with the NYRDPTBKATi, there won't be any copy protection on them at all. It's true that the iPod file format obfuscates the locations of the files on the disk, but they're all there and you can get 3rd party programs which know how to read the format. The vast majority of music gets into iPods by being ripped, not downloaded.

Second, the issue isn't the iPod or NYRDPTBKATi, but rather iTMS, which imposes the DRM on the way out the door. Stross says this in the article but some misses the implication:

This claim requires willful blindness to the presence of online music stores that eschew copy protection. For example, one online store, eMusic, offers two million tracks from independent labels that represent about 30 percent of worldwide music sales.

Unlike the four major labels Universal, Warner Music Group, EMI and Sony BMG the independents provide eMusic with permission to distribute the music in plain MP3 format. There is no copy protection, no customer lock-in, no restrictions on what kind of music player or media center a customer chooses to use the MP3 standard is accommodated by all players.

In other words, it's quite possible to play non-DRMed files (what else is a podcast, after all?), it's just that (1) the music users want isn't available (2) the users don't know where to get it or (3) the UIs for getting it are too annoying. if it's really true that the major labels are willing to go non-DRM than this sounds like a great marketing opportunity for someone to make a really good non-DRM online music store. In any case, Stross's quarrel isn't with the iPod but with iTMS.

Programmability
This brings us to the real issue: programmability. According to this article the NYRDPTBKATi isn't going to be an open platform. I.e., you won't be able to load your own applications onto it. Apple has advanced two major arguments for why this is OK: protecting the network from rogue applications and protecting the stability of the device.

Here's Jobs advancing the first reason:

But its not like the walled garden has gone away. You dont want your phone to be an open platform, meaning that anyone can write applications for it and potentially gum up the provider's network, says Jobs. You need it to work when you need it to work. Cingular doesnt want to see their West Coast network go down because some application messed up.

Look, this is mostly nonsense. Yes, it's true that programmable computers can do damage to the Internet (cf. zombies, spam, DDoS, etc.) but this isn't primarily an issue of people installing the wrong third party software but rather of their machine being remotely compromised via vulnerabilities in the existing software—primarily stuff installed by the OS manufacturer. I should mention that Apple isn't giving out SDKs for the iPhone, so it's going to be harder for malware authors to program to it than (say) Windows, but that's only a temporary obstacle if it becomes an attractive attack target. There are of course ways to stop third-party malware from being loaded on at all (e.g., signed code) but the level of defense that Apple employs on the iPod doesn't suggest that they're too likely to have done anything like that here. I'd imagine they're just hiding the specs and the SDK and maybe churning the API/ABI occasionally to make it more inconvenient to write a real product.

More importantly, the danger in rogue applications isn't primarily to the access network but rather to machines other places on the Internet. It's actually very easy for Cingular to detect when a device is doing something dangerous to their network and shut it down. And to the extent to which it's not easy, Cingular has much bigger problems since they're already quite willing to sell you Windows Mobile and Palm smartphnes, which are programmable.

The second argument Apple is advancing is that letting end-users run arbitrary third-party apps will potentially destabilize the handset, contributing to a bad user experience.

We define everything that is on the phone, he said. You dont want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesnt work anymore. These are more like iPods than they are like computers.

The iPhone, he insisted, would not look like the rest of the wireless industry.

These are devices that need to work, and you cant do that if you load any software on them, he said. That doesnt mean theres not going to be software to buy that you can load on them coming from us. It doesnt mean we have to write it all, but it means it has to be more of a controlled environment.

So, this is vaguely more reasonable, especially considering Apple's well-known fetish for the providing the optimal UI experience. Still, it's not particularly convincing. I've loaded several 3rd party apps on my Treo and haven't noticed it destabilizing the phone functionality. A modern O/S like OSX should be quite capable of protecting applications from each other—that kind of process isolation is one of the major functions of the OS. I haven't noticed any of the 3rd-party apps I run on my OS/X boxes being a source of massive instability.

Does it matter?
I'm probably unusual in that I'd actually like to be able to do some development on a handheld device, which would obviously be a problem if there's no SDK. That would be a big motivator for getting something based on a real operating system rather than PalmOS. But even ordinary users may find this kind of lockin inconvenient. I don't know what applications Apple intends to provide on the NYRDPTBKATi, and the truth is that they provide a pretty reasonable set on your Mac, but even so I've installed Firefox, MS Office, the Palm software suite, and Windows Media Player. Apple offers their own versions of some of this stuff and it will be interesting to see if they decide you should have to run Safari instead of Firefox or Keynote instead of PowerPoint. One of the nice things about having a general purpose computer is that you get to make these decisions for yourself rather than having Steve Jobsa make them for you.

6 Comments

I'm all for programmability, but I can at least see the other side of the argument. I've gone through using a SideKick (walled garden, only approved apps) and a Windows Mobile device, and the general OS design of WinMobile to accomodate those apps drives me batty.

The thing thinks that it's a little PC, so it hangs, stalls, had ugly modal dialog boxes, and is a complete pain to navigate. On the other hand, you can load thousands of apps.

The SideKick requires apps to go through a cert process, but the apps are all well behaved and conform to a univeral look and feel that makes the phone much more pleasant to use.

It's be great if there was some middle path here.

I have a theory on why the third party app issue is there for the iPhone.

Having watched the demo very very carefully, I noticed that apps slow a lot when the phone is in use. My speculation is twofold: first, that the phone uses the main processor for part of the work during phone calls, and second, that OS X does not yet have enough infrastructure to allow the phone call app to properly reserve enough CPU time for itself to assure good performance.

I will repeat this is just speculation, but were it true, it would give Apple a strong reason to prevent arbitrary third party apps from running since they could render the phone useless. If my speculation is correct, this defect would vanish if and when OS X got better real time scheduling.

I will point out, by the way, that there are some truly open phones in development. See, for example, http://www.openmoko.com/. Strangely, the phone the openmoko people are working on also completely lacks a keyboard.

I think Perry's probably nailed it, and I'm really bummed it's not going to be open. I don't have a lot of third-party applications on my Treo, but 'pssh' has saved my bacon more than once and something as simple as the BART application is something I'd really rather not live without. Plus, heck, I'm a geek. I'd love to be able to program a touch-screen thing that lives in my pocket and is running Mach/UNIX and hosting Objective-C. Duh.

And don't get me started about Cingular...

BTW, here's Tog's initial thoughts on the iPhone:

http://www.asktog.com/columns/070iPhoneFirstLook.html

The lack of programmability, in my opinion, is the only major reason why the iPhone isn't (yet) a Treo-killer. The specs look better on all interesting dimensions and the UI is sexy. And there are plenty of Treo users drooling right now. But when the reality of the missing ecosystem sets in, a lot of people will wake up. I won't be able to ssh on the iPhone (painful, but sometimes very handy). You won't be able to use an iPhone as a Bluetooth modem for a laptop. A business user won't have his expense-tracking application. A teenager might not get their favorite IM client on it. And so on.


The interesting question is whether the iPhone will stay closed or not. Unlike Perry, I suspect there's no technical reason why the iPhone is closed. If Palm can do an open phone on top of a cooperative-multitasking system like the (ancient) PalmOS 5, Apple can do lots better with a real operating system like OS X. And in the mobile space, there's a long history of powerful, open phone being crippled by device manufacturers at the request of carriers. My guess is that the iPhone is closed at Cingular's request (and that, with the possible exception of certified apps, that restriction is part of the exclusivity agreement). My hope is that the iPhone is only closed "for now" and Apple open it up once they have more experience with the device and its custom version of OS X. Time will tell which one of those is right.

Ravi has reversed the complexity issue here.


On a primitive system like PalmOS, doing resource reservation is relatively straightforward. The problem is getting it to work in a system that looks much like Unix.


First, consider that in the traditional Unix kernel model, processes are not really preemptable when they're running in the kernel. You can go off for a few moments to service an interrupt, but basically the assumption is that you run until you block. (There are some slight exceptions but they're not that important.) Now, in a hard real time system, that means either you a) change around your kernel model, or b) put in very tight guarantees about how long you can stay in an execution path.


Consider, as another example, device drivers. If your box isn't doing much hard real time, it is okay to code device drivers in a fairly straightforward manner and to ignore questions like how long you spend in low level service code with interrupts blocked. Now, lets say you're trying to build a real time system -- no, you can't just hang out at the bottom of a device driver for as long as you want, and if the device needs to be tweaked twice a millisecond apart, you can't just call delay() and assume the user won't notice because the event is rare.


Consider the scheduler. The traditional Unix scheduler model doesn't really have a notion that you're guaranteed N computrons every M time units. Compute bound userland processes can hang out for quite some time before the processor gets released (though usually a system call of some sort happens and the processor gets released). The scheduler is very simple and doesn't spend a lot of time on the accounting needed to figure out how much execution time you've gotten compared to what you need. The stock scheduler is built to emphasize interactive performance over compute performance and doesn't really have a notion of scheduling classes.


All this stuff can be fixed, and indeed it has been fixed in a number of systems, but my hypothesis is that all the work has not yet been completed for OS X.


As I said, though, this is all pure speculation. Maybe I'm completely wrong. It would, however, explain certain elements of Apple's spin on the whole thing.

Leave a comment