A few days ago, WinAmp iPod plugin developer Will Fisher wrote a blog entry about the changes Apple made to the iPod music database format that break compatibility with third-party software. Although the iPod has never officially supported open music management, the database format used by the device was previously relatively straightforward. The new database format uses a checksum value that locks the database to a specific device and prevents third-party database modification. If the device's internal database is modified by a third-party program in any way, it will refuse to play any of the content and report that the device contains 0 songs, even if the database is still completely intact in every other respect.
Fortunately, community members have alerted us that a GtkPod developer has cracked the checksum and successfully tested the new database format support on two devices. Those who are already locked into Apple's ecosystem will now be able to continue using the software of their choice with their iPods.
Why did Apple do this in the first place? It appears to be a lock-in strategy intended to force consumers to use iTunes. It is relatively clear that this change was made to block third-party software and isn't just a new feature that was added to the database format for other reasons. Cory Doctorow of BoingBoing weighs in on the debate and provides a pretty good rebuttal to claims that the changes were made for data integrity verification:
"Checksumming is NOT just being used to verify data integrity—if that were all, then the iPod wouldn't report zero tracks if the checksums failed to match. The sum could be calculated using an easily-derived salt. In this case, the checksum is being calculated using a secret shared between the device and iTunes, in order to prevent clients that don't share that secret from loading music onto the iPod."
Lennart Poettering, an open-source software developer who helped create a Linux implementation of Apple's ZeroConf protocol, also comments on the situation in an insightful blog entry and explains that Apple has similarly used cryptographic keys to lock out third-party support for features in DAAP and ROAP, network audio streaming protocols used by iTunes and AirPort.
"iTunes uses cryptographic hashes to make sure that only real iTunes instances can swap audio with each other. This key has been broken multiple times, hence there are now a couple of alternative DAAP implementations, which can swap audio with iTunes (Rhythmbox being one example). However, with iTunes 7 Apple changed the cryptographic key once again, and until now nobody managed to break it."
Although Apple's iPod lock-in attempt has been thwarted today, Poettering reminds us that it might not be possible to thwart in the future. Apple's willingness to make these kinds of changes to the database format should be taken as a warning that unsupported third-party compatibility options may not be viable in the long term. Although Apple may not be attempting to block third-party native iPhone app hacks with firmware updates, for instance, the company could easily attempt to do so in the future if they felt that the third-party software ecosystem was a threat to their control. Developers shouldn't assume that Apple's leniency now will continue. In fact, if history is any evidence—with the iPods, DAAP, and ROAP—it is likely that iPhones will be locked back down again too at some point in the future.
reader comments