Month: September 2009

Privacy took another hit this week

With the introduction of obligatory finger prints in Dutch passports this week, privacy has taken another hit. When applying for a new passport (or identity card), it will be mandatory to provide four finger prints. Two of these will end up in the RFID chip in the travel document. This is due to EU legislation and will be implemented in all European countries.

As an added bonus, all Dutch finger prints will be stored in a central database, accessible by the Police. Scary, considering that the Netherlands has 12 times as much telephone taps on its inhabitants compared to the United States. It has to be noted that the EU legislation does not require this at all!

For a few years now, I have been refusing the enter the United States. Main reason: you are mandated to supply all 10 finger prints at the border. You can easily choose to not enter the US anymore. When your own country starts implemented such unnecessary rules, it becomes much harder. Adults are required to carry ID. You need an ID for getting a job, a house, an Internet connection, almost everything you need in life.

Many people will say: “Who cares? You have nothing to hide, do you?”. Sure you do, I don’t know much people who would write their credit card credentials on their front door, for everybody to read. But this is not the point, it gets scary once the data collected will be used against you. Fraud with finger prints is absolutely not unheard of, the CCC already researched this in 2004. Identity theft will become much easier, since finger prints are stored in the RFID it is easily read out wirelessly. These can then subsequently be faked. People usually try to find a balance between privacy and safety for these kind of things. Since many highly value safety, they have no problem to turn in some of their privacy. The problem with finger prints is that it provides absolutely no safety at all.

An interesting remark I found on this was about access verification based on finger prints. Now that you have to carry your ID with you, with the finger prints on the RFID, you basically always carry your “password” with you. Free to read out from 5 to 100 meters. We can be pretty sure the encryption scheme for passports will be hacked, if it has not been hacked already.

Fortunately, I got a new identity card for travel in Europe last Summer, so I should be “safe” for another 4.7 years…

Unit testing the filter model

One thing that has been on my todo list for many years was writing proper unit tests for GtkTreeModelFilter (the “filter model”). The state keeping that the filter model has to do is enormously complex. Sadly, this has caused the filter model to get to a state where it was basically impossible to maintain it, a patch fixing something would almost always break something else. Getting out of such a state is generally only possible by bringing the entire thing under test. And that’s what I have done about 2 weeks ago and took a week to get the basics of the unit tests right.

The majority of the filter model code is now under test. Not only the correctness of the model’s structure is tested (are the right nodes there? Also at the correct position? Are the right nodes designated as parents? etc.), but also whether the right signals are emitted at the right moment (and with the correct details/arguments).

While writing the unit tests, 2 or 3 bugs were uncovered and also fixed. Using the unit tests I was also able to clear the long outstanding filter model bug reports from Bugzilla. Actually, being able to do that was the entire point of writing the test suite ;). When handling those reports, the usefulness of the unit tests immediately proved themselves: when patching one of the problems (with a fix that looked generally okay), one of the other tests started to fail. This regression would not have been noticed without the test suite.

Hopefully, we’ll soon get support for seeing the testing coverage (from what I heard there is a bug/patch for this in Bugzilla). Some parts of the filter model are not under test yet, most importantly the intricate reference counting of nodes. Some day I will get back to this.

What I am also hoping for is to re-use some of the concepts used for these unit tests in unit tests for other tree models. And, of course, to come up with a generic tree model tester that can be used to test custom tree models.

Many people might find such a generic tree model tester overkill and say that tree models must be much more trivial to implement. That’s something for the future really. I will promise to blog about the plans/ideas I have for GtkTreeView and friends later on. (You can imagine that a lot of ideas have been brewing while I was busy finishing my studies ;) ).

Oh by the way, currently I am doing some work on GTK+’s Quartz backend. It has suffered from some regressions after the introduction of client side windows in GTK+ and I am trying to get those under control as well as cleaning up the Quartz patch queue in Bugzilla. After that I will most probably be looking into extending/improving the CellEditable API to finally get proper acceptance/cancellation behavior.