Apple’s Update Strategy is Risky
On Saturday I was going to a party at an apartment building. The buzzer wasn’t working, and I took out my shiny new iphone to call and get in. As I was dialing, a few young teenagers were coming out. They wanted to see the iPhone, and so I demo’d it in exchange for entry to the building. (Mmm, security.) As I was heading in, one of them turned back to me to say “Be careful! The updates are bricking those things!”
(Bricking is a term used to describe making your expensive electronics as useful as a brick by messing up the way the it starts up.)
I found that really interesting–they hadn’t ever touched the phone, but they’d heard about and remembered the risks of patching them and wanted to share.
More than interesting, I think there’s a tremendous danger for everyone who makes software. Allow me to explain my personal analysis here. My employer may well disagree, I haven’t discussed this with them.
This update isn’t simply about annoyances like low speakerphone volume. There are ten security issues being fixed [link to http://docs.info.apple.com/article.html?artnum=306586 no longer works] as well. Some of these (bluetooth remote code execution, cross site scripting, Javascript not turning off and javascript having access to https data) are clearly worth fixing. Unfortunately, Apple has decided to offer only a single, rolled-up update which combines all of these issues with other changes. Those other changes may brick your phone.
This fear of brickage is a particular and intense form of fear of instability. This was a major theme of a paper I wrote in 2002 with Steve Beattie, Crispan Cowan and others, “Timing the Application of Security Patches for Optimal Uptime.” In that paper, we discuss how to balance the security expert’s fear of an attack with the operations expert’s desire for system stability. Our suggestion was to measure the odds of a patch induced failure with the odds of an attack. We used vendor patch recall as a indicator of patch quality. Apple has denied us that, by saying “If the damage was due to use of an unauthorized software application, voiding their warranty, they should purchase a new iPhone.”
This fear will leave many iPhone owners reluctant to patch. In fact, as I write this, the unbricking software rolls your phone back to version 1.0.2, effectively unbricking and unpatching it at the same time.
People remember important or emotional events more than they remember routine ones. Quick, what did you have for dinner on October 1 of last year? How about your birthday? Similarly, users remember patch failures far more than they remember patch success.
And so what Apple is doing has an important side effect: creating a fear of their patches. That fear will last long after a reasonable resolution of this incident. It will be felt and remembered not only by those who had bricked phones, but also by those kids who let me into their building.
If Apple wants to shoot themselves in the foot, that’s their business. What they’re doing is splattering other people.
There are two important lessaons for anyone developing software:
- Software has bugs, and some bugs require patches. Think about update strategies early on.
- It would serve Apple extremely well to find ways to let their iPhone customers extend their devices in supported ways. More generally, when you have a hot product, let your customers extend it. Embrace the chaos that emerges.
Speaking of chaos that emerges, there was too much to fit into the main post, so a little more on troubles with updating, and the inexorable nature of corporate DNA, after the cut.
Image: ChieuKeung’s lego iPhone.
[Update: For all of you saying, “Don’t hack, it’s ok” in the comments, I have two responses:
- First, you’re missing a major point of this post, which is tangentially about Apple, and all about the psychology of patching.
- Second, Engadget says you’re wrong (in a long post):
In an informal and totally unscientific poll here on Engadget, the number of iPhone users who had never hacked their device but wound up bricked was very similar to the number of users who did hack and brick their device.
]
I’d like to say a little more on the combination issue: Rainer Brockerhoff has an explanation that the entire OS is in ROM, and thus overwriting it is tricky and complex. It may be that each update would have bricking risk, not to mention that there would be an explosion of states Apple would have to consider and support as they issue future updates. That probably contributes to the locked down nature of things, which convinced Lauren Weinstein to comment on the difference with how Microsoft treats Windows Mobile, “Darth Apple and the iPhone: The Dark Side Revealed?” [link to http://lauren.vortex.com/archive/000301.html no longer works].
Finally, I wanted to mention a post by Les Ward (“The impending return of “beleaguered”“) on this quote from Steve Jobs:
And we weren’t so good at that, where Bill and Microsoft were really good at it because they didn’t make the whole thing in the early days and they learned how to partner with people really well.
And I think if Apple could have had a little more of that in its DNA, it would have served it extremely well. And I don’t think Apple learned that until, you know, a few decades later. (Steve Jobs, “Official D5 conference transcript” [link to http://d5.allthingsd.com/20070531/d5-gates-jobs-transcript/ no longer works].
As Les says,
It seems, in particular, that many of their recent choices have been driven more with an eye toward entanglements of deals they have made than a desire to make good products. This switch is taking them away from what their loyal fans loved about them, and is likely to do more damage than Apple expects.
Can this post be called anything other than competitor bashing? We all know how Apple works, and we all know how the mobile phone industry works. Adding a conflict of interest, and we all need to bend over backwards to avoid airing the geekly ire.
This is totally backwards. First off, 99% of iPhone owners will never bother to unlock their iPhones. There is nothing to fear for them.
Second, the people who are foolish enough to unlock their iPhones should be have alittle more brains. Let’s see, should I be more worried about an Apple approved patch which will fix bugs and add functionality or about an unsanctioned unlock which probably adds no value to my device and may nullify a $400 piece of gear?
Ian,
I’m sorry you see this as competitor bashing. I pointed out that this derives from a thread in my thinking (around the sociology & psychology of patching) that goes back to 2002. I also pointed out that I’m a customer.
I suspect that AT&T and not Apple is behind the posturing.
I bought an iPhone and had it shipped up to Canada where I have been using it on both Rogers and Fido prior to setting it up for my wife. Impressively well designed product although I do so much email on my blackberry I don’t think the iPhone can replace it yet.
Anyways: obviously for Apple to get into the cellphone game it had to work with some wireless service providers. Being a newbie it was probably easier to start working with just one provider, and the GSM move was almost certainly a choice to make their device more portable between networks which made the choice of AT&T more obvious. But there is an exclusive relationship with AT&T they need to manage and AT&T may stand to lose more than Apple if widespread unlocking occurs. I’m not sure what the economics are here (does AT&T subsidize the cost of the hardware and/or does Apple get a cut of the revenue of iPhone accounts on their network) but AT&T is the desperate dinosaur with armies of lawyers looking to make sure that Apple doesn’t make it easy to take their precious iPhone to other networks.
I think Apple is testing the waters, and we will probably see something interesting in the next year (e.g. Google buys UHF airways and allows we start to see more carrier neutral infrastructure supporting devices like the iPhone).
If you want such a complex product to succeed, its important to get the developers onboard, which means you need to create more open platforms. I would be shocked if Apple isn’t starting to get it.
Also, to the other Ian: this certainly doesn’t come off as competetitor bashing. In fact the first thing it highlights is that Adam is using a competitor’s product and musing about the openness of the platform.
I guess my big question is, why do you have this need to unlock it and risk bricking your phone when updates are rolled out? This sounds a lot like wanting your cake and eating it too…you want it unlocked but want Apple to support your changes and not mess up? I guess I’m lost there…
If I ever replace firmware/software on devices above the TOS/warranty, I’m accepting the risk that a subsequent update or initiative might wreak havoc on the device, and either leave it in a vulnerable state, an original state, or unusable state.
People should have a fear of putting custom parts/software into their stuff, not of the patches. The exception being if replaced updates/unlockings is supported or at least accepted consumer behavior by the vendor.
Whether the iPhone should be unlocked beyond AT&T is another topic altogether. Sure they might be married at the moment, but that won’t hold together over time. As it stands, that’s an Apple/AT&T business/marketing/product decision…nothing more.
This isn’t only about unlocking, it’s also about adding functionality to your phone with 3rd party apps.
Lonervamp, I agree that for obtaining end user support (which I don’t care about) Apple should have the right to determine which configurations are supportable. But that’s an entirely different question from what is ALLOWED.
The irony of the folks trying to justify device and feature “locking” is that Apple’s products HAVE BEEN MADE POSSIBLE by open hardware and software platforms. Namely the PC (hardware) and FreeBSD (software).
I think Apple demonstrated quite convincingly their inability to compete with their own proprietary hardware and software platforms.
I guess the point I feebly try to make is that Apple doesn’t need to cater to people who twist and turn and add things to the iPhone that were possibly not intended. Can I put a new firmware on my Motorola Razr along with new apps and still expect Verizon to support me or take care to make sure my Razr is never ruined even with updates? I kinda doubt it. Same goes for my PSP and Sony. Sure, changing my Linksys WRT54G adds functionality when I install OpenWRT, but does that mean Linksys still upholds the warranty and support? Rightfully so, I doubt the makers would support my changes, and their first response will likely always be, “Put the device back how it was, otherwise you’re on your own.”
It might be a better argument to say Apple is purposely bricking changed iPhones…versus accidental bricking due to incompatibilities. The former would be just plain malicious. Of course, intent can be hard to identify. If 50% of the “third party adders” get updates with no problem, and another 50% are bricked, was that malicious or just accidental because the add-on was poorly designed?
As it is, I guess, there are a lot of people who *want* to add software to their iPhones, but “want” doesn’t really matter compared to what is allowed or not. I think a lot of people are crying about what they want, and not about what is reasonably possible.
Then again, I could be fully wrong and Apple wants third party development and replacements and just isn’t ready to fully let go of the platform like that…or they didn’t make the core firmware (the ROM stuffs) solid enough. I mean, I add software to my Windows PC. I still expect updates. But I don’t get the ability to change source code in Windows or do huge replacements…at least not without the burden of responsibility for the stability falling squarely back to me.
The vast majority of the Apple iPhone users have no worries at all. It’s only the little baby-whiney-hackers that have any concern. They should “buck up” and realize that if they hack, they are going to have these kinds of troubles. It’s not the troubles for the vast majority, but only for the whiny ones. Get real and get a life!
With regard to unlocking phones from the network, I think that people are getting what they deserve if they then try to apply patches. If you go around applying binary hacks to the flash inside embedded devices then expecting subsequent updates to work flawlessly seems quite unreasonable.
Having said that, I think that Apple have played this very poorly. I quite understand Apple not wanting to have to deal with the huge proliferation of states but the correct solution would have been to check the hash of the code in the device and simply refuse to upgrade devices which had been hacked. If people wish to have their code deviate from Apple’s code then Apple can tell them to fork off…
I’m unsure if I agree with Adam about the longer-term effect. Apple have received some very poor PR from this and I suspect much of this is down to the fact the technology journalists are disproportionately likely (a) to hack their gadgets and (b) ignore HUGE BLOCK CAPS WARNINGS. In practice however the overall fraction of iPhone users who will ever see a “bricked” phone is likely very small. Some users may have been made wary of updating their phones but it’s hard to know how substantial this effect is among those who don’t read Slashdot. Furthermore, since there have been numerous reports of brand new, non-hacked phones getting broken by the update, perhaps customers are right to be apprehensive about upgrading until Apple do something about their QA processes. It’s a while since I read “Timing the Application of Security Patches for Optimal Uptime” but I seem to recall that holding off upgrading is supposed to exponentially reduce my “risk of bad patch”.
Ironically, if Apple really have put out a “Bad Patch” then it looks like they have a way to save face with one community, at the risk of raising the ire of another. If the patch is equally likely to break new phones then it’s demonstrably not an attack on the phone hackers; it’s just bad software.
Ian Rae and Adam:
I would suggest that it is only an irony in the Gnu/FSF/GPL world. That community is on a crusade to open up everything, by carrot&stick. (I don’t like it, but I have to admit that it worked… the Linux world overtook the BSD world.)
The BSD world is different. The explicit intention it so allow the companies to take the shared product and close up their usage of it. It’s a carrot with no stick; the message is that a company can do whatever they like, and when they feel happy, come back and start contributing to the community by putting source into the common code base. It works and it worked well. (With the selection by Apple, the BSD world has now overtaken the Linux world, by some metrics.)
There is no irony; Apple is simply using FreeBSD as it was intended. Where this model runs into grief is if they start using GPL stuff, as well. Then it gets messier. Apple is certainly smart enough to avoid that, so don’t lose any sleep over it.
The same logic apparently applies to Adam’s claim that “it’s about adding applications.” This is FSF/GPL/free beer thinking in another costume. Why? Where? When did we acquire that right? And why can’t we exercise that right over at sourceforge or somewhere, instead of telling Apple to deliver our customised geek platform?
I agree with Nicko … if the patch is bad, then it’s just a bad patch. Not much point in talking about patching, etc, strategies until we can compare two well-executed strategies.
News on hacker-friendly phones:
http://news.zdnet.co.uk/communications/0,1000000085,39287934,00.htm
http://news.zdnet.co.uk/communications/0,1000000085,39281072,00.htm
Serious question from a Windows Mobile developer: when did Microsoft ever release a security patch for Windows Mobile (and the OEMs pick it up and release it as a ROM update)? As far as I know it’s never happened.
I’m afraid I refuse to believe there have never been any vulnerabilities. Software is software, it has bugs, and some of those bugs will have a security impact.
Serious question from a Windows Mobile developer: when did Microsoft ever release a security patch for Windows Mobile (and the OEMs pick it up and release it as a ROM update)? As far as I know it’s never happened.
I’m afraid I refuse to believe there have never been any vulnerabilities. Software is software, it has bugs, and some of those bugs will have a security impact.