Es war mir eine echte Freude, den Produktmanagertypen von Vitronic, der sich extra die Mühe gemacht hatte vorbeizukommen, mit meinen Fragen zum Schwitzen zu bringen. Überhaupt war es beeindruckend, welchen Aufwand die Gegenseite (also das bayerische Innenministerium) getrieben hatte. Alleine am Verteidigertisch saßen 6 Leute.

Am Ende interessierte das Gericht allerdings doch nur wieder die juristischen Feinheiten. Technische Probleme werden da nach Möglichkeit verdrängt.

Zitat Patrick Breyer:
“Der Verwaltungsgerichtshof hat die Berufung mit Urteil vom 17.12.2012 inzwischen leider zurückgewiesen, die Revision zum Bundesverwaltungsgericht jedoch wegen der grundsätzlichen Bedeutung der Streitfragen zugelassen. Die Urteilsbegründung liegt noch nicht vor. Sobald dies der Fall ist, wird über das weitere Vorgehen entschieden.” – besser könnte ichs auch nicht sagen.

Das Bundesverwaltungsgericht ist übrigens in Leipzig.

Vielen Dank an alle bisherigen Unterstützer!

Das Format zwingt einen dazu, sich wirklich gut vorzubereiten. Eine sehr spannende Erfahrung. Danke jennycolombo!

Check it out with your desktop browser, your smartphone and your tablet. It even degrades gracefully to Internet Explorer 8, though no zooming is possible there.

This posed a very interesting problem which I chose to solve with good old Perl.
Why Perl? Because it’s the absolute right thing to use, when you want to manipulate text!

It’s very fast, very stable, easy on resources and Perl has everything to build a proxy without using any additional software like Apache, Nginx, Squid or the like.

Mojolicious to the Rescue

It gets even easier, when you have an amazing framework like Mojolicious, which I stumbled upon a few months ago!

It calls itself “A next generation web framework for the Perl programming language”. It has no (I repeat that: NO!) mandatory module dependencies, features a full HTTP 1.1 web server (even non-blocking if you like) and also a HTML5/XML client complete with a DOM parser using CSS3 syntax jQuery style for accessing elements.

Additionally, it has a preforking non-blocking I/O server featuring hot deployment called “Hypnotoad“. And a heck of a lot more jokes in the source code comments taken from Futurama.

One of it’s primary goals is to bring back fun into coding web in Perl. And boy, did I have!

no Moose

Mojolicious has a great base class called Mojo::Base. It has all the syntactic sugar one wants, provides all the good switches (warnings/strict etc.), a default constructor and a ‘has’ accessor creator. Good riddance, Moose, you always bugged me with your weight!

So everything was there for this little project already. I just had to put the bricks together. And smooth it went!

The whole project took under 10 man-days to finish!

Lessons Learned

Configuration Files

One always needs configuration files, at least to store the database credentials somewhere. This application was no different.

When using Catalyst, it has a configuration file by default, which can be in any format one could possibly think of, thanks to Config::Any.
Mojolicious doesn’t bring configuration files by default, one has to build its own code for it. At first I built a class using YAML::Any, because I like YAML for configuration files very much.

But when working with Mojolicious for a while, one’s mindset changes: Why introduce this absolutely unneccessary dependency? Well, with Catalyst, one more to the hundreds doesn’t hurt. But Mojolicious is different: Why not use the provided Mojo::JSON instead?

So I quickly put together a class, which reads the configuration from a JSON file. While it’s not that flexible as YAML, JSON works well enough for the task. Absolute plus: No extra dependency introduced. Smooth.

Charset Guessing

While the DOM parser Mojo::DOM is very complete, I missed one thing, which is automatic charset guessing. Mojo tries to leave it’s fingers off the encoding as good as possible, so it’s easy to just proxy a file unmodified, but if you want to modify the content, you should make sure you know the encoding, so you’re not messing it up.

While it’s not a problem to build one’s own charset guesser, I nevertheless would like to see it in the Framework, because that’s where I think it belongs. (If it’s there already, please put my nose on it, because I couldn’t find it!)

I built the following guesser, which was purely by instinct and is most probably improvable:

sub guess_charset {
    my ($self, $content_type, $body) = @_;

    # Avoid undef warnings
    $content_type ||= '';
    $body ||= '';

    # HTTP Content-Type header
    if ($content_type =~ /charset=(.*)$/i) {
        return $1;
    }

    # XML prolog
    if ($body =~ /<\?xml .*encoding="(\S*?)".*\?>/si) {
        return $1;
    }

    my $dom = Mojo::DOM->new( $body );

    # <meta http-equiv="content-type">
    my $meta = $dom->at( 'meta[content*="charset"]' );

    if ($meta && $meta->attrs( 'content' ) =~ /charset=(.*)$/i) {
        return $1;
    }

    # HTML5 <meta charset="">
    $meta = $dom->at( 'meta[charset]' );
    if ($meta) {
        return $meta->attrs( 'charset' );
    }

    return;
}

Database Access

I came to love DBIx::Class as an ORM for database access. You need some patience to get acquainted with it, but then its great to work with, because it’s so complete. No comparison to the poor excuse of an ORM called ActiveRecords used in Rails.

The downside is, again, it introduces so many dependencies, you make your customer cry when trying to deploy your application.

Since my customers were no Perl guys, using DBC was out of the question. Instead I wrote a small model class for DB access, which allows named pre-prepared statements and polishes all the rough edges off DBI.

I hate having raw SQL statements between program code, because I so often see how it leads to bad style, SQL injections and inefficient database access. Therefore I put the statements in the config file and pre-prepare them on model construction. I know, there are issues with this, but I mind these. Promised.

I’ve done stuff like this so many times, and it seems goofy, to reinvent the wheel once again, but somehow, there are so many ways to talk with your database that nobody seems to be able to agree on some standards between a full fledged ORM and the absolute lowest level.

Anyway, the one issue I had with Mojolicious in this regard is this:

The Hypnotoad server does preforking which destroys all database connections done on startup, so one needs to connect only after forking.

I came across this wiki page where it is explained, and I at first opted for the DBIx::Connector solution, which doesn’t introduce too much dependencies and sounds like the fire-and-forget solution to all database connection problems.

Somehow, it did solve the problem, but we observed another issue: the connections dropped after some hours of operations, preferably after having some hours of traffic and then some without any.

So I got rid of the DBIx::Connector again and now handle dropped connections manually in the model class. Ironically far more stable and another dependency saved!

Static Routes

When doing a reverse proxy, Mojolicious::Static gets in your way. The nice it is to have some default output, so you have something to start from, you definitely don’t want to get served up the default Mojolicious favicon.

To get around this, I had to build a custom static file serving class, which actually does: nothing.

package Proxy::NoStatic;
use Mojo::Base 'Mojolicious::Static';

sub dispatch {}

1;

A little tedious and maybe this could be achieved simpler. However, this was the fastest I came up with.

Bottom Line

Mojolicious is by far the best framework for server side web development I came across in a long time. And I saw some: Spring 3, Rails, Catalyst, CakePHP, Yii, FuelPHP, Zend, CodeIgniter and not to mention the various home made ones I had the “pleasure” to work with…

I so much enjoyed it and I can’t wait for the next project to use it!

Thank you Sebastian Riedel for giving it to us!
And, btw., Sebastian: Mission accomplished!

The conference is very interesting, it almost seems like a family gathering, (well, a very big family – over 350 participants), accordingly the atmosphere is very friendly, also to newcomers. I was way overdressed with my suit, almost everybody was in shirts and jeans. While I mention that – the givaway goodies are great, I got a longsleeve shirt, a magnetic IPv6 address sticker and a pocket ruler! (There was even more, but I didn’t want to look too greedy…)

I definitely can recommend participating at a RIPE conference! If you can, stay the whole 5 days and definitely join the evening events. RIPE goes a long way to make it an enjoyable event for everybody!

Unfortunately my talk was the last one today, so I couldn’t speek with too many people afterwards, nevertheless, the conversations I had, were very intersting.

At the talk itself, and the discussion afterwards, I had a hard time transporting our issues on IPv6 privacy just right, unfortunately a not-so-small part of the tech community has the attitude that you can’t solve political issues with technical measures. My reply to that is: protocols, software, configuration is politics. Unfortunately this clear cut way of saying it didn’t come to my mind at the right moment.

Additionally I recognized once again, that the privacy discussion in german speaking countries is way ahead of many others, in some people’s view I was yet another german again concerned with privacy.

Some people afterwards told me, that a moderator was missing, and I definitely can confirm that.

On balance, it can’t say it was a success, but it wasn’t unsuccessful neather. I could drop our concerns there and I got a chance for a replay: One attendee wants to help me push the topic further in the community.

I hopefully get a chance then to clarify and crispen our concerns and arguments!

BTW: I learned that the BSI promotes the same goals as the AK Vorrat does!

I’m there for the german AK Vorrat to represent our view on privacy issues regarding IPv6.

I will be there the whole day and am happy to talk to you, too! Contact me, if you want to meet!

Zuerst einmal: Vielen Dank an alle Spender, die das möglich gemacht haben!

Das mediale Interesse im Vorfeld war eher moderat, inzwischen fängt die Sache aber an, zu fliegen. Die Abendzeitung München berichtete gestern über die Aktion, und prompt steht das Fernsehen auf der Matte.

Vermutlich ist der Wirbel um den Staatstrojaner für die erhöhte Aufmerksamkeit nicht ganz unschuldig.

Noch ist aber nichts im Kasten, deshalb möchte ich noch nicht zu viel verraten.

Jetzt erst einmal ein paar

Fakten aus der Verhandlung

Das Gericht hat diese erst einmal vertagt. Erst einige Tage vor der Verhandlung ging uns und dem Innenministerium ein 32-teiliger Fragenkatalog des Senats zu dem Thema zu, in dem das Innenministerium bzw. die Polizei recht detailiert zu dem ganzen Sachverhalt Sstellung nehmen muß.

Selbst in dem 4,5h Verhandlungsmarathon konnte nicht alles umfassend geklärt werden, trotz 4 anwesender Mitarbeiter der Polizei und des Ministeriums plus Anwältin.

Wir warten also auf deren schriftliche Stellungnahme, für die sie 6 Wochen Zeit haben, anschließend haben wir nochmal 2 Monate Zeit für eine Antwort, danach will der Senat evtl. eine weitere mündliche Verhandlung ansetzen, u.U. mit dem bayerischen Datenschutzbeauftragten Thomas Petri.

Bei den Fragen des Senats mußten die Beamten doch deutlich weiter die Hosen herunterlassen, als sie es gerne getan hätten, das überhebliche Lächeln aus der ersten Verhandlung 2009 war dementsprechend nicht mehr in den Gesichtern zu erkennen.

Soweit, den Staatsbeamten eine aktuelle Liste der Standorte der Erfassungsgeräte abzunötigen, ging das Gericht nun allerdings leider doch nicht.

Ich fasse hier mal meine

Erkenntnisse über die Erfassungsgeräte

zusammen:

Es gibt momentan 25 AKEs (Automatische Kennzeichen Erkennungssysteme) oder auch AKLS (Automatische Kennzeichen Lese Systeme), davon sind 3 mobile Geräte.
Höchstvermutlich sind alle Systeme von der Firma Vitronic aus Wiesbaden.

Die mobilen Geräte sehen in etwa aus, wie ein normales Geschwindigkeitsmessgerät (Blitzgerät), können zwei Fahrspuren auf einmal überwachen und wurden im letzten Jahr zweimal eingesetzt. (Wir konnten ein Photo davon sehen.)

Die restlichen 22 Anlagen sind fest montiert, einige von denen waren früher auch mobil und stammen offenbar aus dem früheren Pilotprojekt an den Grenzübergängen, das aufgrund fehlender nötiger Gesetze eingestellt wurde.

Auch die ex-mobilen Geräte überwachen zwei Spuren, die original festen jeweils nur eine, deshalb ergeben sich folgende Zahlen: Es gibt 22 fest installierte AKEs, die 30 Fahrspuren auf 12 Standorten überwachen.

Die fest installierten Anlagen laufen 24/7 durch, sie nehmen die Fahrzeuge von hinten auf und sind auf bayerischen Autobahnen und einer Europastraße auf Schilderbrücken montiert.

Die Erkennung wird durch eine Laserschranke ausgelöst. Die AKEs arbeiten mit einem Videobild im Infrarotbereich, das verstärkt wird durch einen Infrarotblitz, der entsprechend für menschliche Augen nicht sichtbar ist.

Wir konnten ein solches Bild sehen, es ist schwarz/weiß, hat einen sehr hohen Kontrast, das Kennzeichen ist, v.a. auch bedingt durch die Reflexfolierung vieler Kennzeichentafeln recht deutlich zu erkennen, Rückleuchten kann man erkennen, den Rest des Fahrzeugs dagegen kaum.

Am Fahrbahnrand stehen “Betonkästen” die einen Rechner enthalten, auf dem eine Datenbank läuft, die sämtliche aktuell zur Fahndung ausgeschriebenen Kennzeichen enthält. Gegen diese Datenbank wird ein erkanntes Kennzeichen abgeglichen, und wenn ein vermutlicher “Treffer” vorhanden ist (Treffer ist nicht gleich Treffer, dazu später mehr), dort eingetragen und an die Verkehrsleitstelle übermittelt. Bei den mobilen Anlagen wird das stattdessen auf einem Laptop im Einsatzfahrzeug gemacht.

Der Rechner am Fahrbahnrand wird regelmäßig aktualisiert, mit einem Extrakt aus INPOL und SIS, allerdings ohne die Fahndungen nach dem Pflichtversicherungsgesetz.

Alle, die Ihre KfZ Versicherung nicht bezahlt haben, können also aufatmen.

Laut Aussagen der Ministerialbeamten enthält dieser Extrakt nur die Kennzeichen, keine weiteren Daten wie z.B. Fahndungsgrund.

Die Datenanbdingung ist teilweise kabelgebunden, teilweise via UMTS.

Fußballfans aufgepasst! Bei besonderen Anlässen können zusätzliche Fahndungsdaten eingespielt werden, insbesondere der Begriff “Datei Gewalttäter Sport” fiel in diesem Zusammenhang. Wobei zeitnah die aktuellen Zulassungsnummern der Fahrzeuge der Delinquenten ermittelt werden.

Globalisierungsgegnern dürfte vermutlich eine ähnliche Behandlung zuteil werden.

Nachdem das Ministerium in letzter Zeit mehrere parlamentarische Anfragen zu statistischen Daten bekommen hat, wurde die Software im Juli um eine statistische Zählung erweitert. Aus den Monaten Juli, August und September 2011 ergeben sich demnach folgende Zahlen:

• 8 Mio. überprüfte Fahrzeuge pro Monat
• 40.000 – 50.000 vom System vermutete Treffer / Monat
• 500 – 600 echte Treffer / Monat
• 30 – 35 sichergestellte Fahrzeuge / Monat

Treffer nicht gleich Treffer

Da das Erkennungssystem keinerlei Semantik kennt, also ausländische von inländischen Nummern nicht unterscheiden kann und ebenso durch das SIS mit Fahndungen vieler verschiedener Länder abgeglichen wird, ergeben sich vergleichsweise viele falsche Treffer (“False Positives”).

Die Beamten in der Leitstelle haben dementsprechend viel zu tun, zu überprüfen, ob es nun wirklich ein echter Treffer ist.

Mehr zum Ablauf in der Leitstelle und zur verwendeten Software dann bald im nächsten Artikel!

Am Montag, 17.10.2011 um 14 Uhr findet das Berufungsverfahren vor dem bayerischen Verwaltungsgerichtshof statt.

RA Dr. Udo Kauß aus Freiburg wird mich vertreten. Er hat schon mehrere Prozesse zu diesem Thema begleitet.

Vielen Dank an dieser Stelle noch einmal für die Spenden, die dieses Verfahren möglich machen!

Die wichtigsten Tools

• Firebug, Netzwerk Tab -> zeigt Ladezeiten und Cache Hits
• Firbug Add-Ons machen Performance Analyse und geben viele gute Hinweise:
  • Yahoo’s YSlow (Erläuterungen)
  • Google’s Page Speed (Erläuterungen)

Die relevanten HTTP Header

Quelle: HTTP/1.1 Header Field Definition

Expires

• Erklärt Ablaufdatum der Resource
• Browser macht keinen Request mehr vor Ablauf dieses Datums

Cache-Control

• public: Aktiviert Proxy Caching und Caching im Firefox bei SSL Verschlüsselung
• no-cache: Deaktiviert Caching
• no-store: Keinerlei Speicherung, noch härter als “no-cache” (gedacht für Backups etc…)
• max-age: Ablaufzeit in Sekunden, redundant zu Expires
• must-revalidate: Immer Server fragen, ob Resource abgelaufen ist
• (es gibt weitere, die vor allem für Proxies relevant sind)

Last-Modified

• Erklärt letztes Änderungsdatum
• Browser schickt einen If-Modified-Since Header beim nächsten Request
• Server kann ein 403 Not Modified zurückschicken, Browser nutzt Caching Daten

ETag

• “Entity Tag”
• Ist eindeutige ID bzw. Hash einer Resource
• Apache verwendet z.B. dafür Last-Modified-Timestamp, Dateigröße und iNode ID, kann aber beliebig gewählt werden
• Browser schickt einen If-None-Match Header beim nächsten Request
• Server kann ein 403 Not Modified zurückschicken, Browser nutzt Caching Daten

Erkenntnisse

• Expires und Cache-Control: max-age sind gut, um Anzahl der Requests zu drücken
• Last-Modified und ETag sind gut, um die Datenmenge zu reduzieren
• Expires und Cache-Control: max-age sind redundant, besser nur eins von beiden verwenden
  • Weniger HTTP Overhead
• Last-Modified und ETag sind redundant, besser nur eins von beiden
  • Weniger HTTP Overhead
  • Wenn beides verwendet wird, muß auch beides geprüft werden!
• Optimales Caching: Resource muß nur ein einziges Mal geladen werden, dann keine weiteren Requests mehr
  • Expires in Jahr in die Zukunft setzen
  • Wenn sich Resource ändert, URL ändern (z.B. mit Versionsnummer oder Hash)
  • Das geht nur, wenn das gesamte System (die Webapplikation) darauf ausgelegt ist!

Diskussion

ETags sind in Applikationen etwas leichter zu handhaben als Last-Modified Timestamps, da ein einfacher Stringvergleich ausreicht. Timestamps müssen erst umständlich in UNIX Epochen umgewandelt und verglichen werden, bzw. durch aufwändige Klassen gejagt werden.

Dabei sind sie flexibler zu handhaben – Ein ETag kann aus irgendwelchen Daten bestehen, nötigenfalls aus der Summe mehrerer Metadaten mehrerer Elemente.

Für einfache Szenarios (z.B. Bilder, die von der Applikation serviert werden) reicht als Seed für den ETag ironischerweise meist ein Timestamp einer Datei. Mehrere Seeds erhöhen den I/O oft unnötig, können jedoch im Zweifelsfall jederzeit leicht hinzugefügt werden.

Empfehlung von YSlow und Page Speed ist, immer ein Expires und/oder ein Cache-Control zu senden. Bei Resourcen, die sich jederzeit ändern könnten, fühlt sich das allerdings relativ nutzlos an. Der Selbstversuch bestätigt das erwartete Standardverhalten der Browser, immer beim Server nachzufragen, solange der Server nicht explizit ein Expires gesetzt hat. Von öminösen Heuristiken war nichts zu bemerken. Insofern verbrauchen diese Header bei derartigen Resourcen erst einmal nur Bandbreite.

Dennoch bin ich natürlich an guten Gründen interessiert, Expires und/oder Cache-Control bei Resourcen mit unbekanntem Ablaufdatum einzusetzen!