Nach Hause telefonieren?

Oder: Zahlen mit der Unicard.

[Ich bin ein Grundsatzartikel und keineswegs die Meinung des Unicardausschusses oder aller seiner Mitglieder]

Ein zentraler Punkt des seit Jahren diskutierten Unicardkonzepts ist die Bezahlfunktion. Im folgenden Artikel wird es um Möglichkeiten gehen, die Bezahlfunktion in den Mensen des Studentenwerks und an den öffentlichen Kopiergeräten der Universität in die Unicard zu integrieren.

Im Unicardausschuss gibt es auch Überlegungen, wie die Bezahlfunktion von der Unicard entkoppelt, aber dennoch möglichst einfach und einheitlich umgesetzt werden kann. Dies wird hier nicht thematisiert.

Aktuelle Situation

In den Mensen und Wohnheimen des Studentenwerks wird ein chipkartenbasiertes System der Firma InterCard® eingesetzt. Das Bezahlen an den öffentlichen Kopiergeräten der Universität läuft über ein System der Firma Schomäcker.

Was soll auf die Karte?

Es gilt, zwei zentrale Fragen zu beantworten:

  1. Sollen zwei getrennte Geldkonten auf der Karte verwaltet werden oder ein gemeinsames für beide Systeme?
  2. Wird der „Kontostand“ auf der Karte gespeichert (offline) oder bei Uni/Studentenwerk auf einem Server (online)?

Mit ein bisschen Kombinatorik wird klar, dass es damit insgesamt 4 grundsätzliche Systemkonzepte gibt. Diese will ich kurz vorstellen und die Vor- und Nachteile aus Studierendensicht beleuchten.

Kontoführung

In den folgenden Schaubildern werden 2 Karten verwendet: Eine mit 2 integrierten Konten, eine mit nur 1 Konto, jeweils mit zufällig ausgewürfelten Konto-IDs:

kontenvergleich

 

2 Konten – offline

Die Information, wie viel Geld für welches System auf welcher Karte ist, wird allein auf der Karte selbst gespeichert. Die Bezahlsysteme von Uni und Studentenwerk bedienen sich jeweils an „ihrem“ Konto, respektive erhöhen das jeweilige Guthaben.

Im Schaubild ist die Kommunikation der Karte mit dem jeweiligen Terminal schematisch dargestellt: Ein Kopiervorgang im Wert von 30 ct und eine Aufladung des Mensakontos um 20 € + 30 ct Zulage.

2 Konten - offline

(zum Vergrößern auf das Bild klicken)

Man sieht, dass die Terminals nur den aktuell gespeicherten Betrag der Karte abfragen und einen aktualisierten Betrag setzen. Die Abfrage etwa einer vorhandenen Konten- oder Karten-ID ist nicht nötig. Uni und Studentenwerk würden allerdings wohl gern mitprotokollieren wollen, welche Karte wie viel Guthaben anhäuft und verbraucht, um Manipulationen, beispielsweise durch Kartenklonen1, zu erkennen.

Vorteile

  • Ohne Protokollierung ist nicht nachvollziehbar, wer wann wo was bezahlt hat
  • Lokale Operationen – netzwerkunabhängig

Nachteile

  • Konten müssen getrennt aufgeladen werden
  • Bei Kartenverlust ist das Guthaben auch futsch

Aber warum brauchen wir eigentlich zwei getrennte Konten?

1 Konto – offline

Werfen wir wieder einen Blick auf das Schaubild – jetzt mit einem gemeinsam genutzten Konto. Dargestellt ist der Kopiervorgang im Wert von 30 ct, gefolgt von der Aufladung um 20 € + 30 ct.

1 Konto - offline

(zum Vergrößern auf das Bild klicken)

Auch hier wird der Kontostand von der Karte abgefragt, die Unterscheidung der Konten entfällt. Dies macht es den beteiligten Parteien selbst mit Abfrage der ID praktisch unmöglich, „bösartige“ Manipulationen am Guthaben zu erkennen, ohne untereinander Daten über Aufladungen und Abbuchungen auszutauschen. Wenn beispielsweise zwischen zwei Bezahlvorgängen am Kopierer der Kontostand um 20,30 € steigt, weiß die Uni nicht, ob die Karte am STW-Terminal aufgeladen oder etwa auf einen früheren Stand zurückgesetzt wurde. Ein dritter Partner der die Unicard als Zahlungsmittel akzeptiert würde es allen Teilnehmern noch mehr erschweren, Zahlungsvorgänge bei den jeweils anderen Stellen nachzuvollziehen. Bei nur zwei Partnern müssen Differenzen zwischen zwei Zahlungsvorgängen ja logischerweise durch Zahlungen/Gutschriften beim jeweils anderen Partner entstanden sein. Bei drei Partnern muss man bereits raten, wo das Geld überhaupt ausgegeben wurde.

Vorteile

  • Ohne Protokollierung ist nicht nachvollziehbar, wer wann wo was bezahlt hat
  • Einmal aufladen – überall bezahlen
  • Lokale Operationen – netzwerkunabhängig

Nachteile

  • Bei Kartenverlust ist auch hier das Guthaben futsch

Mehr Technik! Mehr Netzwerk! Mehr Buzzwords!

2 Konten – online

Jetzt verlagern wir den Ort, an dem das Guthaben verwaltet wird, in die Cloud. Pardon, auf einen voll sicheren Server ins Uni-/STW-Intranet meine ich natürlich. Die Kommunikation ist hier ein wenig anders:

2 Konten - online

(zum Vergrößern auf das Bild klicken)

Das jeweilige Terminal fragt von der Karte lediglich die Konto-ID ab und telefoniert dann „nach Hause“. Zum Kontoverwaltungsserver werden die ID und der zu buchende Betrag gesendet. Der Server antwortet entweder mit einer Bestätigung oder einer Fehlermeldung, zum Beispiel wenn das Guthaben aufgebraucht ist. Zur Erstattung von Guthaben bei Kartenverlust sollte man sich die Konten-IDs oder etwas vergleichbares notieren können.

Vorteile

  • Uni und Studentenwerk interessieren sich nicht für Buchungen des jeweils anderen
  • Bei Kartenverlust kann Restguthaben gerettet werden

Nachteile

  • Beide Konten müssen getrennt aufgeladen werden
  • Bei einem Netzwerkausfall sind keine Buchungen mehr möglich
  • Wenn der Server kaputt geht sind alle Guthaben futsch2

Wieso legen wir die beiden Konten nicht einfach zusammen?

1 Konto – online

Im letzten Schaubild für heute gibt es einen grundlegenden Unterschied zu den drei anderen. Während bisher das Guthaben entweder von jeder Stelle für sich oder dezentral auf den Karten verwaltet wurde, gibt es nun einen einzigen Server, der über das Guthaben auf der Karte Bescheid weiß. Ob dieser bei Uni oder Studentenwerk steht ist technisch egal, vermutlich würde er allerdings bei einer solchen Lösung bei der Universität landen.

Dieser „Clearingserver“ empfängt nun alle Buchungen aller Terminals und sorgt dafür, dass das Studentenwerk alle Beträge, die bei ihm mit Karte bezahlt werden, auch übermittelt bekommt.

1 Konto - online

(zum Vergrößern auf das Bild klicken)

Das Studentenwerk braucht gar nicht zu wissen, wer da jetzt eine bestimmte Buchung vorgenommen hat. Kritisch betrachten sollte man hier hingegen, dass die Uni Einblick in alle Buchungen bekommt, an denen sie eigentlich gar nicht beteiligt ist.

Vorteile

  • Einmal aufladen – überall bezahlen
  • Bei Kartenverlust kann Restguthaben gerettet werden

Nachteile

  • Bei einem Netzwerkausfall sind keine Buchungen mehr möglich
  • Was geht es die Uni an, wofür ich mein Geld in der Mensa ausgebe?
  • Wenn der Server den Geist aufgibt, sind die Guthaben futsch

Sonstiges

Natürlich sind auch Mischformen denkbar, etwa eine kombinierte Speicherung des Guthabens auf einem Server und auf der Karte. Was passiert, wenn die beiden Werte plötzlich unterschiedlich sind, ist allerdings unklar – vermutlich würde dann einfach der geringere der beiden Werte genommen.

Fazit

Die 1-Konto-offline-Lösung ohne Mitprotokollierung von ID oder Sonstigem wäre mir als Student am liebsten, auch wenn dann bei Kartenverlust halt 20 € oder so weg sind. Wenn das Guthaben unbedingt auf einem Server gespeichert werden muss, dann wäre es mir datenschutztechnisch lieber, wenn Uni und Studentenwerk ihre jeweiligen Konten getrennt verwalten würden.

  1. siehe der Artikel zu den Wahlen
  2. Sie haben doch sicher ein funktionierendes Backup?

Spielereien mit Sainte-Laguë/Schepers

Wenn die neue Satzung mal kommt (bald, gell), dann werden die Sitze im SP nicht mehr nach d’Hondt, sondern mach Sainte-Laguë/Schepers verteilt.

Während die Klassiker sowohl beim d’Hondt-Verfahren als auch beim Sainte-Laguë/Schepers-Verfahren die Höchstzahlverfahren sind, bei denen eine große Tabelle mit Divisionsergebnissen gefüllt wird, habe ich mich in meiner Umsetzung am Divisorverfahren vergriffen. Der Vorteil des Divisorverfahrens ist, dass man sich nicht die ganze Tabelle merken und auch nicht ständig Maxima finden muss, sondern nur nach einem Teiler sucht, mit dem bei Standardrundung die richtige Sitzzahl herauskommt.

stlgs-image

Meine Implementierung lässt sich auf http://mst.hszemi.de/stlgs-web/ ausprobieren. Der Sourcecode liegt bei GitHub.

Technisch läuft das ganze mit reinem HTML/JavaScript, beim Hinzufügen und Entfernen von Hochschulgruppen hilft der Einfachheit halber jQuery.

Als kleines Schmankerl kann man sich auch noch direkt die Verteilung anzeigen lassen, die entstanden wäre, wenn die Sitze des letzten Studierendenparlaments bereits mit Sainte-Laguë/Schepers verteilt worden wären.

Wahlen mit der Unicard

[Ich bin ein Grundsatzartikel und keineswegs die Meinung des Unicardausschusses oder aller seiner Mitglieder]

DAS Top-Ereignis in der Bonner Hochschulpolitik sind wohl jedes Jahr die Wahlen zum Studierendenparlament und zu den Gremien der Universität. Ansonsten können die Studierenden noch ihre Fachschaft wählen, aber für die meisten war’s das dann wieder für ein Jahr mit der Mitbestimmung.1

Im Folgenden werde ich mich vorrangig auf die SP-Wahl und die damit zusammen durchgeführten Gremienwahlen konzentrieren und die Fachschaftswahlen  erwähnen wo es angebracht erscheint. Nicht behandelt werden Personen, die keine Unicard nutzen wollen. Dies ist nochmal ein anderer großer Themenkomplex.

Der aktuelle Studierendenausweis erfüllt bei den Wahlen zwei Funktionen:

  1. Wahlberechtigung: Wer darf was wählen?
  2. Wahlnachweis: Wer hat schon gewählt?

Wie können diese Funktionen bei Einführung der Unicard umgesetzt werden?

Wahlberechtigung

Die Wahlberechtigung für den Fakultätsrat bzw. das BZL ergibt sich aus der aufgedruckten Zahl im Feld „Gremienwahlen“ auf der Rückseite des Ausweises. Die Wahlberechtigung für die Fachschaft gilt für das Studienfach, das mit einem Sternchen markiert ist.

An jeder Urne gibt es außerdem eine „Negativliste“, in der unter anderem solche Personen stehen, die trotz Studierendenausweis keine Wahlberechtigung haben.

Druckt man die Informationen des aktuellen Ausweises auch auf die Unicard, bleibt beim Nachweis der Wahlberechtigung alles beim Alten.

So einfach wäre das. Kommen wir nun zum

Wahlnachweis

Bei den Wahlen zu SP, Gremien und Fachschaft besteht der Witz darin, dass jede wahlberechtigte Person nur 1 Stimme abgeben darf.

Derzeit wird das dadurch sichergestellt, dass bei der Stimmabgabe ein Loch in das dafür vorgesehene Feld des Studierendenausweises gestanzt, oder für Fachschaftswahlen im Wintersemester das Feld anderweitig ungültig gemacht wird.

Eine Unicard, die über mehrere Semester hinweg nicht ausgetauscht wird, ist nun nicht dazu geeignet, Löcher hineinzustanzen. Bei Chipkarten kann dies nebenbei bemerkt auch die Funktionalität einschränken. Wie kann also anders sichergestellt werden, dass jede Person nur maximal 1 Stimme pro Wahl abgibt? 2 Möglicherweise bietet es sich auch an, den Wahlnachweis physisch von der Unicard zu trennen.

1. Wahlbenachrichtigung

Das Konzept

Jede/r Wahlberechtigte bekommt vor der Wahl eine persönliche Wahlbenachrichtigung, die bei der Stimmabgabe vorgezeigt werden muss und dann ungültig gemacht wird.

Vorteile:

Das System bleibt gleich: An der Urne wird ausgestanzt.

Dezentrale Datenhaltung: Es ist schwer, viele Personen mehrmals wählen zu lassen (mehr dazu später bei zentraler Datenhaltung).

Nachteile:

Anders als der Studierendenausweis, den man quasi täglich benötigt, geht eine solche Wahlberechtigung vermutlich leichter verloren und der Verlust bleibt länger unbemerkt.

„Irgend jemand“ muss die Kosten für die Erstellung und den Versand von >30.000 Wahlbenachrichtigungen tragen – Geld, das durch den Umstieg auf Chipkarten und den damit verbundenen Wegfall von Druck und Versand neuer Studierendenausweise eigentlich eingespart werden könnte. Selbst bei Fachschaftswahlen mit weitaus weniger Wahlberechtigten entstünden Kosten von geschätzt 60 ct pro wahlberechtigter Person, nicht pro Wähler/in.

Zu guter Letzt wäre eine Wahlbenachrichtigung vermutlich weniger fälschungssicher als der Studierendenausweis.

2. „Flags“ auf der Karte

Oder nennt es „Token“ wenn ihr wollt.3

Das Konzept

Auf der Unicard wird digital die Information gespeichert, ob die entsprechende Person für das entsprechende Gremium bereits gewählt hat oder nicht.

Vorteile:

Dezentrale Datenhaltung: Es ist schwer, viele Personen mehrfach wählen zu lassen.

Nachteile:

Man sieht einer Karte nicht an, ob schon gewählt wurde oder nicht. Es ist also an jeder Urne zusätzliche Hardware in Form von Laptop und Kartenschreib/lesegerät nötig.

Mehrfaches Wählen bleibt verboten, wird aber einfacher als zuvor. Indem die Karte auf den Zustand vor der Wahl zurückgesetzt wird, sieht es für die Wahlhelfer so aus, als habe die betreffende Person noch nicht gewählt. Eine solche Manipulation fällt nur beim extrem aufwendigen Kreuzvergleich aller Urnenbücher auf.

Das zurücksetzen der Flags passiert dabei folgendermaßen (sehr stark vereinfacht, aber mit hübschen Bildchen): 0 stehe dabei für „hat noch nicht gewählt“, 1 für „hat bereits gewählt“.

Wahlen-flags vorher-nachher

Daten auf der Karte sind nicht verschlüsselt: Durch vorher-nachher-Vergleich werden die entsprechenden Bits auf der Karte identifiziert und dann immer wieder in den Zustand „hat noch nicht gewählt“ gesetzt.

Wahl verschlüsselte Karten

Daten auf der Karte sind verschlüsselt: Wahrscheinlich können die für den Wahlnachweis verantwortlichen Bits nicht mehr identifiziert werden. Vor dem Wahlgang wird einfach eine Kopie der gesamten Karte angelegt und nach dem Wahlgang wieder zurückgespielt. Sofern zwischendurch nichts mit der Karte bezahlt wurde lässt sich die Manipulation nicht feststellen, da die Daten auf der Karte konsistent und korrekt verschlüsselt sind.

Jetzt mag der Einwand kommen „das geht sicher nicht so einfach“: Da die Flags bei diesem Verfahren sowieso mindestens jedes Jahr zurückgesetzt werden müssen, ist dies technisch grundsätzlich möglich. Die Frage ist nur, wie viel Aufwand betrieben werden muss.

Auf zum nächsten Verfahren:

3. Wahlberechtigtenverzeichnis mit Abhaken

Das Konzept

An der Urne liegt ein ausgedrucktes Verzeichnis der Wahlberechtigten. Wer wählt, wird abgehakt. Wer abgehakt ist, darf nicht mehr wählen.

Vorteile:

Sofern der Kuli nicht versagt oder das Wahllokal sich spontan selbst entzündet, ist die Ausfallwahrscheinlichkeit sehr gering.

Nachteile:

Unzureichende Synchronisation: Sobald mehr als 2 Urnen im Einsatz sind, weiß die eine Urne nicht, wer gerade an der anderen Urne gewählt hat.

Zentrale Datenhaltung: Falls das Verzeichnis im Lauf der Wahl verloren geht, kann man die gesamte Wahl in die Tonne kloppen, da nicht mehr nachvollziehbar ist, wer bereits gewählt hat.

Schlechte Skalierbarkeit: Bei Fachschaftswahlen mit 1 Urne und < 2000 Wahlberechtigten ist das Verfahren mit < 30 Seiten vermutlich noch gut handhabbar. Für SP- und Gremienwahlen mit 30.000 Wahlberechtigten hat so ein Verzeichnis über 400 Seiten, der Wahlakt wird durch seine schiere Größe immens verzögert.4

4. Online-Wahlberechtigten-Verzeichnis

Das Konzept

Beginnen wir mit einem Schaubild:

wahl_db

Schema: Wahlnachweis mit Datenbanksystem (Das muss nicht beim HRZ stehen, es dient hier als Beispiel)

Das Datenbanksystem beim HRZ speichert zu jeder/jedem Wahlberechtigten zu jedem Gremium die Information, ob die Person schon gewählt hat oder nicht.

Das Wahllokal meldet sich am Datenbanksystem an und überprüft mit seiner Hilfe, ob die Person die gerade wählen will dies schon getan hat oder sonstwie auf einer Negativliste steht. Ist die Person wahlberechtigt, bekommt sie die Wahlunterlagen.

Bei Einwurf der Stimmzettel in die Urne wird dem Datenbanksystem vom Wahllokal mitgeteilt, für welches Gremium die Person gewählt hat.

Im Wahlbüro, in dem die Wahlleitung sitzt, werden alle Änderungen an der Datenbank einerseits sofort auf einem Papertrail aufgezeichnet und optional auch auf einer Live-Anzeige ausgegeben. Dies dient dazu, Manipulationen am Datenbanksystem teilweise erkennen zu können.

Vorteile:

Unabhängig von der Umsetzung des Studierendenausweises.

Nachteile:

Es werden Laptops für die Wahllokale und das Wahlbüro sowie ein spezieller Drucker zur Erzeugung des Papertrail benötigt.

Das System ist abhängig von der Stromzufuhr und der Verfügbarkeit einer Internetanbindung. Die Wahllokale können nicht mehr frei platziert werden.

Zentrale Datenhaltung: Wenn jemand5 die Möglichkeit zur Manipulation des Datenbankservers erlangt, hat der Wahlausschuss verloren. Wenn der Server den Geist aufgibt, was nach Murphy’s Law immer in der Wahlwoche passiert, ist nur noch über den Papertrail nachvollziehbar, wer bereits gewählt hat. Die Wahl muss dann unterbrochen werden. Auch wenn im Wahllokal oder Wahlbüro die Verbindung zum Server abbricht, muss der Wahlvorgang gestoppt werden.6

5. Wahl über eine Umfrage in eCampus oder BASIS

*facepalm*

Fazit

Es gibt Möglichkeiten, mit oder ohne Einbindung der Unicard die Wahlen zu SP, Gremien und die Fachschaftswahlen ordnungsgemäß durchzuführen. Die Liste ist naürlich keinesfalls vollständig. Eine Kombination der Verfahren 2. und 4. scheint mir momentan am sichersten wenn es funktioniert, allerdings auch am störanfälligsten. Der Unicardausschuss wird sich mit der Fragestellung sicherlich auch bald beschäftigen.

  1. Was nicht heißt, dass es nicht weitere Möglichkeiten zur Einflussnahme auf die Hochschulpolitik hier gibt.
  2. Gehen wir mal realistischerweise davon aus, dass die Unicard eine Chipkarte wird
  3. Siehe akut 329 Seite 8ff.
  4. Schätzung mit 70 Einträgen pro Seite in Schriftgröße 9
  5. Tante Erna, böse Informatiker, die Kinesen,…
  6. Die Frage bei so etwas ist nicht, ob, sondern wann es passiert, und wie man es kompensieren kann.