Benutzer:Haibaer/Token-Generator
Inhaltsverzeichnis
Konzept eines Token-Generators für Piraten
Motivation
In Liquid Feedback kann man zum einen nur namentlich abstimmen und zum anderen kann ein Admin auch abgegebene Stimmen manipulieren und Vorwürfe mit einem "Du hast Dich wohl verklickt" abbügeln.
Allerdings ist es ja dank API einfach möglich, ein paralleles System zu entwickeln, in dem alle in LF zur Abstimmung stehenen Themen abgestimmt werden können. Dies würde das Konzept "Liquid Democracy" insofern aufweichen, dass man die zur Abstimmung stehenden Initiativen/Anträge "liquide" ermittelt, dann aber direktdemokratisch abstimmt. Dieses würde jedem Piraten die Teilnahme an Liquid Feedback ermöglichen ohne sein komplettes Abstimmverhalten offenlegen zu müssen.
Um sicherzustellen, dass sich nur Piraten an den Abstimmungen beteiligen, wird ein dreiteiliges Konzept vorgestellt. Das komplette Abstimmungssystem besteht aus drei Komponenten: Einem Token-Generator, einem Stimmen-Akkumulator und einer Client-Software (Puristen können aber auch alles mit der Shell erledigen). Jede dieser drei Komponenten kann und sollte unabhängig von der anderen entwickelt und betrieben werden.
Der Token-Generator selbst lässt sich auch noch für andere Systeme nutzen.
Token-Generator
Der Token-Generator erzeugt für jede Abstimmung entsprechende Einmal-Tokens und verteilt diese an alle Piraten, die an diesem System teilnehmen wollen. Zur Teilnahme benötigt man einen Teilnahmecode. Dieser wird ähnlich gehandhabt wie die Invite-Codes (also direkt beim Gensek hinterlegt oder bei Bedarf auch noch eine Clearingstelle dazwischengeschaltet).
Piraten, die am System teilnehmen können, registrieren sich beim Token-Generator mit diesem Invite-Code. Zusätzlich zum Invite-Code wird auch noch eine gültige Email-Adresse des Piraten benötigt (welche eine andere sein kann als die in der Mitgliederverwaltung hinterlegte). Optional kann der Pirat auch noch seinen PGP Public Key hinterlegen, falls er die Tokens verschlüsselt zugeschickt bekommen möchte.
Optionales Datenschutzfeature: In der Datenbank hinterlegt werden bei Bedarf jedoch nur die Email-Adresse sowie die Dauer der Gültigkeit. Dann müssen sich die teilnehmenden Piraten allerdings regelmäßig neu anmelden; der GenSek muss neue Codes verschicken, etc. Verzichtet man auf diesen Komfort, so lässt sich letztendlich im System eine Verknüpfung Mitglied <=> Abstimmungs-Email-Adresse herstellen (welches allerdings auch nicht weiter tragisch ist)
Wird eine Abstimmung in Liquid Feedback begonnen (das ist über die API-Funktionen ermittelbar), so wird ein Prozess "Versand von Abstimmungstokens" angestoßen:
- Es wird eine "Abstimmungs-ID" gebildet
- Die im System hinterlegten Email-Adressen werden alle in zufälliger Reihenfolge "abgearbeitet" (Ziehen ohne Zurücklegen):
- Es wird ein Zufallsstring gebildet
- Es wird ein PGP-Schlüsselpaar erzeugt
- Abstimmungs-ID, Zufallsstring und PGP Private Key werden an die Email-Adresse versendet (und optional mit dem im System hinterlegten PGP Public Key verschlüsselt)
- Abstimmungs-ID, Zufallsstring und PGP Public Key werden in eine temporäre Datei geschrieben
- Die Daten in der temporären Datei werden erneut zeilenweise randomisiert und veröffentlicht (d.h. es werden alle gültigen Abstimmungs-Tokens (Abstimmungs-ID+Zufallsstring) mit dem zugehörigen PGP Public Key veröffentlicht.
Client-Software
Möchte der Nutzer sich an der Abstimmung beteiligen, so öffnet er den Abstimmungsclient und gibt die per Email erhaltenen Daten ein (konkret kann das so aussehen, dass die Abstimm-Tokens vom Token-Generator in einem TGZ-Archiv als Mail-Anhang versendet werden). Der Client stellt außerdem eine Oberfläche zum Ausfüllen des Stimmzettels zur Verfügung. Klickt der Benutzer auf "Stimme online abgeben", so geht der Client folgendermaßen vor:
- Es wird eine XML-Datei erzeugt, in welcher der Stimmzettel abgebildet wird.
- Die XML-Datei enthält zusätzlich zum "Stimmzettel" die Abstimmungs-ID sowie den Zufalls-String
- Die XML-Datei wird mit dem zum Token gehörenden PGP private Key signiert
- Die signierte XML-Datei wird an den Stimmen-Akkumulations-Server übertragen
Es wird empfohlen, die "Kryptographie-Arbeit" von GnuPG erledigen zu lassen; obwohl der Client selbstverständlich jede andere PGP-Implementierung (auch eine eigene) nutzen kann.
Stimmen-Akkumulations-Server
Während der Abstimmung geht der Stimmen-Akkumulations-Server wie folgt vor:
- Bei der erhaltenen XML-Datei wird die Signatur geprüft. Den dazu notwendigen PGP Public Key findet der Stimmen-Akkumulations-Server beim Token-Generator
- Es werden Zufalls-String und Abstimmungs-ID verglichen, ob sie
- zu einer gültigen Abstimmung gehören und
- der Zufalls-String in der Liste aller Codes auftaucht (und der dazu veröffentlichte PGP Public Key passt)
- Es wird geschaut, ob der Zufalls-String bereits in Liste der bereits abgestimmten Zufalls-Strings drin ist. Sollte das der Fall sein, so wird die bisherige Stimme überschrieben. Andernfalls wird ein neuer Eintrag beim Server erzeugt. Der Zufalls-String wird beim Stimmen-Akkumulations-Server sofort veröffentlicht (im Gegensatz zu LF sieht man bei diesem System bereits während der Abstimmungsphase die "Wahlbeteiligung").
Ist die Abstimmung vorbei, werden sämtliche Stimmzettel in Verbindung mit Zufalls-String und PGP Public Key veröffentlicht. Jeder kann sich davon überzeugen, dass seine Stimme sowie die der Anderen korrekt gezählt und nicht verändert wurde. Man sieht am Ende noch, welches Token wie abgestimmt hat; jedoch existiert nirgends eine Zuordnung von Abstimmungs-Token zu Benutzer; diese besteht nur für einen sehr kurzen Zeitraum während des Versands des Abstimmungs-Tokens.
Erweiterungen
Das Ganze System lässt sich auch auf andere Bereiche ausdehnen. Es wäre auch möglich, ganze Blöcke von Tokens zu generieren, damit man eben nicht 10 Emails bekommt, wenn 10 Themen zur Abstimmung stehen. Es ist auch eine Erweiterung denkbar, dass der Bundesvorstand bei Bedarf oder auf Antrag hin so einen "Token-Generierungs-Prozess" auslösen kann; je nach Bedarf, wofür man solche Einmal-Tokens verwenden möchte.