There's a debate here in Germany about whether an IP address is a piece of data that can (or could) identify a person. This is an important question for the IT industry in Germany because of our stringent data privacy laws: storing and/or processing personal data requires the person's (prior) agreement. The current headlines revolve around Google Analytics but the general question is whether the established procedure of logging IP addresses is in line with the law.

What if IP addresses are declared as personal data? Two questions twirl around in my head:

1. What about other uses of IP addresses (like in dynamically generated firewall rules)?
2. What's a practical alternative to logging IP addresses?

While my first question is in fact to be taken seriously - albeit it's sort of funny to think about the implications. Hoever, I don't have any further thoughts with respect to question #1. I've seen several academic papers in the past with respect to question #2 but can't currently locate them - with one exception: Ulrich Flegel's paper about pseudomizing Unix log files using a modified syslog daemon (which has additional pseudomizing aspects like unix usernames and the like). My main issue is that the deployment of such a solution would be rather involved for most environments. My (rather easy to deploy) suggestion is a pseudomizing reverse DNS server; the web server would need to be configured to not log IP addresses but rather the reverse DNS name of the visitor (which is a standard configuration option for most servers). However, most webserver admins (understandably) shy away from logging reverse DNS names because of the potential for delays incurred by unsuccessful reverse lookups. However, if a DNS server handling reverse lookups was deployed locally then performance wouldn't be an issue. If this reverse DNS server served not the real reverse DNS name but rather a pseudomized DNS name then all the sudden we would have solved those legal concerns. Well, not quite: of course the IP addreses would need to be stored within the reverse DNS pseudomizer itself; however, I am sure that there are ways to design and operate such a device in that it would be considered compliant to the law (ie: access restricted to a designated privacy officer).

Yesterday I've stumbled across a tool Pit and I wrote a few years ago. In honor of his birthday I decided to devote a blog entry to this (don't worry: the technical details are quite interesting).

The scenario: we were facing issues in our production environment with a multi-process server application that binds an UDP port to a multicast address on HP-UX. Every now and than the system would stop processing messages sent to its multicast address. After quite some time we realized that this ocurred whenever one of the server applications processes terminated (ie: crashed). Since this server application was a service provider on the corporate/enterprise service bus it meant that that particular service was available in one less server (as in system) instance to the service bus whenever a process terminated. That could turn in to a real problem quickly, so we needed a solution that would allow a quick problem recovery until the real issue was fixed.

The problem: HP-UX 11.11 had a bug that didn't account for multiple "participants" (processes bound to the same multicast address). In other words: if you had multiple processes on the server that used the same multicast address and one of these processes terminates then HP-UX (incorrectly) instructed the network card to not listen for incoming packets to that multicast address any longer (well, the corresponding MAC address). The remaining server processes would keep on waiting for incoming packets but the network card just didn't want them any more. The theorectical solution looked easy: if a process bound itself on that multicast address then HP-UX would instruct the network card to listen to multicast packets again. The two obvious implementation alternatives weren't quite acceptable:

• restart the entire process tree -> a restart took too long
• start a dummy process that binds to the multicast address and puts itself to sleep (it must not terminate because that would reverse the intended effect) -> how many dummy processes would we have over the course of several months?

So, we needed another solution and we found one. HP-UX implements an interface named DLPI (Data Link Provider Interface), which allows low-level manipulation of network card state. We wrote a small tool that used DLPI to manually add the corresponding MAC address of the multicast address to the network card's MAC address for which it should accept packets. This tool was run via CRON every minute and the problem was "solved" until a fix became available for HP-UX (which happened with 11.20 if I remember correctly). Here's your birthday present, Pit: http://pastie.org/private/qeazuwrqnmar25hzo4reg (I am pretty sure you did't have the sources for that tool any more)

I would like to listen to podcasts while driving. I bought an iPod a few years ago and thought I would take it with me in the evening and sync-up podcasts for the next day's drive (my car has an USB connector suitable for iPods). However, I never developed a habbit of taking the iPod with me and thus it now contains only music.

I recently got an Android phone and that rekindled my desire to listen to podcasts on the road. I figured that it could automatically download podcasts and all I have to do is figure out a way to get the podcast played over my car's stereo. Connecting my phone to my car's USB port might work (I haven't tested that yet), but I don't want to have to fiddle with the USB cable every day (yes, I am lazy like that).

My preferred solution was to have the podcasts streamed over bluetooth to play on my car's stereo. However, my car only supports the HSF bluetooth profile (designed to trasmit voice calls to headsets) and not the A2DP profile (for high-quality music content). Thus, I would need to figure out a way to get Android to transmit the audio content via HSF to my car. I stumbled across various posts in which some people wrote about their own unsuccessful efforts to accomplish this. I remember one posts that contained a statement by some Android developer that only phone conversations are supported for HSF. It said something like "android does not support app processor generated audio data for HSF" (referring to the "main"/"app" CPU in the phone - instead of the "media"/"phone" processor which handles all phone-related processing).

While I do think that it should be plausible to hack something together for rooted Androids, I don't see that on my to-do list for now. Instead, I am currently investigating another solution: exploit the fact that my phone contract has a flat rate for calling land-line phone numbers. I am thinking of setting up an asterisk instance that I can call (phone call, not VoIP) and have it play back my podcasts. It would consist of two components: a web frontend for managing podcast subscriptions and the asterisk logic for handling incoming calls in order to navigate through the podcasts and to actually play them. Although this solution is not as technically challenging as hacking audio support for HFP for Android, it's probably the more appealing solution for others.

By the way: for those who are eager to investigate the bluetooth HFP implementation in Android, here are the relevant Android source files:

• ScoSocket.java
• android_bluetooth_ScoSocket.cpp
• BluetootHandsfree.java

Update: If your in Germany then check out http://www.phonecaster.de/ - it does exactly what I wanted to implement myself. I may not pursue my idea anymore...

Wouldn't it be cool if mod_dav_svn (the Subversion plugin for Apache) offered RSS (or Atom) feeds for repository entities? One could browse through the repository with a browser and easily monitor repository entities for changes via RSS. Subscribing to a directory entity should report changes to any contained entity.

I think that adding an additional URL handler like ".../!svn/rss/..." (similar to others like ".../!svn/vcc/..." or ".../!svn/his/...") would be a reasonable implementation choice. The first thing to implement would to add the RSS element links for all listed repository entities in the generated HTML output (<link rel="alternate" type="application/rss+xml" title="..." href="..."/>) - that should be nearly trivial. Far more complex will be the implementation for the RSS URL handler itself: it requires accessing the repository's log data and should optimally be rather performant (ie: not parse the log data from all versions in the backend). My guess is that there's no way around having to maintain a sqlite(/whathever) log cache for efficiency.

Oh, right: I don't think that I'll be implementing this feature any time soon. What about you, don't you have some spare time for this project? Leave a comment or send me an e-mail in case you want to tackle this.