Wahlcomputer sind angreifbar. Und werden es immer sein.

Viel zu leicht angreifbar, wie der CCC und andere Organisationen demonstriert haben. Und der Einsatz von Wahlcomputern ist daher ein ziemliches Risiko.

Bei einer klassischen Wahl wird natürlich auch mal versucht zu betrügen (z.B. von der CSU in Dachau), allerdings gestaltet sich das erheblich schwieriger.

Klassische Papierwahl hat zahlreiche Vorteile, unter anderem dass sie einfach von Wahlhelfern aller Parteien beobachtet werden können. Die Wahlzettel werden ausgegeben, und bei der Stimmabgabe wird der Wähler in der Liste abgehakt, und er darf genau einen Zettel in die Urne einwerfen. Die Listen können kontrolliert werden, Ausweise ebenso.

Jetzt bei einem Wahlcomputer - da kommt einfach am Ende ein Gesamtergebnis heraus. Aber wie das genau entstanden ist, kann keiner von uns verifizieren. Der Wahlcomputer könnte auf vielfache Weise manipuliert worden sein, und es gibt keine Möglichkeit, die Wahl erneut auszuzählen, oder Manipulationen nachzuweisen. Das System ist dazu viel zu komplex, und es ist niemandem möglich, die Korrektheit des Ergebnisses zu verifizieren.

Ein paar Manipulationsmöglichkeiten, die bei einfachen "Tests" nicht auffallen:

• es wird nur das Endergebnis falsch ausgegeben, wenn über 100 Stimmen vorliegen
• es wird nur am Wahltag manipuliert
• es werden nur die Stimmen bestimmter Namen manipuliert, z.B. alle mit einem 'a' im Familiennamen

Das andere Problem ist das des Wahlgeheimnisses. Computer verfügen über eine Uhr, und sind auf die angewiesen. Alles im Computer wird von einer Uhr gesteuert. Und nichts ist einfacher, als in dem Computer sämtliche Stimmabgaben zu protokollieren. Zusammen mit einer Überwachungskamera kann so sehr einfach ermittelt werden, wer wie abgestimmt hat. Wahlgeheimnis ade!

Vergleichen wir das wieder mit einer klassischen Wahl auf Papier: der Stimmzettel verschwindet in der Urne, und diese wird nacher - für jeden nachvollziehbar - gemischt. Die genaue Zuordnung Person und Stimme geht beim Einwerfen und Mischen verloren. Wahlbeobachter können die Urnen vor der Versiegelung inspizieren. Teilweise werden auch transparente Urnen eingesetzt. Jeder kann sehen wie die Wahlscheine beim Leeren der Urne durcheinanderpurzeln und dass da keine "Einwurfreihenfolge" festgestellt werden kann. Aber könnten Sie sicherstellen, dass der Computer nicht ihre Stimmabgabe protokolliert?

Wahlen müssen durch jedermann nachvollziehbar bleiben!

Deswegen E-Petition gegen den Einsatz von Wahlcomputern unterzeichnen. Direkt an den Petitionsausschuss des Deutschen Bundestags. Die Unterzeichnungsfrist endet am 28. November; es sind derzeit 22804 Unterzeichner.

Auch erreichbar über Bundestag.de, Petitionen, rechts "Übersicht über öffentliche Petitionen", Link in der Mitte, Übersicht, in der Liste auf "Wahlrecht: Stimmabgabe an Wahlgeräten".

I've been trying some stuff with the Turbogears application I worked on a bit during the last two weeks.

First thing was that I looked into using postgres as DB backend for Turbogears. Which turned up a bug in sqlalchemy (an ORM, mapping objects to database rows and back). I was passing a unicode string to the getBy function (to retrieve an object by it's primary key), and it went into the SQL statement without any quoting. Since my keys are all ascii, I could just cast them into regular string objects, and getBy worked then.

Performance with postgres is worse than with sqlite; this is not too surprising. However this might change once I enable multithreading.

Performance numbers: with SQLite: 8.30 trans/sec, with Postgres: 7.52 trans/sec

These performance numbers are still very bad, and I guess we won't be keeping Turbogears on the long run, unless I find some documentation on improving the speed. One of the hints I got was to avoid py:match in kid, the templating engine used. I started by not using turbogears "sitetemplate" default template. This would automatically insert javascript and css files when needed. Since I don't use their widgets and such, I havn't been using this feature anyway. Not using the template - which contains one py:match for the 'head' tag and one for the 'body' tag - improved performance to 9.01 trans/sec (or 8.32 trans/sec)

Now I can't explain why the improvements in the postgres run were better; both are a 10 minutes siege run. But 8.5% improvement is a start. I'll look into getting rid of the other py:match instances in our templates. (If I'd only find a good example with py:def - guess I'll instead "precompile" pre-templates into the actual templates or so instead with some self-written tool.)

P.S. No, I'll probably not use turbogears for my next similar project. Rapid development is nice, ORMs are fancy and such, but sometimes good old plain SQL can be very easy to use, too. And more performant.