So, Apple now blocks third-party software from accessing iPods. But is behaviour like that news? No, unfortunately not at all.

Let's have a look on two technologies that are closely related to the iPod and Apple-style media playback: DAAP (Digital Audio Access Protocol) and RAOP (Remote Audio Output Protocol). RAOP is the protocol that is spoken when you want to output audio from iTunes over the network on your AirPort base station. DAAP is the popular protocol which you can use to swap music between multiple iTunes instances on a LAN. Both technologies use cryptographic hashes to block interoperable alternative implementations.

Now, the RAOP client crypto key has been extracted from iTunes, hence its now possible to implement alternative software that takes the role of iTunes and streams audio to an AirPort. However, noone managed to extract the RAOP server key yet, hence noone is able to implement software that exposes itself as AirPort-compatible audio sink on the network, so that iTunes could stream data to it.

With DAAP it's a similar situation: 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.

So basically, Apple now dongles AirPorts to iTunes, iTunes to iTunes and iTunes to iPods. The whole Apple eco-system of media devices and software is dongled together. And none of the current iterations of the underlying technologies have been fully broken yet.

While the audio files you can buy at the iTunes shop may now be DRM-free, you're still locked into the Apple eco-system if you do that. They replaced DRM with vendor lock-in.

This lock-in behaviour is childish at best. DAAP once was the de-facto standard for swapping media files in LANs. Swapping files in LANs is perfectly legitimate and legal. Then, Microsoft/Intel started to include a similar technology in UPnP, the UPnP MediaServer. An open technology that has now been included in endless media server devices. Several Free Software implementations exist (most notably gUPnP). These days, uPNP MediaServer is ubiquitous, DAAP is no more. Apple had the much better starting position, but they blew it, because of their childish locking-out of alternative implementations.

I believe that DAAP is the superior protocol in comparison to UPnP MediaServer. (Not really surprising, since I wrote most of Avahi, which is a free implementation of mDNS/DNS-SD ("Zeroconf"), the (open) Apple technology that is the basis for DAAP.) However, due to the closedness of DAAP I would recommend everyone to favour UPnP MediaServer over DAAP. It's a pity.

Both DAAP and UPnP MediaServer are transfer protocols, nothing that is ever directly exposed to the user. Right now, Free Software media players support DAAP much better than UPnP MediaServer. Hopefully, they will start to abstract the differences away, and allow swapping music the same way over DAAP and over uPnP. And hopefully, DAAP will eventually die or Apple will open it. They have shown that they are able to change for the good, they became much more open with WebKit, and they changed the license of Bonjour to a real Free Software license. Let's hope they will eventually notice that locking users in makes their own technology irrelevant in the long term.

Oh, and let's hope that Jon finds the time to break all remaining Apple crypto keys! Jon, DAAP 7.0, and the RAOP server key is waiting for you! I'd love to make PulseAudio RAOP-compatible, both as client and as server.

Update: Ars Technica has an update on this.

Woah, I am interviewed on LugRadio. (@ 71:09)

$ ccache -s | egrep "(cache hit|cache miss)"
cache hit                        3518652
cache miss                        168484
$ echo $((168484*1000/3518652))
47
$

Less than 5% of the compiler invocations on my development machine since 2004 actually processed new and unseen code.

I'm still unsure, though, what this is telling me?

Only three days left for sending in your paper for FOMS 2008, the best Free Software multimedia conference/workshop around. The best chance to meet all the important people from the major multimedia projects!

Earlier today I switched Fedora over to install PulseAudio instead of the venerable EsounD by default.

My GUADEC 2007 slides.

... whether the guys behind this know about this?

It's a pleasure to see as many projects as possible making use of Avahi. OTOH I believe that all solutions should speak the same protocol. Using Apple's somewhat standardized link-local iChat/XMPP protocol (which is what Telekinesis does) seems to be the best option to me: because you get MacOSX interoperability for free and many IM clients (including many on Windows) already contain support for this as well.

Seems CUPS now comes with Zeroconf/Bonjour network printer browsing support included in the upstream tarball. I haven't tried this myself, but presumably CUPS should work on Avahi as well, since we ship a -- these days nearly perfect -- Bonjour compatibility library.

In Fedora Rawhide this functionality seems to be enabled already. Other distibutions, please follow!

Seems at least one good thing came from the recent Apple buyout of CUPS/Easy Software Products: I can now remove one item from my TODO list which has been there for a long time already.

For those interested: here're my slides for my presentations at LRL and OLS:

• Ottawa Linux Symposium 2007: Cleaning up the Linux Desktop Audio Mess (Not too much new stuff here if you already read my LCA slides)
• LugRadio Live 2007: Six Use Cases for Avahi

LWN linked a short summary of my OLS talk.

In response to Darren Kenny:

• On Linux (and FreeBSD) nss-mdns has been providing decent low-level integration of mDNS at the nsswitch level for ages. In fact it even predates Avahi by a few months. Porting it to Solaris would have been almost trivial. And, Sun engineers even asked about nss-mdns, so I am quite sure that Sun knew about this.
• You claim that our C API was internal? I wonder who told you that. I definitely did not. The API has been available on the Avahi web site for ages and is relatively well documented ^[1], I wonder how anyone could ever come to the opinion that it was "internal". Regarding API stability: yes, I said that we make no guarantees about API stability -- but I also said it was a top-priority for us to keep the API compatible. I think that is the best you can get from any project of the Free Software community. If there is something in an API that we later learn is irrecoverably broken or stupid by design, then we take the freedom to replace that or remove it entirely. Oh, and even Sun does things like that in Java, Just think of the Java 1.x java.lang.Thread.stop() API.
• nss-mdns does not make any use of D-Bus. It never did, it never will.
• GNOME never formally made the decision to go Avahi AFAIK. It's just what everyone uses because it is available on all distributions. Also, a lot of GNOME software can also be compiled against HOWL/Bonjour.
• Implementing the Avahi API on top of the Bonjour API is just crack. For a crude comparison: this is like implementing a POSIX compatiblity layer on top of the DOS API. Crack. Just crack. There is lot of functionality you can *never* emulate in any reasonable way on top of the current Bonjour API: properly integrated IPv4+IPv6 support, AVAHI_BROWSER_ALL_FOR_NOW, the fact that the Avahi API is transaction-based, all the different flag definitions, and a lot more. From a technical persepective emulating Avahi on top of Bonjour is not feasible, while the other way round perfectly is.

Let's also not forget that Avahi comes with a Bonjour compatibility layer, which gets almost any Bonjour app working on top of Avahi. And in contrast your Avahi-on-top-of-Bonjour stuff it is not inherently borked. Yes, our Bonjour compatibility layer is not perfect, but should be very easy to fix if there should still be an incompatibility left. And the API of that layer is of course as much set in stone as the upstream Bonjour API. Oh, and you wouldn't have to run two daemons instead of just one. And you would only need to ship and maintain a single mDNS package. Oh, and the compatibility layer would only be needed for the few remaing applications that still use Bonjour exclusively, and not by the majority of applications.

So, in effect you chose Bonjour because of its API and added some Avahi'sh API on top and this all is totally crackish. If you'd have done it the other way round you would have gotten both APIs as well, but the overall solution would not have been totally crackish. And let's not forget that Avahi is much more complete than Bonjour. (Maybe except wide-area support, Federico!).

Anyway, my original rant was not about the way Sun makes its decision but just about the fact that your Avahi-to-Bonjour-bridge is ... crack! And that it remains.

Wow, six times crack in a single article.

Footnotes:

[1] For a Free Software API at least.