 Ja, ich freue mich jetzt vorstellen zu dürfen, es kommt jetzt Q-Bit, er studiert in Potsdam, was mit Software, wie er selber sagt. Im Chaos ist er halt viel als Fashion-Obs unterwegs und er sagt uns etwas über die Faltstricke der Anonymisierung und hat da ein spannendes Fallbeispiel und gerade in Zeiten wie diesen, wo viel über Anonymisierung und Pseudonymisierung gesagt wird, einen großen Applaus auf die Bühne bitte. Ja, herzlich willkommen zu Faltstricke der Anonymisierung. Ich bin der Q-Bit und baue mit ein paar Kommilitonen eine Evaluierungsplattform für Lehrveranstaltungen in Hochschulen. Das Projekt ist jetzt fast zehn Jahre alt, heißt EVP und ist seitdem gern zitiert beim Thema Projekt NamSkippen. Nein, also die Idee ist Studierende bewerten dort Lehrveranstaltungen, die sie in dem Semester an der Universität belegt haben. Das ist eine gute Sache, so sieht es aus, es gibt ein Fragebögen mit Ratings auf verschiedenen Skalen und so Freitextfeldern. Die Ergebnisse von diesen Ankreuzfragen können nach der Notenveröffentlichung alle sehen und die Dutzierenden erhalten zusätzlich die Textantworten als Übersicht. EVP ist dazu gedacht, die Lehre zu verbessern. So, das funktioniert nur, wenn auch viele Leute mitmachen und ernsthaft Feedback gegeben wird. Und da spielen wirklich viele Dinge mit rein und eines davon ist für die Studierenden, die ja irgendwie in der Kunst der Lehrenden stehen, besonders interessant. Und das sind meine Antworten da anonym. Also kann ich auf dieser Plattform Feedback geben, ohne das für andere zu sehen sein wird, dass ich dieses Feedback gegeben habe. Disclaimer, an dieser Stelle, anonyme Kommentare sind nicht unbedingt eine geeignete Methode für Feedback, aber das ist das, was wir uns jetzt hier anschauen. Und die Dutzierenden und wir haben damit auch gute Erfahrungen gemacht damit. Und unser Anspruch ist jetzt, ja, euer Feedback soll anonym sein. Wir wollen eine hohe Beteiligung und anonym ist nun mal gut dazu, die Hürde für Feedback nach unten zu setzen. Dass die Hürde gering ist, sodass viele Leute mitmachen. Und wir müssen das auch richtig machen mit der Anonymität, denn so ein Vertrauen in uns als Betreiber dieser Evaluationsplattform, das lässt sich schnell verspielen und wenn da einmal rauskommt, dass da irgendwie Dinge nicht anonym waren, dann hat man erstmal sein Vertrauen verspielt. Gut, wie machen wir das? Naja, die Plattform ist so gebaut, dass sie bei den Antworten nie die Autoren anzeigt. Ja, das ist jetzt so eine Ansicht, wie es für die Dutzierenden wäre, wenn sie die Auswertung bekommen. Da ist es einfach eine Liste aller Textkommentare ohne Autor. Und zusätzlich zeigen wir immer noch an, wer die Textantworten alles sehen kann. Sowohl den Leuten, die abstimmen, als auch den Leuten, die sich dann die Ergebnisse anschauen. So, und das ist doch super. Damit haben wir jetzt irgendwie Anonymität geschaffen. Die Autoren werden nicht angezeigt zu den Kommentaren und damit ist es ja irgendwie Anonymen. Oder? Naja, so, man hat ja so einen eigenen Schreibstil, da man so Kommentare verfasst. Und die können einen verraten. Man baut ja auch über das Semester irgendwie eine Beziehung zu den Dutzierenden auf, die lernen einen ein bisschen kennen und die lernen ja auch die eigene Meinung kennen. Und so kann man vielleicht über das, was man da schreibt, seine Identität preisgeben. Und das müssen die Leute wissen, wenn sie irgendwie ihren Evaluationsbogen online ausfüllen. Und das ist auch besonders bei kleinen Seminaren kritisch, denn da gibt es ja nur wenig Leute. Aber auch bei denen wollen wir ja Feedback sammeln. Was machen wir da? Naja, wir wollen ja das irgendwie nicht verfälschen, irgendwie Zusatzrauschen da reinpacken oder so. Stattdessen zeigen wir den Leuten eine Warnung an Achtung. Hier in dieser Veranstaltung gibt es eine geringe Anzahl an Teilenden. Seid ihr dessen bewusst, formuliere deinen Text vielleicht so. Und zusätzlich haben die Leute die Möglichkeit, dass wenn sie die einzigen wären, die Antworten gegeben haben, dass dann ihre Kommentare nicht veröffentlicht werden. Und so soll es ihm möglich sein, zumindest dieses Problem ein bisschen zu reduzieren oder zu akzeptieren. Also jetzt sind wir glücklich, wir haben uns irgendwie angeschaut, damit haben wir irgendwie Anonymität hergestellt, oder? Naja, das jetzt ein Punkt, da könnte man aufhören, sich die Sache anzuschauen. Was wir erreicht haben, ist ja irgendwie organisatorische Anonymität. Also das Tool zeigt die Antworten nicht an und das haben wir jetzt so organisiert, dass Anonymität herrscht. Das hat uns aber nicht unbedingt gereicht. Wir waren auch ein bisschen neugierig und wir wollten technische Anonymität. Wir wollten also, dass es gar nicht möglich ist, irgendwie zu den Textantworten die Autoren zuzuordnen. Für welches Szenario ist das irgendwie interessant? Naja, enter the hacker stellt man sich vor, dass unsere Seite angegriffen wird. Also jemand bekommt Zugriff nicht nur auf die Seite, wie die Duzierenden, sondern auch auf den Server, auf die Datenbank, auf den Backup, auf den Export. Und auch dann wollen wir, dass Anonymität herrscht. Das heißt, das Szenario, was für uns jetzt anschauen ist, dass ein Angreifer jetzt einen Datenbankdamm oder Zugriff auf die Datenbank oder den Server erhält. Sobald dieser Angriff auf den Server erfolgt ist, kann der Angreifer natürlich irgendwie die Anwendung austauschen und dann immer mitschreiben, wer welchen Kommentar abgegeben hat. Aber für alle Daten, die wir bis dahin gesammelt haben, für die sollen natürlich weiterhin Anonymität gelten. Zum Umgang mit Daten hat Matszek Ceglowski in seinem Talk Haunted by Data einen Vergleich angestellt. Er hat dort Daten mit radioaktiven Abfall verglichen und daraus drei einfache Tipps schon abgeleitet. Und zwar über Daten, don't collect it, if you have to collect it, don't store it, and if you have to store it, don't keep it. Also schauen wir jetzt mal rein, wie wir das bei uns umsetzen. Ein einfaches Beispiel für das don't collect it, da habe ich hier. Früher haben wir Kerberos für unser Einloggen benutzt. Ja, die Nutzer haben in einem Nutzernahme- und Passwortfeld ihre Log-in-Daten der Universität eingegeben. Wir haben das dann mit dem Identitätsmanagement-Server der Uni abgeklärt. Und der hat dann gesagt, ja, der Nutzer darf sich einloggen oder eben nicht. Und dabei liefen die Passwörter auch über unseren Server. Mittlerweile nutzen wir einen OpenID-Provider. Da gibt es jetzt kein Passwortfeld mehr, sondern nur noch ein Knopf, wo man drauf drückt, um sich einzuloggen. Man wird zum OpenID-Provider geleitet, der kümmert sich um dieses ganze Passwortgeschubse und sagt uns am Ende nur, der Nutzer hat sich eingeloggt als der und der oder die Nutzerin gibt es nicht. So, wir kriegen jetzt keine Passwörter mehr auf dem Server und wir haben quasi dieses don't collect it erfüllt. Wir können die Daten auch nicht mehr verlieren. Jetzt haben wir aber diese Evaluationsdaten. Wir müssen diese sammeln und speichern, weil das ist ja Sinn unserer Anwendung. Wir wollen sie auch später anzeigen. Aber wir können dabei auswählen, welche Daten genau wir speichern. Und hier haben wir ein ganz klassisches Problem mit der Nutzeridentität. Die Nutzer müssen sich authentifizieren und dann werden sie autorisiert, genau einmal abzustimmen. Keiner soll mehrmals Kommentare abgeben können und so irgendwie das Ergebnis beeinflussen. Aber jeder soll das Recht dazu haben, jeder, der in der Veranstaltung teilgenommen hat. Aber nachdem die Nutzer autorisiert wurden, hier ihre Feedback zu geben, ab dann sollen sie anonym sein. Und alle Daten, die sie angeben, sollen ohne Bezug zum Outdoor sein. Und die klassische Lösung, die wir in der Welt zum Beispiel dafür haben, ist eine Wahlurne. Weil eine Wahl ist ja irgendwie genau das und da leistet eine Wahl ohne genau das, was wir wollen. Auf einer Liste wird abgestrichen, wer zur Wahlurne herantreten darf und diese gruppiert dann die Antworten, die kommen alle in einen Haufen und so sind sie die identifiziert und damit ist es irgendwie nachvollziehbar anonymisierend. Wir wollen jetzt also unsere Anwendung so bauen, dass sie die Autorisierung sicherstellt, aber dann die entsprechenden Daten anonym sind. So, das ganze Projekt ist ein Django-Projekt mit dem Django-Webframework geschrieben und da haben wir so Models, wie hier dargestellt, ganz oben die Evaluierung. Das ist ein Modell, da gibt es eine Liste an Teilnehmern und dann eine Liste an Voters, also an Leuten, die schon abgestimmt haben. Darunter haben wir zwei Ergebnisobjekte, einmal ein Rating-Answercounter, also ein Zähler, der zählt, wie oft welche Option bei einer Frage gewählt wurde und ganz unten so ein Text-Answerobjekt. Und das ist hier sehr ähnlich zu ohne, denn nur bei der Evaluierung haben wir irgendwie eine Liste an Nutzern und die Antwortobjekte unten sind ohne Referenz zu irgendwelchen Leuten, von denen zum Beispiel die Textantwort kommt. Und das sieht gut aus, da können wir erst mal glücklich sein, weil wir haben ja jetzt nicht gespeichert, wer hier so eine Textantwort gegeben hat und das haut er erst mal gut hin. Oder? Naja, wir müssen ein bisschen tiefer graben. Wir nutzen Django als Web Framework und das führt jedem Objekt noch automatisch eine ID hinzu, die in der Datenbank als Primärschüssel genutzt wird. Das ist auch gut und wichtig, denn mit dieser Primärschüssel, mit dieser ID, werden diese ganzen Beziehungen zwischen den Objekten überhaupt erst realisiert. Das Problem ist, dass diese IDs immer automatisch eins weiterzählen. Also die erste Textantwort zum Beispiel bekommt ID 0, die zweite bekommt ID 1, die dritte bekommt ID 2 und so weiter. Das heißt eigentlich sehen unsere Modelldefinitionen so aus. Jedes Objekt hat so eine ID, das ist ein Autofield, also diese hochzählende ID. Und das Problem ist jetzt, dass wir zum Beispiel Textantworten zusammengruppieren können. Denn diese haben aufeinander folgende IDs, da sie gemeinsam abgegeben wurden. Wenn ein Nutzer seinen Fragebogen abschickt, dann sind da meinetwegen fünf Textantworten drin. Die kriegen dann zum Beispiel die IDs 23 bis 27, weil die alle zusammen reinkommen und der Zähler ja hochzählt. Und wenn sich dieser Nutzer jetzt durch seinen Schreibstil in der ersten Antwort und in der letzten identifiziert, dann kann ein jemand, der die Datenbank hat, auch sehen, dass alle Antworten dazwischen von diesem Nutzer stammen müssen. Aber besonders kritisch ist, man muss nicht mal unbedingt Zugriff auf die Datenbank haben. Denn wenn man sich dann nicht weiter dumm kümmert, wird auf unserer Seite, wenn die Kommentare in der Reihenfolge, wie sie diese IDs haben, angezeigt. Das heißt, auch ein Duzierender, der hier mehrere Antworten identifiziert, kann wissen, von wem die Antworten, die dazwischen gelistet sind, stammen. Das ist jetzt schlecht, weil das wollen wir ja nicht. Wir wollen ja nicht, dass die Antworten, außer die, die sich wirklich selbst identifizieren, deanonymisiert werden. Aber wenigstens sind ja nur die Textantworten betroffen. Diese Rating-Antworten mit den Zählern, die sind ja schon gruppiert. Richtig? Naja, auch bei diesen Rating-Antworten kann man Personen zuordnen. Es ist nur etwas puzziger, etwas schwieriger. Dazu schauen wir uns dieses Evaluation-Model nochmal an. Das heißt, dieses ID fehlt. Die Liste an Teilnehmern und die Liste an Abstimmenden. Und diese Liste an Abstimmenden ist ein Many-to-Many-Field. Das wird immer realisiert durch eine eigene Tabelle. Das kann man sich so vorstellen wie eine Liste an Evaluationsteilnahmen. Und auch die bekommen ja eine ID. Das heißt, wir können hier wieder aus den IDs ablesen, in welcher Reihenfolge die Leute den Fragebogen ausgefüllt und abgeschickt haben. Und wir wissen somit auch, wer der erste Voter war. Hier hat zum Beispiel Laura die geringste ID, die 42 und dann kommt Linus mit der 43 und so weiter. Das ist das erste Pultestück. Und das zweite ist, dass diese Rating-Antworten nur bei Bedarf erstellt werden. Also wenn eine Option noch nie gewählt wurde, dann hat sie auch keinen Zähler. Aber auch die haben IDs. Und auch da lässt sich erkennen, in welcher Reihenfolge die Counter angelegt wurden. Es könnte zum Beispiel so aussehen, der Counter für die Antwort Option 4. Wenn wir jetzt nach Schulnoten gehen, hat hier ID 101. Und die anderen beiden haben eine höhere ID, sind also später erstellt worden. Jetzt wissen wir, dass Laura zuerst abgestimmt hat und die Rating-Option 4 zuerst gewählt wurde. Und damit wissen wir, dass Laura die 4 gewählt hat. Und auch hier haben wir wieder diese Antwort, die ja nur aus einem ankreuzen Bestand auf einmal eine Person zuordnen können. Auch wenn wir nun ein Zähler haben. Und es ist schlecht. Wir können quasi alle Antworten, die der erste Nutzer gegeben hat, rekonstruieren. Und mit ein bisschen Trickserei kann man das auch für die Nutzer machen, die danach kommen. Es wird dann immer ein bisschen unsicherer, aber es geht auf jeden Fall für mehrere Personen. Zum Beispiel vielleicht auch irgendwie für die letzte Person. Und das alles nur, weil wir diese Auto-Increment-IDs in den Objekten haben, wie es uns ermöglichen, die Reihenfolge der Objekte nachzuvollziehen. Also was können wir dagegen tun? Naja, UUIDs to the Rescue. Was ist das? Ja, das sind Universal Unique Identifiers, also eine Art standardisierte ID. Und die lösen unser Problem. Oder? Naja, so eine UUID-Version 1 basiert erstmal auf einem Zeitstempel zu einem gewissen Anteil und liegt damit ja wieder in die Einführungsreihenfolge. Wir brauchen zufällige UUIDs. Und es gibt es auch, das heißt dann Version 4. Reicht das? Naja, wenn wir so Zufallszahlen haben, dann kann man da vielleicht auch nachvollziehen, in welche Reihenfolge die erstellt wurden. Wir brauchen kryptografisch sicheren Zufall, wo man dann im Nachhinein nicht sagen kann, in welcher Reihenfolge der Zufall da generiert wurde. Auch dafür gibt es eine Funktion und wir basteln uns das dann hier zusammen und sagen hier, eine UUID Version 4 mit diesen 16 zufälligen Bytes. Diese Funktionen nehmen wir und setzen sie in unsere drei Models ein als ID. Dann gibt es diese Auto-Increment-ID nicht mehr, sondern stattdessen diese UUIDs. Und jetzt können wir aus den IDs nicht mehr die Reihenfolge nachvollziehen. Super, jetzt sind wir doch glücklich. Oder? Naja, wir graben mal ein bisschen tiefer. Diese ganzen Objekte landen ja irgendwann in einer Datenbank. Dafür nutzen wir Postgres. Und Postgres trollt uns ein bisschen. Warum trollt uns Postgres? Naja, schauen wir mal rein. Wir haben hier ein Codeschnipsel, da stellen wir eine Tabelle Test mit zwei Feldern, ID um Text und fügen da drei verschiedene Datensätze ein. Immer mit so einer zufallsgenerierten UUID und in Texten FUBAR und EVP. Und jetzt können wir so einen Select machen auf diese Tabelle und siehe da, die Daten werden uns genau in der Einfolge-Reihenfolge, Reihenfüge-Reihenfolge wieder ausgegeben, ohne dass wir irgendwie da eine bestimmte Sortierung fordern. So, das jetzt ein Problem. Wir müssen es irgendwie verhindern, dass die uns per default so ausgegeben werden, wie sie eingefügt wurden. Was können wir dagegen tun? Naja, wir sortieren die Tuple auf Disk um, da gibt es auch ein Befehl, wenn man in die Dokumentation schaut, findet man das Cluster-Komand. Und das macht genau das. Es reordert die Tuples on Disk. Also erstellen wir den Index, an dem man clustern kann, das ist einfach die ID und clustern dann nach dieser ID. Und es funktioniert. Wir haben jetzt hier geclustert, machen wieder dieses Select-Statement und siehe da, jetzt sind die Tuple per Standard erst mal nach dieser ID alphabetisch sortiert. Und damit sind wir doch jetzt glücklich. Oder jetzt können wir auch aus der Datenbank nicht mehr die Reihenfolge, in der die Einträge eingefügt wurden, nachvollziehen. Oder? Postgres trollt uns wieder. Es gibt nämlich zusätzlich zu den Spalten, die wir erstellen, auch ein paar Systemspalten. Und eine davon ist die Xmin-Spalten. Aus technischen Gründen braucht man die zum Beispiel zur Isolation einzelner Datenbank Transaktionen. Und dabei wird für jedes Tuple, also für jede Zeile in der Tabelle die Transaktions-ID der Transaktion gespeichert, die dieses Tuple einfügt. Also immer wenn man eine neue Zeile schreibt oder eine Zeile ändert, da wird nämlich einfach nur eine neue Version angelegt und das alte Tuple als alt markiert, kommt da eine Transaktions-ID ran. Und das Besondere ist die ist aufsteigend. Vorhin in unseren Django-Models haben wir hier wieder aufsteigende IDs an unseren Objekten dran. Da ist vielleicht mal eine Ziffer übersprungen, weil andere Transaktionen in der Datenbank stattfinden. Aber das ist ja nicht schlimm. Wir können es immer noch in eine Reihenfolge bringen. So. Das kann man sich auch mit anzeigen lassen. Dazu muss man neben dem Stern einfach noch sagen, zeigt mir das Xmin. Und dann können wir danach auch sortieren. Das braucht diesen Cast. Aber mit diesem Cast seht ihr, dass wir die Verlusterung unsere Texte wieder in der Einfügel-Reihenfolge anzeigen können. FU, A und EVP. Und das ist schlecht. Jetzt haben wir wieder die Datenbank und haben wieder eine Reihenfolge, obwohl wir das ja geklastert haben und in der Anwendung eigentlich gar kein Verweis mehr auf die Reihenfolge haben. Was können wir dagegen tun? Nächster Heck. Unsere kritischen Tabellen, also zum Beispiel die mit den Text Antworten, kriegen jetzt eine Extraspalte. Und dann wir einfach nur, um die Einfügel-Reihenfolge so zurückzusetzen. Also da wird dann überall das Xmin auf den gleichen Wert gesetzt. Ich habe hier wieder ein Coach-Lipsel. Wir fügen der Tabelle Test. Jetzt diese Spalte Toggle hinzu. Das ist einfach ein Boolean, den wir an- und ausmachen können. Und ich füge jetzt hier nochmal eine Zeile mit dem Text Hans hinzu. Der taucht jetzt, wenn wir selektieren und nach Transaktions-ID sortieren, ganz unfen auf. Jetzt gehen wir aber mal los und machen das in allen Zeilen auf True. Und jetzt klustern wir die Relation neu nach unserem Index wieder, sodass das wieder alles nach der UV-ID sortiert ist. Und dann machen wir wieder einen Select. Und siehe da, die Xmin-ID rechts ist jetzt überall gleich von diesem Toggle auf True setzen. Und die Tubel sind wieder nach der ID sortiert. Super. Jetzt verrät die Transaktions-ID erst mal nicht mehr die Reihenfolge. Naja, halt Stopp Achtung. Wir dürfen die toten Tubel nicht vergessen, die es ja auch noch irgendwo im Speicher gibt. Wie viel es davon gibt, kann man sich anzeigen lassen. Ich habe hier mal die Abfrage dafür mitgebracht. Ihr seht da, die Live-Tubels sind vier Stück, die vier, die wir gerade gesehen haben. Und die vier alten Tubel, bevor wir dieses Toggle auf True gesetzt haben, gibt es auch noch. Die wollen wir loswerden, weil die geben ja noch die Reihenfolgepreis. Was macht man da? Da gibt es auch ein Befehl für Wacquem. Da gibt es auch die Wacquem, die entfernt unter anderem eben auch diese toten Tubel. Das machen wir und schauen dann wieder rein und sie hat da tatsächlich keine toten Tubel mehr. So, jetzt haben wir es aber wirklich geschafft. Oder jetzt können wir uns sicher sein, dass man die Reihenfolge nicht mehr nachvollziehen kann aus unseren Daten. Oder? Naja, es gibt eigentlich auch so viel mehr Dinge, die man sich hier anschauen kann. Z.B. die Web-Server-Access-Logs, in denen irgendwie IPs verzeichnet werden, die Reihenfolge, in der auf den Web-Server zugegriffen wurde. Oder auch die Datenbank-Logs. Postgres macht einen Write-Ahead-Log, einfach, um ausfallsicher zu sein. Aber auch in diesem Log finden sich die Werte noch mal wieder in einer gewissen Reihenfolge. Dann die ganzen Backups, die wir von unserer Datenbank machen. Vielleicht auch bevor wir irgendwie geklastert haben. Aber auch der Vergleich von Backups auf zwei aufeinander folgenden Tagen hat was verraten. Wenn z.B. von einem auf den anderen Tag Antworten hinzukommen, dann wissen wir irgendwas über die Reihenfolge der Textantworten. Diese ganzen Dokumente muss man dann irgendwie auch löschen, weil die verraten ja was. Aber was ist denn löschen überhaupt? In vielen Speichermedien bedeutet die löschen einfach, dass man Speicherplatz als unbenutzt markiert. Dass der also überschrieben werden kann für andere Fälle. Das heißt aber nicht, das ist also schwierig. Aber ich möchte jetzt nochmal darauf eingehen, warum wir uns das angeschaut haben. Diese ganzen Maßnahmen dienen irgendwie der Datenspaßamkeit. Und wir wollen Datenspaßamkeit, weil falls ein Angreifer an unsere Daten kommt, unsere Nutzer geschützt sein sollen. Also in dem Fall soll eben nicht zuordnen, wer hier diesen kritischen Kommentar geschrieben hat. Aber wir wollen es unseren Nutzern auch einfacher machen, uns ihre Daten an zu vertrauen, uns ihre Meinung, uns ihre Kritik, die sie an den Lehrveranstaltungen oder was auch immer haben. Denn wir könnten ja auch irgendwann bösartige Intentionen haben. Oder die Leute, die sich nach uns um die Evaluierungsplattform kümmern. Oder wir können doch einfach ein Fehler machen. Wir können doch einfach das falsch machen. Irgendwas falsch konfigurieren, irgendeine E-Mail an den falschen Enfänger schicken. Davon sind wir ja auch nicht frei. Aber wir wollen den Nutzern einfach verabschieden, wie es geht, zu vertrauen. Denn letztendlich vertrauen sie uns auch, dass wir die Software so betreiben, wie wir sie auf GitHub veröffentlichen. Das garantieren wir mit keinem technischen Mittel. Wir erwarten einfach, dass sie uns das glauben. Nicht zuletzt wird bei uns der Server auch durch Studierende betreut, die ja auch Abstimmung machen und damit die gleichen Interessen wie die Nutzer als ganzer haben. Sicherlich gibt es auch irgendwie Verfahren, das zu validieren, was da läuft, oder irgendwie Zettifizierung, aber das haben wir nicht. Und wenn man das ein bisschen weiter treibt, dann vertrauen wir als Betreiber ja auch nur darauf, dass die Frameworks und die Programmiersprachen und die Betriebssysteme und die Hardware, die wir nutzen, auch nichts Verwunderliches mit dem Datenanstellt, die wir mit ihnen verarbeiten. Ein interessantes Beispiel dazu, wir sagen jetzt mal, wir vertrauen dem Distributionsweg nicht. Also wir kennen die Sources und die Projekte und wir vertrauen den auch. Wir wissen, das ist irgendwie Open Source, da haben viele Leute drauf geschaut, das setzen viele ein. Aber wenn ich hier Appget-Install mache oder was auch immer, dann vertraue ich nicht dem, was da rauskommt, was da ankommt. Und was macht man in vielleicht genau diesen speziellen Fall ja, richtig selbst kumpilieren. Und warum dieser Ansatz vielleicht ein bisschen zu naiv ist für so ein Problem, für den 80 hat Ken Thompson dazu sich Gedanken gemacht und bei einer Turing Award Lecture quasi ein Heck beschrieben. Das Ganze heißt Reflections und Trusting Trust. Das Paper findet man im Internet. Es sind drei sehr interessante Seiten, auf jeden Fall lesenswert und wir schauen uns jetzt mal die ganz grobe Idee davon an. Also wir haben hier unsere App und wir wissen nicht so richtig, ob die in Ordnung ist. So wir wissen aber, dass wir jetzt los und kumpilieren unsere App. Und jetzt können wir auf die Source einfach das Binary erzeugen und sind damit erstmal zufrieden. Aber halt, wir haben das ja mit einem anderen Tool gemacht und zwar irgendwie mit dem C-Compiler zum Beispiel. Und wir haben ja gesagt, wir vertrauen der Distribution nicht so. Wir haben den C-Compiler ja auch nur irgendwo herbekommen. Also es ist nicht unbedingt vertrauenswürdig und es ist heimlich eine Schwachstelle einschmuggelt. Dass es irgendwie in der Binary von dem C-Compiler versteckt, das können wir gar nicht erkennen. Gut, was machen wir gleicher Ansatz? Wir holen uns die Source für den C-Compiler und bauen das dann auch. Aber womit haben wir jetzt den C-Compiler gebaut? Naja, auch mit dem C-Compiler. Aber dem vertrauen wir nicht und damit haben wir jetzt so ein bisschen ein Henne- und Ei-Problem beschrieben, schaut euch das gerne an. So, aber hier sind wir jetzt irgendwie auf den Problem gestoßen, wo wir dann einfach vertrauen haben müssen. Und ich höre jetzt hier mal auf, weil jetzt sind wir gleich bei einer Verschwörungstheorie. Ich möchte aber nochmal kurz zusammenfassen, was wir alles gesehen haben. Zuerst Anonymität ist schwierig als Afterthought. Wir haben erst unsere Anwendung gehabt, die wir haben wollen. Und es gab viel zu finden dabei. In der Informatik gibt es so viel Abstraktion zu durchschauen. Da muss man von Anfang an wie klare Ziele haben, was Anonymität und Datensparsamkeit angeht und die von Anfang an mit umsetzen. Weil sonst landet man in so einer Situation, wo wir jetzt sind, wo wir feststellen, wir haben irgendwie verschiedene Stellen, da haut es nicht ganz hin mit der Datensparsamkeit und der Anonymität. Als Zweites, am Ende bin ich und sind auf jeden Fall sehr zuverlässig, wenn man es richtig macht. Aber sie decken irgendwie nicht immer alles ab. Irgendwie müssen die Nutzer auch den Anbietern vertrauen. Zum Beispiel, dass sie die Software so betreiben, wie angekündigt. Oder wie beworben vielleicht auch. Und die Anbieter selbst vertrauen ja auch nur auf die genutzten Frameworks, Tools, Services, auf die günstige Hardware oder auf irgendwie vertraglich gebundene Partner in der Datenverarbeitung. Es gibt Dinge, die können da helfen, es sind irgendwie Gesetze, das ist Dezentralität, weil irgendwie die Angespräche größer und unüberschaubarer wird. Und es sind auch Freundschaften zwischen Leuten, also zum Beispiel kenne ich Leute, die betreiben Infrastruktur und ich nutze die halt gern, aber ich den Leuten vertraue. Und zu guter Letzt, Wahlohren sind eine gute Sache. Und was meine ich damit? Naja, Verfahren, die überschaubar sind und bei Design wenig Datensammeln. Den kann man viel einfacher vertrauen. Ja, und damit vielen Dank fürs Zuhören und danke an die Leute, die uns immer helfen, unsere Evaluierungsplattform mitzuentwickeln und alle, und all die, die so fleißig mitkommentieren. Euch viel Spaß beim Deewog noch. Ich bin unmuted. Ja, dann erstmal herzlichen Dank für den Vortrag und gehen wir in medias.rex in die Fragen. Warum werden die Nutzernamen überhaupt gespeichert und nicht nur ein Hash dieser? Dann wären die IDs auch nicht so kritisch. Wir haben uns, wir haben darüber nachgedacht, wie wir das unabhängiger von den Nutzernamen machen können und ein Hash war damit im Gespräch. Unter anderem auch ein Hash mit dem Passwort zusammen, um den Nutzern die Möglichkeit zu geben, im Nachhinein noch ihre Antworten zu ändern. Ohne dass wir speichern, müssen wem die Antworten zugeordnet werden. Das sind aber Gedanken, die wir später haben, nachdem die Plattform erstmal so entwickelt wurde, wie ich sie jetzt hier gezeigt habe. Das ist auf jeden Fall ein guter Gedanke. Wir haben immer nachgedacht, aber wir haben nur nicht angefangen, das irgendwie umzubauen. Aber das ist eine gute Idee. Dann die nächste Frage. Das bei jedem hinzufügen von Daten, der Wert einer Spalte, Toggle, alle Zeilen gleichzeitig verändert wird, klingt nicht so, als würde es gut skalieren. Die Probleme gibt es von der Performance bei unserer Größe noch nicht. Also wir sind irgendwie 600 Leute, die mit evaluieren, also 600 Studierende. Aber ich kenne durchaus Leute, die sagen, wir bauen Anwendungen mit Postgres und wenn wir Vacuum machen, also es geht nicht. Wir können nicht, auch nicht mal für fünf Minuten nach zum Vier, unsere Daten beim Abschalten. Wir hatten damit noch keine Probleme, aber ich kann das auf jeden Fall nachvollziehen, der Fall wäre. Wenn, dann muss man sich ein anderes Setup überlegen. Also irgendwie Copy und Write, Datenbanken, Vier, Instanzen und Mirrors und so weiter. Da kann man auf jeden Fall ein bisschen zufistikated werden. Dann, wenn man diesen Feedback-Service bei sichern der Uni verwenden will, welche Zusatz-Services braucht man jetzt insgesamt? Das ist eine Open-Source-Software. Ihr könnt die, das ist eine Django App, die man mit dem Server betrieben. Man muss sicherlich irgendwie eine Authentifizierung da einbauen. Also wir haben jetzt so OpenID-Provider und das ist bei uns so ein bisschen auf die Datenflüsse mit dem Studienreferat abgestimmt, Teilnehmerlisten und so weiter, wie die importiert werden. Aber man kann das sicherlich auch für seine eigene Zwecke anpassen. In der Zwischenzeit ist ja hier auch ein Link sogar eingefügt werden, wo man noch weitere Informationen findet. Mit was für einem Tool hast du die Folien erstellt. Reveales. Sie sehen echt toll aus. Danke. Die Folien sind von einem Kollegen aus dem Projekt, der das mal, der den Talk in kurzerer Form mal an der Uni gehalten hat. Wir haben das da mit Google-Präsentationen gebaut. Shame on me. Aber das ist halt historisch gewachsen, so wie so Folien. Steel with Bright. Die nächste Frage. Wenn man immer misstrauischer wird und nicht mal ein Compiler traut, könnte man auch gleich seinen eigenen Server basteln. Wie weit soll man am besten gehen? Zwecks Misstrauen. Wann ist Misstrauen gesund und wann nicht mehr? Oh, das ist eine ganz schwierige und individuelle Frage. Also dieses Paraneuer-Level ist ja so beim TCC gefühlt generell ein bisschen höher. Ich glaube, das muss sich die sehr erläuternvertraut oder Diensten oder Anbietern. Das kann ich nicht im Allgemeinen beantworten. Aber ich denke, eine gewisse Grundskepsis ist ganz gut. Das führt eben dazu, dass Services vielleicht dezentralisiert betrieben werden, dass man sich selber mal in den Kopf macht, selber in den Next Cloud aufsetzt, anstatt bei Dropbox die eigenen Daten zu haben, zum Beispiel. So, dann wird die Software an deiner Uni schon verwendet? Wenn ja, gibt es schon praktische Erfahrungen damit? Die Software ist seit 2011 im Einsatz. Also fast zehn Jahre jetzt. Wir haben sehr gute Erfahrungen damit gemacht. Allein dadurch, dass sich die Studierenden selbst in die Weiterentwicklung kümmern, sind die Features eigentlich immer so, wie sie gerade brauchen. Also 60 Prozent der Teilnehmer schicken dann auch eine Evaluierung ab. Also wir haben wirklich gute überdurchschnittliche Erfahrungen damit gemacht. Aber das hängt auch wirklich mit einer Kultur, was Evaluierung angeht, an der Uni zu sein. Wir sind jetzt ein Informatik-Gebiet. Da sind die Leute halt gut, darin Feedback und Kritik und Fehler zu akzeptieren. Das ist ja als an klassischeren Studiengängen meine Vermutung. Dann die nächste Frage im Rückblick. Welche Designentscheidungen würdet ihr jetzt anders machen, um Anonymität besser slash leichter ins Software umzusetzen? Was wir jetzt anders machen? Ich glaube, irgendwo sagt man auch, es sind nur Evaluierungsergebnisse, die sind nicht so kritisch wie politischen Bahl zum Beispiel. Und das ist jetzt ein Ausgleich zwischen wie praktikabel ist das Ganze zu programmieren und wie anonym ist das. Und ich finde, obwohl wir ja diese Schwächen haben, haben wir da trotzdem noch einen zufriedenstellenden Punkt gefunden auf dieser Skala. Aber wenn man da was Krasses braucht, dann wie gesagt, von Anfang an überlegen, welche Technologien ermöglichen mehr Anonymität. Ich bin da auch noch sehr am Anfang. Und wir sind da auch noch immer noch am Diskutieren. Nächste Frage. Was ist mit anderen Systemspalten in der Datenbank? Wie beispielsweise CTID? Ich weiß nicht, was die CTID macht. Schreib uns gerne ein Issue ins GitHub. Wir sind da auf jeden Fall interessiert. Ich hatte gestern nochmal in das Datenbank Write a Headlock von denen, die ich da per Insert in die Datenbank gepackt habe. Also mit technischem Know-how und mal her damit. Wir finden das auf jeden Fall spannend, auch wenn es sich unbedingt in Erinnerung an unserem System resultiert. So, die nächste Frage über springe ich kurz. Komm aber gleich nochmal drauf zurück. Verrückte Mathematiksysteme, die für Onlinewahlen vorgeschlagen werden, mal angeschaut, um das ohne Server Trust zu realisieren? Also die Frage ist jetzt, ob ich dieses Thema angeschaut habe, die ohne Server Trust eine Wahl umsetzen wollen. Mit verrückter Mathematik oder dunkler? Mit verrückter Mathematik. Nein, stecke ich nicht tief drin. Onlinewahlen, digitale Wahlen ist aber auf jeden Fall ein Thema auch bei uns in der Uni und bei uns in der Nähe in Potsdam. Wir beobachten das auf jeden Fall als Chaos-Treff ganz eng. Ja, aber kenne ich mich mit den technischen Details nicht so aus. Nächste Frage. Kann ich nicht einfach jedem Benutzer meines Systems ein einmalig verwendbaren Token ausstellen? Jeder Student bekommt genau ein, keiner weiß, wer welchen hat. Das kann man machen. Ja, es ist wieder so ein Punkt in dem wir einfach einen Export an allen Belegungsdaten importieren, das und es funktioniert. Jeder kann genau seine Veranstaltungen evaluieren. Die Leute kriegen E-Mail-Reminder, zwei Tage vorher, die Nacht vor Evaluierungsschluss. Wir müssen nichts in der Vorlesung austeilen. Deduzierenden müssen sie nicht weiter groß zum Kümmern außer, dass sie am Anfang einmal sagen, ich will die und die und die Frage bürgen. Nächste Frage. Wäre eure Abstimmungsplattform theoretisch geeignet nach allen Anonymisierungsversuchen um Wahlen slash Volksabstimmungen durchzuführen? Nein. Ich denke, du lachst auch schon. Ich denke, digitale Wahlen sind in sehr, sehr vielen Formen eine ganz, ganz schlechte Idee. Weil die Wahl ohne, das so gut macht, nachvollziehbar zu sein. Da gibt es nichts mit drei Stufen, drei Abstaktionstiefen weiter unten und da plötzlich kannst du wieder nachvollziehen, wer welchen Wahlzettel geschrieben hat. Sondern bei einer Wahlurne versteht jeder, wie die Anonymisierung funktioniert und es kann trotzdem jeder nachvollziehen, dass jeder nur einmal abstimmen durfte. Und diese Nachvollziehbarkeit, auch für Nicht-Techies, ist ein Respekt für Wahlen. Plus eins. Nächste Frage. Ist gute Sicherheit nicht ein Mix zwischen Usability und Sicherheit? Gute Sicherheit heißt, dass es mehr Auswand ist, den Dienst zu knacken, als die Daten anders zu bekommen. Und Sicherheit oder Anonymität ist zudem nichts Absolutes, sondern etwas Relatives. Glaubst du nicht, dass viele zu viel Aufwand betreiben? Irgendwo muss man ja genau diesen Punkt an, dieses Spektrum von Usability und absoluter Sicherheit. Wir ziehen ja auch irgendwo den Punkt. Wir sagen ja auch irgendwo, wir gucken uns das weiter an, weil wir es interessant finden, aber wir wollen nicht die Kotbasis sprengen, nur um dieses winzige Stückchen mehr an Sicherheit und Anonymität zu gewinnen. Ich bin auch der Meinung, dass das keine Absolute sind, sondern dass man da individuell entscheiden muss. Reicht im Grunde nicht die anonyme Fragefunktion von Moodle oder anonyme Zettel? Ja, kennen Sie das, wenn eine Fakultät historisch gewachsen ist. Wir haben zehn Moodles an der Fakultät. Zettel sind totes Holz informatisch. Wir wollen nicht Zettel, Sie wollen gerne technologische Lösung. Ja gut, bei Wahlen dann vielleicht nicht und dann sind wir da vielleicht in der Klasse. Das sind alles valide Alternativen, wirklich. So ist es bei uns geworden jetzt. Okay, welche Punkte am aktuellen Stand der Software stören dich noch und würdest du noch verbessern wollen? Bezüglich der Anonymität bin ich schon recht zufrieden. Ich glaube auch, dass alles, was man da mehr programmieren würde, nicht das Problem fix, dass die Leute ja gar nicht wissen können, auf der Open Source Seite zeigen. Also ich glaube, das ist an der Stelle das größere Problem als an der Codebase selbst und von der Funktionalität der Plattform selbst. Ja, wir sind so gewachsen. Ich würde mir ein bisschen mehr Automatisierung von Erinnerungen wünschen. Also viele Dozierende lassen sich so Zeit bis sie mal ihren Fragebogen bestätigen. Da bauen wir jetzt so einen Knopf, der einfach alle mal erinnert. Ich glaube auch, dass die Leute ihre Evaluierungen einstellen sollen. Wie regelt ihr das Löschen der Daten? Wie lange bleiben die Antworten für die Lehrenden verfügbar? Die Antworten werden archiviert nach sechs Semestern in etwa. So Dozierende ändern ja auch ihre Veranstaltungskonzepte. Es kommen neue Leute dazu. Sie verbessern sich und es sollen einfach nicht fünf Jahre alte Evaluierungsergebnisse, die einen Einfluss darauf haben, wie die Studierenden heute ihre Lehrveranstaltung wählen, zum Beispiel. Die Leute können aber sich ja einen Export machen, wenn sie die Veranstaltung noch sehen können. Also da haben wir nicht mehr so, also wir geben das ja weg und damit ist es erstmal weggegeben. Aber für Leute, die neu an die Uni kommen, die sehen immer nur die vergangenen drei Jahre. Ja. Dann wird jeder Punkt der CIA-Triade erfüllt. CIA-Triade ist Confidentiality, Integrity und Availability. Die kenne ich nicht. Also Verfügbarkeit, Integrität und Vertraulichkeit. Kannst du mir helfen, das zuzuordnen? Ja, ich denke mal einfach so, wie wird die Vertraulichkeit bei euch sichergestellt? Also vielleicht welche technischen organisatorischen Maßnahmen habt ihr implementiert, um Daten irgendwo zu sichern für unberechtigter Einsichtnahme oder für unberechtigter Veränderung und dass sie halt auch dann da ist, wenn man sie braucht. Ach so. Na ja, wir haben einen Gremium, das kümmert sich um die Seevaluierungsplattformen. Da gibt es genau zwei Leute, die abmins sind und Zugriff auf den Server haben. Und genau drei Leute, die Verwaltungszugriff auf die Plattform haben. Also da die Veranstaltungen bearbeiten können. Dieses Gremium, dieses Fachschaftsrats, das wird also auch gewählt aus der Studierendenschaft. Und ich denke, dadurch haben wir einen ziemlich demokratischen Ansatz, was die Kontrolle dieser Plattform angeht. Aber ja, wie sich das jetzt auf dieses Jahr etriade bezieht? Ja. So, dann nächste Frage. Habt ihr darüber nachgedacht, KI zu nutzen, um den Schreibstil anzugleichen? Da gibt es Projekte zu. Alle Texte gleich oder ähnlich formuliert? Wir haben mal darüber nachgedacht, mit KI-Beleidigungen zu erkennen, um die dann hinter einer Content Warning oder sowas anzuzeigen. Haben uns aber auch dagegen entschieden. Das ist kein großes Problem tatsächlich. Also manchmal wollen die Leute auch erkannt werden. Und ansonsten ist es mit dem Schreibstil, haben wir das noch nie als Problem wahrgenommen, dass so groß ist, dass man sich da wirklich automatisiert drum kümmern muss. Ja, und wie gesagt, wir wollen das Feedback nicht verfälschen, auch nicht durch eine KI. Das ist uns irgendwie das höhere Gut an der Stelle.