|
Einige Randbedingungen machen die Sache jedoch komplexer. Es sollen ja nicht Hinz und Kunz eine Lehrveranstaltung bewerten, sondern die Studenten, die daran teilgenommen haben. Also muß ein Autorisierungssystem hinzugefügt werden. Das hätten wir ja bereits, beispielsweise in Form von Username und Passwort für den Hochschul-Internetzugang oder auch mit den Praktikums-Accounts. Jedoch ist damit die Bewertung der Lehrveranstaltung nicht mehr anonym - und das sollte sie sein. Um einen Lösungsweg für dieses Problem zu finden, greifen wir auf einen Artikel von Lincoln D. Stein aus dem Perl-Journal zurück, der seinerseits auf einer Veröffentlichung von Kryptologie-Papst Bruce Schneier beruht. In diesem Artikel geht es um die Realisierung eines sicheren Internet-Wahlverfahrens:
Conventional paper ballots satisfy requirement 1 by voter registration, a
process that ensures that only American citizens of a certain age can vote.
Requirements 2 and 4 are satisfied by crossing the registered voter's name
off a list when the voter enters the polling location, and 3 is satisfied by
using an anonymous ballot. The last two requirements, however, are not completely
satisfied by paper ballots too.
Schneier's book describes several cryptographic protocols which meet
these six requirements for secure elections. Some of them are quite elaborate
and require new software at the voter's side of the connection. Here
we will use one of the simpler ones that happens to be well suited
for web-based voting.
This protocol requires two independent central facilities to work, called
the CEA and the CLA. The CEA is the Central Enumeration Agency. It is responsible
for collecting and tallying ballots, and publishing the results on election
night. The CLA is the Central Legitimization Agency. It is responsible for
registering and credentialing voters.
Dear Registered Voter, Attached is your voter registration number. PLEASE KEEP A COPY OF THIS E-MAIL; YOU WILL NEED IT IN ORDER TO VOTE. DO NOT BEND, FOLD OR SPINDLE. REGISTRATION-START-- 8334290304185989711211356 0784480602526249967749323 7190985476311629502773466 9927297350189474428770582 --REGISTRATION-END--
The privacy of the ballot is ensured by the separation of the CLA and the
CEA. One facility knows the identity of the voters, but not who they voted for.
The other has access to their vote, but not their identity.
This protocol discourages election fraud in a number of ways. If a registered
voter tries to vote twice, he will be caught in step 5. We can discourage non-registered
voters from trying to guess valid VRNs by using large random numbers (in this
example, we use 100-digit numbers).
If the CEA itself tries to cheat by stuffing the ballot box or "losing"
ballots, this can be detected in step 8. By publishing a list of CNs and their
votes, the protocol allows voters to check the list to make sure that their
votes were tallied correctly.
There are still ways to defraud this protocol. For example, the CEA and CLA can collude to figure out the identity of a voter; if voting is being done over the web, the CEA can use the voter's IP address to figure out who he is. The first of these problems can be addressed by election auditors and statutory law. The second can be addressed using proxy servers or by having the balloting take place in central polling places equipped with ATM-like web browsers. It is also important to note that the protocol described here is a slight departure from the one described by Schneier. The original protocol is built along an email model, in which the voter himself generates the CN, rather than letting the CEA do it for him...
Für das aktuelle Projekt wird auf die Bestätigung der Wahl an den Wähler verzichtet (wir wollen's ja nicht übertreiben) - also auf die letzten beiden der vorgenannten Punkte. Es geht darum,
Zur Lösung können die oben geschilderten Prinzipien angewendet werden.
• Erzeugung von Registrierungsnummern (RN)
• Abstimmung und Sammeln der Ergebnisse
• Anzeige der Ergebnisse
Es versteht sich von selbst, daß die Teile I und III nur von der jeweils berechtigten Person aufgerufen werden dürfen.
Ausserdem wird zusammen mit beliebig vielen RN auch eine eindeutige ID erzeugen, die dem Abrufen der Ergebnisse dient. In einer Datenbank werden die RN gespeichert, um später die Wahlberechtigung überprüfen zu können. Nach der Wahl verfällt der jeweilige Datensatz; jeder Studierende kann also nur einmal abstimmen.
Die Lehrpersonen-ID wird auf die gleiche Weise erzeugt, jedoch in einer zweiten Datei gespeichert. Auf diese Weise kann man sicherstellen, daß nur die berechtigte Lehrperson die Ergebnisse abrufen kann und nicht ein Kollege oder gar ein Student.
Als Interface dient ein Formular, das die Auswahl von Lehrperson und Fach sowie die Eingabe der gewünschten Anzahl der zu generierenden RN erlaubt. Das Skript zu diesem Formular gibt die Lehrpersonen-ID und entsprechende Anzahl von RN-"Schnipseln" als HTML-Antwort aus. Die kann dann entweder zur weiteren Verarbeitung abgespeichert oder ausgedruckt und zerschnitten werden.
Die folgenden Dateien bilden das Evaluationssystem:
Das Masterpasswort des Studiendekans wird von "tallylog.cgi", "tallyall.cgi" und "tallyadmin.cgi" abgefragt.
Bei der Akkreditierung für den Bachelorstudiengang Elektrotechnik und Informationstechnik sowie für den Masterstudiengang Electrical Engineering wurde eine anonymisierte Evaluierung explizit gefordert, zur Auswahl stehen das Ausfüllen der Papier-Fragebögen und Abgabe derselben bei der Studiendekanin (nicht bei der entsprechenden Lehrperson) oder ein elektronisches Verfahren wie dieses hier.
Die Programme wurden nach einem ersten Probelauf noch leicht modifiziert. Neben "kosmetischen" Änderungen wurde ein Problem in der Ausgabe behoben: Da manche Browser die als Histogramm-Balken zweckentfremdeten HTML-Tabellen nicht gedruckt haben, wenn die Option "Hintergrund auch drucken" im Browser abgeschaltet war, arbeitet die jetzige Produktions-Version mit einer Grafikausgabe. Eine schmale Grafik (GIF-Bild) wird jeweils passend "gedehnt".
Damit das System auch von anderen Fakultäten genutzt werden kann, wurde es recht bald entsprechend erweitert. Beim Generieren der Wahlzettel wird nun zuerst die Fakultäten ausgewählt. Diese Information sorgt dann für die Bereitstellung der passenden Dozenten- und Fächerlisten. Ebenso hat jede Fakultät und jeder Studiendekan ein eigenes Passwort.
Wegen des regen Zuspruchs wurde 2012 das ursprünglich zugrunde liegende Flatfile-System zur Datenspeicherung durch eine MySQL-Datenbank ersetzt. Die Datenbank besteht aus folgenden Tabellen:
CREATE TABLE `dozenten` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `fakultaet` int(11), `semester` varchar(10) NOT NULL DEFAULT '', `profid` varchar(20) NOT NULL DEFAULT '', `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '', `studiengruppe` varchar (20) NOT NULL DEFAULT '', `datum` timestamp, PRIMARY KEY (`id`) ) DEFAULT CHARSET=latin1;
CREATE TABLE `waehler` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `fakultaet` int(11), `semester` varchar(10) NOT NULL DEFAULT '', `key` varchar(20) NOT NULL DEFAULT '', `profid` varchar(20) NOT NULL DEFAULT '', `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '', `studiengruppe` varchar (20) NOT NULL DEFAULT '', `evaluiert` char(1) NOT NULL DEFAULT '0', `datum` timestamp, PRIMARY KEY (`id`) ) DEFAULT CHARSET=latin1;
CREATE TABLE `log` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `fakultaet` int(11), `semester` varchar(10) NOT NULL DEFAULT '', `lehrperson` varchar(30) NOT NULL DEFAULT '', `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '', `studiengruppe` varchar (20) NOT NULL DEFAULT '', `profid` varchar(20) NOT NULL DEFAULT '', `datum` timestamp, PRIMARY KEY (`id`) ) DEFAULT CHARSET=latin1;
CREATE TABLE `tally` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `fakultaet` int(11), `semester` varchar(10) NOT NULL DEFAULT '', `profid` varchar(20) NOT NULL DEFAULT '', `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '', `studiengruppe` varchar (20) NOT NULL DEFAULT '', `info` text NOT NULL DEFAULT '', `datum` timestamp, PRIMARY KEY (`id`) ) DEFAULT CHARSET=latin1;
CREATE TABLE `admin` ( `id` int(20) unsigned NOT NULL AUTO_INCREMENT, `fakultaet` varchar(10) NOT NULL, `evalpw` varchar(20) NOT NULL, `masterpw` varchar(20) NOT NULL, `Dozenten` text NOT NULL, `Faecher` text NOT NULL, `datum` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) DEFAULT CHARSET=latin1;
Weiterhin muss ein neuer User in der Datenbank eingetragen werden, der den Namen 'eva-user' trägt. Dies kann beispielsweise mittels eines SQL-Befehls erfolgen:
INSERT INTO `user` (`Host`, `User`, `Password`, `Select_priv`, `Insert_priv`, `Update_priv`, `Delete_priv`, `Create_priv`, `Drop_priv`, `Reload_priv`, `Shutdown_priv`, `Process_priv`, `File_priv`, `Grant_priv`, `References_priv`, `Index_priv`, `Alter_priv`, `Show_db_priv`, `Super_priv`, `Create_tmp_table_priv`, `Lock_tables_priv`, `Execute_priv`, `Repl_slave_priv`, `Repl_client_priv`, `Create_view_priv`, `Show_view_priv`, `Create_routine_priv`, `Alter_routine_priv`, `Create_user_priv`, `Event_priv`, `Trigger_priv`, `ssl_type`, `ssl_cipher`, `x509_issuer`, `x509_subject`, `max_questions`, `max_updates`, `max_connections`, `max_user_connections`) VALUES ('localhost', 'eva-user', '', 'Y', 'Y', 'Y', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', '', '', '', '', 0, 0, 0, 0); UPDATE `user` SET `Password`=PASSWORD('irgendeinpasswort'); FLUSH PRIVILEGES;
Der Username und das Passwort werden dann im Modul "Tallyman.pm" eingetragen. In diesem Perl-Modul sind auch alle gemeinsamen Daten und Funktionen für die Programme zusammengefaßt. Das betrifft auch die Definition des Fragebogens. Diese besteht aus drei Arrays, wobei das erste die Fragetexte enthält, z. B.:
our @DefA = ( "Konzept der Lehrveranstaltung", # 1 "Fachliches Niveau", # 2 "Vermittlung des Lehrstoffes durch den/die Hochschullehrer/in", # 3 "Hilfsmittel zur Lehrveranstaltung", # 4 ... );Das zweite Array ist ein "Array of Hashes", das für jede Frage alle Auswahlmöglichkeiten auflistet, und zwar die Codierung innerhalb der Datenbank. Normalerweise ist '1' die beste Antwort und '5' die schlechteste. Für "k. A." wird die Null verwendet. Bei Fragen mit nur drei Antwortmöglichkeiten werden '2', '3' und '4' verwendet. Ein 'A' kennzeichnet Fragen mit freier Antwort.
our @DefF = ( {'1' => 0, # ++ '2' => 0, # + '3' => 0, # o '4' => 0, # - '5' => 0, # -- '0' => 0}, # keine Antwort {'1' => 0, # viel zu hoch '2' => 0, # zu hoch '3' => 0, # angemessen '4' => 0, # zu niedrig '5' => 0, # viel zu niedrig '0' => 0}, # keine Antwort {'1' => 0, # ++ '2' => 0, # + '3' => 0, # o '4' => 0, # - '5' => 0, # -- '0' => 0}, # keine Antwort {'1' => 0, # ++ '2' => 0, # + '3' => 0, # o '4' => 0, # - '5' => 0, # -- '0' => 0}, # keine Antwort ... {'A' => ''}, # Kommentar {'A' => ''}, # Kommentar {'A' => ''}, # Kommentar );Das dritte Array ist genauso wie das vorhergehende aufgebaut. Auch hier gibt es für jede Frage einen Hash, nur dass diesmal die Texte der Untertitel im Fragebogen bzw. im Balkendiagramm der Auswertung zu den o. a. "Noten" angegeben werden:
our @DefFC = ( {'1' => '+ +', '2' => '+', '3' => 'o', '4' => '-', '5' => '- -', '0' => 'keine Antwort'}, {'1' => 'viel zu hoch', '2' => 'zu hoch', '3' => 'angemessen', '4' => 'zu niedrig', '5' => 'viel zu niedrig', '0' => 'keine Antwort'}, {'1' => '+ +', '2' => '+', '3' => 'o', '4' => '-', '5' => '- -', '0' => 'keine Antwort'}, {'1' => '+ +', '2' => '+', '3' => 'o', '4' => '-', '5' => '- -', '0' => 'keine Antwort'}, ... );Für die Fragen mit freier Antwort ist hier kein Arrayelement vorhanden, da diese Fragen am Schluss kommen.
Das komplette Programmpaket (Stand März 2013) kann HIER herunter geladen werden.