[NRW LiqDem] Fwd: [Aktive] offener Brief an den Bundesvorstand betreffend Löschungen in LiquidFeedback

[corax <corax AT piratenpartei-nrw.de>]

Dies ist eine weitergeleitete Nachricht
Von    : Andreas Nitsche <cicerolax AT gmail.com>
An     : "Hauptmailingliste der Piraten (Achtung: viele Mails pro Tag)" 
<aktive AT lists.piratenpartei.de>
Datum  : Freitag, 30. Juli 2010, 20:13
Betreff: [Aktive] offener Brief an den Bundesvorstand betreffend Löschungen 
in LiquidFeedback

===8<=================== Original Nachrichtentext ===================
FYI:

=====

Lieber Bundesvorstand,

auf der letzten Vorstandssitzung am 29. Juli 2010 wurden zwei Anträge
zum Thema Löschungen im LiquidFeedback-Betrieb behandelt. Ich möchte
im folgenden als einer der Entwickler von LiquidFeedback mein während
der Sitzung geäußertes Angebot einlösen, nocheinmal aus technischer
Sicht zu beschreiben, welche Löschungen bei LiquidFeedback technisch
möglich sind und welche Folgen dies für die Überprüfbarkeit hat. In
diesem Zuge werde ich auch nocheinmal auf die Exportfunktionen der
Software eingehen.

Hinweis: Im folgenden Text sind mit dem Begriff "Abstimmungsdaten"
sowohl die Daten von Endabstimmungen, als auch Unterstützerstimmen der
Diskussionsphasen gemeint.

Grundsätzlich lassen sich bei LiquidFeedback ALLE Daten löschen.
Hierbei ist jedoch zu beachten, dass bei der Löschung bestimmter
Daten, die davon abhängigen Daten aus Gründen der Datenbankintegrität
ebenfalls gelöscht werden müssen. Konkret bedeutet dies:

Das vollständige Löschen eines Nutzeraccounts erfordert die
vollständige Löschung aller Abstimmungsdaten zu Themen, an denen der
Benutzer teilgenommen hat. Dies begründet sich durch das Referenzieren
des Nutzeraccounts innerhalb der Delegationsbäume einer Abstimmung.

Das vollständige Löschen des Abstimmungsverhaltens eines
Nutzeraccounts erfordert ebenfalls die vollständige Löschung aller
Abstimmungsdaten zu Themen, an denen der Benutzer teilgenommen hat.
Dies begründet sich ebenfalls durch die Delegationsbäume.

Beim Löschen von Abstimmungsdaten können seit LiquidFeedback-Kern
Version 1.2.2 die Antragstexte sowie die zahlenmäßigen Ergebnisse der
Auszählung der Endabstimmung im System verbleiben. Dies war bis vor
einiger Zeit nicht möglich. Anregungen zu Initiativen, deren
Abstimmungsdaten gelöscht werden, müssen jedoch mitgelöscht werden, da
aus einer Anregung die potentielle Unterstützung der jeweiligen
Initiative folgt.

Neben der vollständigen Löschung von Datensätzen besteht die
Möglichkeit, einzelne Felder durch einen Leerstring oder
Zufallsbezeichner zu ersetzen. Dies ist technisch grundsätzlich immer
möglich. Hierdurch kann z.B. im Einzelfalle der aktuelle und/oder ein
alter Name eines Accounts aus dem System entfernt werden. Das
Modifizieren von beliebigen Primärschlüsseln würde allerdings die
Entwicklung eines speziellen Programmes voraussetzen.

Die Pseudonymhistorie liegt in der gleichen Tabelle wie die Historie
über die Stimmberechtigung eines Nutzers. Aus diesem Grunde sollten
alte Pseudonyme, falls nötig, bevorzugt durch Überschreiben mit einem
Leerstring oder "X" aus dem System entfernt werden.

Auch wenn eine vollständige Löschung eines Nutzeraccounts nur unter
bestimmten Voraussetzungen möglich ist, so ist es technisch kein
Problem, die Daten des Accounts jederzeit auf ein Mindestmaß zu
reduzieren, sofern Verknüpfungen zu getätigten Aktionen im System
erhalten bleiben (Unterstützerstimmen, etc.).

Bei allen Löschungen muss natürlich berücksichtigt werden, dass die
Daten zunächst auf "logischer" Ebene aus der Datenbank entfernt
werden. Eine vollständige "physikalische" Entfernung der Daten
gestaltet sich entsprechend schwieriger, und ist je nach Art der
verwendeten Festplatte gegebenenfalls nur durch physikalische
Zerstörung (z.B. durch einen Shredder mit geeigneter Schneideleistung)
sicherzustellen.

Weiterhin beziehen sich obengetroffene Aussagen nicht auf eventuell
existierende Backups des Datenbestandes. Diese müssten gesondert
betrachtet werden.

Die Vertrauenswürdigkeit des Systems basiert auf der vollständigen
Möglichkeit der Nachvollziehbarkeit der Prozesse. Hierbei müssen
jedoch in unserem Falle aufgrund der Nicht-Öffentlichkeit der
Mitgliederdatenbank bereits bestimmte Einschränkungen in Kauf genommen
werden.

Bezüglich der Frage, dass ein in LiquidFeedback angelegter Account
einem echten Mitglied gehört, muss also zunächst den mit der
Mitgliederverwaltung beauftragten Vorstandsmitgliedern, den Betreibern
der Clearingstelle sowie den Administratoren des
LiquidFeedback-Systems selbst VERTRAUT werden.

Damit das Anlegen von sogenannten "Sockenpuppen" jeder dieser 3
Stellen dennoch schwer gemacht wird bzw. niemand einen nachträglichen
Nachweis einer erfolgten Manipulation ausschließen kann, sind
verschiedene organisatorische und technische Maßnahmen getroffen
worden. Näheres hierzu findet sich in der Betriebsdokumentation.

In LiquidFeedback sind die Beteiligungen an Abstimmungen eines
einzelnen Nutzers über den Benutzeraccount selbst verknüpft. Diese
Verknüpfung ist notwendig, um die Verifikation der
Abstimmungsergebnisse in zwei Teilprobleme aufspalten zu können:

a) Die ordnungsgemäße "Akkreditierung", also das Einrichten von Accounts
b) Die korrekte Zählung der Stimmen

Ohne die Verknüpfung des Stimmverhaltens eines Nutzers bei
verschiedenen Abstimmungen ließen sich diese beiden Teilprobleme also
nicht getrennt betrachten.

Teil b) der Verifikation kann von allen Personen durchgeführt werden,
die Zugang zum (partei-)öffentlichen Datenbestand des
LiquidFeedback-Systems haben. Teil a) der Verifikation kann hingegen
nur von Personen durchgeführt werden, die Zugang zur Mitgliederdatei
besitzen.

Die Einschränkung der Personengruppe, die den Teil a) überprüfen kann,
stellt kein grundsätzliches Problem dar, da ein mit der
Mitgliederverwaltung beauftragtes Vorstandsmitglied irgendwann einen
Nachfolger haben kann, der entsprechende Manipulationen aufdecken
könnte. Manipulieren bedeutet an dieser Stelle also ein ganz reales
persönliches Risiko einzugehen. Zusätzliche Sicherheit lässt sich
durch Beteiligung mehrerer Personen an den Prozessen erreichen.

Verzichtet man allerdings auf die Verknüpfung des Stimmverhaltens
eines Nutzers bei verschiedenen Abstimmungen, dann verschmelzen die
Probleme a) und b) zu einem neuen Problem c), welches sich ungleich
komplexer gestaltet: Teilnehmer ohne Zugriffsmöglichkeit auf die
Mitgliedsdaten hätten gar keine Möglichkeit mehr, an der Überprüfung
des Systems mitzuwirken. Die Personen, welche Zugriff auf die
Mitgliederverwaltung haben, müssten JEDE ABSTIMMUNG EINZELN
verifizieren. Dokumentationen der Vorgänge müssten seitens der
Mitgliederverwaltung nicht nur in Bezug auf jedes Mitglied, sondern in
Bezug auf jede Beziehung zwischen Mitglied und Abstimmung angefertigt
werden. Ein solches Vorhaben hielte ich für vollkommen aussichtlos -
eine Überprüfung praktisch unmöglich.

Die Aufspaltung der Teilprobleme a) und b) aus oben genannten Gründen
als gegeben betrachtend, möchte ich nun auf Teil b) näher eingehen:

Damit die Teilnehmer des Systems die Ergebnisse im Rahmen des
Teilproblems b) sinnvoll überprüfen können, ist es notwendig ihnen den
Zugang zu bestimmten Daten zu geben. Diese Daten habe ich oben als
"(partei-)öffentlich" bezeichnet. Hierzu zählt insbesondere die
Information, WELCHER Nutzeraccount WIE abgestimmt hat. Die Daten
müssen von verschiedenen Teilnehmern auf Konsistenz bzw. Gleichheit
überprüft werden können, damit es den Administratoren (oder einem
Hacker) nicht möglich ist, unterschiedlichen Personen verschiedene
Datenbestände anzeigen zu können. Aus diesem Grunde gibt es in
LiquidFeedback die Möglichkeit den relevanten Datenbestand in Form
eines Datenbankdumps herunterzuladen. Der Dump wird in regelmäßigen
Abständen erstellt, so dass das Erstellen von Prüfsummen bereits ein
einfaches Mittel ist, um die Gleichheit der selbst heruntergeladenen
Daten mit denen von anderen Teilnehmern des Systems zu kontrollieren.

Sicherzustellen, dass den Teilnehmern das selbe Bild des
Datenbestandes angezeigt wird, reicht allerdings nicht aus, um
Manipulationen bei einer Abstimmung auszuschließen. Hierzu muss auch
überprüft werden, ob die abgegebenen Stimmen tatsächlich den
abgegebenen Stimmen der Benutzer entsprechen. Es ist daher notwendig,
dass die Abstimmungen namentlich (bzw. pseudonym) einsehbar sind. Eine
Überprüfung der eigenen Stimme mittels kryptographischer Verfahren
ohne einsehbare Verknüpfung zum Benutzeraccount durch andere
Teilnehmer würde nur dann einen gewissen Schutz vor Manipulationen
bieten, wenn ALLE im System registrierten Teilnehmer auch tatsächlich
an JEDER Abstimmung teilnehmen. Da dies praktisch nie der Fall ist,
kommt ein solches Vorgehen nicht in Frage.

Fängt man nun an, Teile des Abstimmungsverhaltens zu löschen,
gestaltet sich eine Überprüfung immer schwieriger. Wie im ersten Teil
meines Textes erläutert, besteht aus Gründen der Datenbankintegrität
ohnehin nur die Möglichkeit in einem Thema die GESAMTEN abgegebenen
Stimmen zu einem Thema zu löschen. Wahlweise könnten Benutzeraccounts
mit einem zufälligen Pseudonym versehen werden, sowie deren
Pseudonymhistorie gelöscht werden.

An dieser Stelle werde ich ein paar Worte zum vielbeschworenen
"Morpheus-Prozess" loswerden müssen. Dieser Begriff stammt nicht von
mir, und vermutlich ist hiermit die "Operation Morpheus" des
Landesverbandes Berlin gemeint. Es handelte sich um einen manuellen
Eingriff in den Ablauf des Systems, bei dem es einzelnen Mitgliedern
möglich war, ihr Pseudonym sowie ihre Pseudonymhistorie zu löschen. Es
handelte sich bei diesem Vorgehen um eine Maßnahme des Vorstands, um
all jenen Mitgliedern entgegenzukommen, die sich nicht der
Konsequenzen bestimmter Nutzungsweisen des Systems bewusst waren. Bei
dieser Operation wurden die Pseudoyme sowie die Pseudoynmhistorien
aller Mitglieder gelöscht, die der bereits in den alten
Nutzungsbedingungen vorgesehenen, jedoch noch nicht durchgeführten,
umfangreichen Veröffentlichung der Daten nicht zustimmten wollten.
Eine Zuordnung zwischen altem- und neuem Account findet sich nach
Abschluss des Eingriffes in Form einer Zuordnungsliste zwischen altem-
und neuen Invite-Code beim Vorstand. Dieses Verfahren war als
einmalige Maßnahme vertretbar, für einen Regelbetrieb eignet es sich
jedoch nicht, wie ich im folgenden Absatz erläutern werde:

Steht es jedem Mitglied frei, einen bestehenden Account nach einer
Sperrung mit einem zufälligem Pseudonym versehen zu lassen, um
anschließend mit neuem Account im System agieren zu können, dann
nähert sich das Gesamtsystem der oben beschriebenen Fusion der
Teilprobleme a) und b) an - zumindest dann, wenn von dieser
Möglichkeit regelmäßig Gebrauch gemacht werden würde, wovon auszugehen
ist. Der Informationsgehalt der Aussage "Pirat X hat zu Thema Y so und
so abgestimmt" sinkt auf Null, wenn Pirat X ausschließlich zur
Abstimmung dieses Themas im System erscheint, und anschließend für
immer verschwindet. Der Dokumentationsaufwand seitens des Vorstands
stiege enorm, und ein Nachfolger hätte es sehr viel schwerer alle
Vorgänge nachzuvollziehen. Eine ordentliche Überprüfung wäre in der
Praxis, je nach Nutzungsgrad solcher Accountwechselmöglichkeiten,
nicht mehr leistbar.

In Bezug auf die Überprüfbarkeit spricht allerdings nichts gegen eine
Löschung von Daten, wenn diese Löschung erst nach einer gewissen Frist
(z.B. 5 Jahre) durchgeführt wird. In einer solchen Frist bestünde
ausreichend Gelegenheit Manipulationen aufzudecken. In jedem Falle
müssen die LiquidFeedback-Accounts sowie deren
Verknüpfungsinformationen zur Mitgliederverwaltung (Invite- und
Referenzcodes) für eine solche Zeitdauer gespeichert bleiben, da
ansonsten bei einer späteren Überprüfung stets behauptet werden
könnte, dass es sich bei einem Sockenpuppenaccount um einen regulär
anonymisierten Account gehandelt habe.

Soweit zur Frage der Vertretbarkeit von Löschungen in Bezug auf die
Überprüfbarkeit. Inwieweit jegliche Form von Löschungen allerdings
praktisch durchsetzbar sind, wenn über 10000 Mitglieder auf den
Datenbestand zugreifen können, bleibt offen. Warum den Teilnehmern des
Systems überhaupt ein Zugriff auf die Daten möglich gemacht werden
muss, habe ich ja bereits erläutert.

Anmerken möchte ich, dass alle einsichtigen Daten auch OHNE das
Anbieten einer expliziten Downloadfunktion von Nutzern abgespeichert
werden können (im Zweifelsfalle durch "Datei -> Speichern Unter"). Das
Bereitstellen einer Downloadfunktion senkt das Bedürfnis der
Teilnehmer, selbst entsprechende Spider zu entwickeln, die - das muss
gesagt werden - bestimmte Profildaten dann vielleicht NICHT
herausfiltern.

Ob der Datenbestand nur den Parteimitgliedern bzw. Systemteilnehmern
oder der gesamten Öffentlichkeit zur Verfügung gestellt wird, halte
ich bezüglich der Überprüfbarkeit für weitgehend irrelevant, doch auch
hier sollte man sich nicht der Illusion hingeben, dass Daten, welche
im Zugriffsbereich von über 10000 Personen liegen, geheimzuhalten
sind.

Zur politischen Frage, ob wir unsere Entscheidungsprozesse vollständig
transparent gestalten wollen, könnte ich zwar als Pirat etwas sagen -
in meiner Rolle als Entwickler möchte ich hierzu jedoch keine Stellung
nehmen.

Abschließend noch ein kleiner Zusatzhinweis für Jens, der das
Vorhandensein von Primärschlüsseln ansprach: Die Primärschlüssel
lassen sich nur dann anderen Datensätzen zuordnen, wenn ein anderer
Datenbankdump der selben Datenbank von einem anderen Zeitpunkt
vorliegt. In einem solchen Falle wäre aber eine Zuordnung von
Datensätzen aufgrund der Stimmenverteilung ohnehin möglich. Auch ohne
Primärschlüssel ließen sich eindeutige Accountmerkmale berechnen. Das
Modifizieren von Primärschlüsseln halte ich aus diesem Grunde in
keinem Falle für gewinnbringend.

Ich hoffe den Lesern meines Textes etwas mehr Klarheit darüber
verschafft zu haben, welche Löschungen bei LiquidFeedback technisch
möglich sind, und welche Auswirkungen bestimmte Löschungen haben (oder
auch nicht haben).

Liebe Grüße
Jan Behrens

=====

(weitergeleitet, da Jan diese Liste nicht nutzt)
Gruß Skipper
_______________________________________________
Aktive mailing list
Aktive AT lists.piratenpartei.de
https://service.piratenpartei.de/mailman/listinfo/aktive

===8<============== Ende des Original Nachrichtentextes =============



--  
Mit freundlichen Grüßen
mailto: corax AT piratenpartei-nrw.de
follow: https://twitter.com/coraxaroc
follow: https://twitter.com/PIRATENnrwHILFE

Bitte beachten: Persönliche Emails an mich, mit nicht persönlichem,
sondern politischem oder parteibetreffendem Inhalt, werde ich (im
Sinne der Transparenz) nach eigenem Ermessen veröffentlichen.

--- Begin Message ---

• From: Andreas Nitsche <cicerolax AT gmail.com>
• To: "Hauptmailingliste der Piraten (Achtung: viele Mails pro Tag)" <aktive AT lists.piratenpartei.de>
• Subject: [Aktive] offener Brief an den Bundesvorstand betreffend Löschungen in LiquidFeedback
• Date: Fri, 30 Jul 2010 20:13:40 +0200
• List-id: "Hauptmailingliste der Piraten \(Achtung: viele Mails pro Tag\)" <aktive.lists.piratenpartei.de>

FYI:

=====

Lieber Bundesvorstand,

auf der letzten Vorstandssitzung am 29. Juli 2010 wurden zwei Anträge
zum Thema Löschungen im LiquidFeedback-Betrieb behandelt. Ich möchte
im folgenden als einer der Entwickler von LiquidFeedback mein während
der Sitzung geäußertes Angebot einlösen, nocheinmal aus technischer
Sicht zu beschreiben, welche Löschungen bei LiquidFeedback technisch
möglich sind und welche Folgen dies für die Überprüfbarkeit hat. In
diesem Zuge werde ich auch nocheinmal auf die Exportfunktionen der
Software eingehen.

Hinweis: Im folgenden Text sind mit dem Begriff "Abstimmungsdaten"
sowohl die Daten von Endabstimmungen, als auch Unterstützerstimmen der
Diskussionsphasen gemeint.

Grundsätzlich lassen sich bei LiquidFeedback ALLE Daten löschen.
Hierbei ist jedoch zu beachten, dass bei der Löschung bestimmter
Daten, die davon abhängigen Daten aus Gründen der Datenbankintegrität
ebenfalls gelöscht werden müssen. Konkret bedeutet dies:

Das vollständige Löschen eines Nutzeraccounts erfordert die
vollständige Löschung aller Abstimmungsdaten zu Themen, an denen der
Benutzer teilgenommen hat. Dies begründet sich durch das Referenzieren
des Nutzeraccounts innerhalb der Delegationsbäume einer Abstimmung.

Das vollständige Löschen des Abstimmungsverhaltens eines
Nutzeraccounts erfordert ebenfalls die vollständige Löschung aller
Abstimmungsdaten zu Themen, an denen der Benutzer teilgenommen hat.
Dies begründet sich ebenfalls durch die Delegationsbäume.

Beim Löschen von Abstimmungsdaten können seit LiquidFeedback-Kern
Version 1.2.2 die Antragstexte sowie die zahlenmäßigen Ergebnisse der
Auszählung der Endabstimmung im System verbleiben. Dies war bis vor
einiger Zeit nicht möglich. Anregungen zu Initiativen, deren
Abstimmungsdaten gelöscht werden, müssen jedoch mitgelöscht werden, da
aus einer Anregung die potentielle Unterstützung der jeweiligen
Initiative folgt.

Neben der vollständigen Löschung von Datensätzen besteht die
Möglichkeit, einzelne Felder durch einen Leerstring oder
Zufallsbezeichner zu ersetzen. Dies ist technisch grundsätzlich immer
möglich. Hierdurch kann z.B. im Einzelfalle der aktuelle und/oder ein
alter Name eines Accounts aus dem System entfernt werden. Das
Modifizieren von beliebigen Primärschlüsseln würde allerdings die
Entwicklung eines speziellen Programmes voraussetzen.

Die Pseudonymhistorie liegt in der gleichen Tabelle wie die Historie
über die Stimmberechtigung eines Nutzers. Aus diesem Grunde sollten
alte Pseudonyme, falls nötig, bevorzugt durch Überschreiben mit einem
Leerstring oder "X" aus dem System entfernt werden.

Auch wenn eine vollständige Löschung eines Nutzeraccounts nur unter
bestimmten Voraussetzungen möglich ist, so ist es technisch kein
Problem, die Daten des Accounts jederzeit auf ein Mindestmaß zu
reduzieren, sofern Verknüpfungen zu getätigten Aktionen im System
erhalten bleiben (Unterstützerstimmen, etc.).

Bei allen Löschungen muss natürlich berücksichtigt werden, dass die
Daten zunächst auf "logischer" Ebene aus der Datenbank entfernt
werden. Eine vollständige "physikalische" Entfernung der Daten
gestaltet sich entsprechend schwieriger, und ist je nach Art der
verwendeten Festplatte gegebenenfalls nur durch physikalische
Zerstörung (z.B. durch einen Shredder mit geeigneter Schneideleistung)
sicherzustellen.

Weiterhin beziehen sich obengetroffene Aussagen nicht auf eventuell
existierende Backups des Datenbestandes. Diese müssten gesondert
betrachtet werden.

Die Vertrauenswürdigkeit des Systems basiert auf der vollständigen
Möglichkeit der Nachvollziehbarkeit der Prozesse. Hierbei müssen
jedoch in unserem Falle aufgrund der Nicht-Öffentlichkeit der
Mitgliederdatenbank bereits bestimmte Einschränkungen in Kauf genommen
werden.

Bezüglich der Frage, dass ein in LiquidFeedback angelegter Account
einem echten Mitglied gehört, muss also zunächst den mit der
Mitgliederverwaltung beauftragten Vorstandsmitgliedern, den Betreibern
der Clearingstelle sowie den Administratoren des
LiquidFeedback-Systems selbst VERTRAUT werden.

Damit das Anlegen von sogenannten "Sockenpuppen" jeder dieser 3
Stellen dennoch schwer gemacht wird bzw. niemand einen nachträglichen
Nachweis einer erfolgten Manipulation ausschließen kann, sind
verschiedene organisatorische und technische Maßnahmen getroffen
worden. Näheres hierzu findet sich in der Betriebsdokumentation.

In LiquidFeedback sind die Beteiligungen an Abstimmungen eines
einzelnen Nutzers über den Benutzeraccount selbst verknüpft. Diese
Verknüpfung ist notwendig, um die Verifikation der
Abstimmungsergebnisse in zwei Teilprobleme aufspalten zu können:

a) Die ordnungsgemäße "Akkreditierung", also das Einrichten von Accounts
b) Die korrekte Zählung der Stimmen

Ohne die Verknüpfung des Stimmverhaltens eines Nutzers bei
verschiedenen Abstimmungen ließen sich diese beiden Teilprobleme also
nicht getrennt betrachten.

Teil b) der Verifikation kann von allen Personen durchgeführt werden,
die Zugang zum (partei-)öffentlichen Datenbestand des
LiquidFeedback-Systems haben. Teil a) der Verifikation kann hingegen
nur von Personen durchgeführt werden, die Zugang zur Mitgliederdatei
besitzen.

Die Einschränkung der Personengruppe, die den Teil a) überprüfen kann,
stellt kein grundsätzliches Problem dar, da ein mit der
Mitgliederverwaltung beauftragtes Vorstandsmitglied irgendwann einen
Nachfolger haben kann, der entsprechende Manipulationen aufdecken
könnte. Manipulieren bedeutet an dieser Stelle also ein ganz reales
persönliches Risiko einzugehen. Zusätzliche Sicherheit lässt sich
durch Beteiligung mehrerer Personen an den Prozessen erreichen.

Verzichtet man allerdings auf die Verknüpfung des Stimmverhaltens
eines Nutzers bei verschiedenen Abstimmungen, dann verschmelzen die
Probleme a) und b) zu einem neuen Problem c), welches sich ungleich
komplexer gestaltet: Teilnehmer ohne Zugriffsmöglichkeit auf die
Mitgliedsdaten hätten gar keine Möglichkeit mehr, an der Überprüfung
des Systems mitzuwirken. Die Personen, welche Zugriff auf die
Mitgliederverwaltung haben, müssten JEDE ABSTIMMUNG EINZELN
verifizieren. Dokumentationen der Vorgänge müssten seitens der
Mitgliederverwaltung nicht nur in Bezug auf jedes Mitglied, sondern in
Bezug auf jede Beziehung zwischen Mitglied und Abstimmung angefertigt
werden. Ein solches Vorhaben hielte ich für vollkommen aussichtlos -
eine Überprüfung praktisch unmöglich.

Die Aufspaltung der Teilprobleme a) und b) aus oben genannten Gründen
als gegeben betrachtend, möchte ich nun auf Teil b) näher eingehen:

Damit die Teilnehmer des Systems die Ergebnisse im Rahmen des
Teilproblems b) sinnvoll überprüfen können, ist es notwendig ihnen den
Zugang zu bestimmten Daten zu geben. Diese Daten habe ich oben als
"(partei-)öffentlich" bezeichnet. Hierzu zählt insbesondere die
Information, WELCHER Nutzeraccount WIE abgestimmt hat. Die Daten
müssen von verschiedenen Teilnehmern auf Konsistenz bzw. Gleichheit
überprüft werden können, damit es den Administratoren (oder einem
Hacker) nicht möglich ist, unterschiedlichen Personen verschiedene
Datenbestände anzeigen zu können. Aus diesem Grunde gibt es in
LiquidFeedback die Möglichkeit den relevanten Datenbestand in Form
eines Datenbankdumps herunterzuladen. Der Dump wird in regelmäßigen
Abständen erstellt, so dass das Erstellen von Prüfsummen bereits ein
einfaches Mittel ist, um die Gleichheit der selbst heruntergeladenen
Daten mit denen von anderen Teilnehmern des Systems zu kontrollieren.

Sicherzustellen, dass den Teilnehmern das selbe Bild des
Datenbestandes angezeigt wird, reicht allerdings nicht aus, um
Manipulationen bei einer Abstimmung auszuschließen. Hierzu muss auch
überprüft werden, ob die abgegebenen Stimmen tatsächlich den
abgegebenen Stimmen der Benutzer entsprechen. Es ist daher notwendig,
dass die Abstimmungen namentlich (bzw. pseudonym) einsehbar sind. Eine
Überprüfung der eigenen Stimme mittels kryptographischer Verfahren
ohne einsehbare Verknüpfung zum Benutzeraccount durch andere
Teilnehmer würde nur dann einen gewissen Schutz vor Manipulationen
bieten, wenn ALLE im System registrierten Teilnehmer auch tatsächlich
an JEDER Abstimmung teilnehmen. Da dies praktisch nie der Fall ist,
kommt ein solches Vorgehen nicht in Frage.

Fängt man nun an, Teile des Abstimmungsverhaltens zu löschen,
gestaltet sich eine Überprüfung immer schwieriger. Wie im ersten Teil
meines Textes erläutert, besteht aus Gründen der Datenbankintegrität
ohnehin nur die Möglichkeit in einem Thema die GESAMTEN abgegebenen
Stimmen zu einem Thema zu löschen. Wahlweise könnten Benutzeraccounts
mit einem zufälligen Pseudonym versehen werden, sowie deren
Pseudonymhistorie gelöscht werden.

An dieser Stelle werde ich ein paar Worte zum vielbeschworenen
"Morpheus-Prozess" loswerden müssen. Dieser Begriff stammt nicht von
mir, und vermutlich ist hiermit die "Operation Morpheus" des
Landesverbandes Berlin gemeint. Es handelte sich um einen manuellen
Eingriff in den Ablauf des Systems, bei dem es einzelnen Mitgliedern
möglich war, ihr Pseudonym sowie ihre Pseudonymhistorie zu löschen. Es
handelte sich bei diesem Vorgehen um eine Maßnahme des Vorstands, um
all jenen Mitgliedern entgegenzukommen, die sich nicht der
Konsequenzen bestimmter Nutzungsweisen des Systems bewusst waren. Bei
dieser Operation wurden die Pseudoyme sowie die Pseudoynmhistorien
aller Mitglieder gelöscht, die der bereits in den alten
Nutzungsbedingungen vorgesehenen, jedoch noch nicht durchgeführten,
umfangreichen Veröffentlichung der Daten nicht zustimmten wollten.
Eine Zuordnung zwischen altem- und neuem Account findet sich nach
Abschluss des Eingriffes in Form einer Zuordnungsliste zwischen altem-
und neuen Invite-Code beim Vorstand. Dieses Verfahren war als
einmalige Maßnahme vertretbar, für einen Regelbetrieb eignet es sich
jedoch nicht, wie ich im folgenden Absatz erläutern werde:

Steht es jedem Mitglied frei, einen bestehenden Account nach einer
Sperrung mit einem zufälligem Pseudonym versehen zu lassen, um
anschließend mit neuem Account im System agieren zu können, dann
nähert sich das Gesamtsystem der oben beschriebenen Fusion der
Teilprobleme a) und b) an - zumindest dann, wenn von dieser
Möglichkeit regelmäßig Gebrauch gemacht werden würde, wovon auszugehen
ist. Der Informationsgehalt der Aussage "Pirat X hat zu Thema Y so und
so abgestimmt" sinkt auf Null, wenn Pirat X ausschließlich zur
Abstimmung dieses Themas im System erscheint, und anschließend für
immer verschwindet. Der Dokumentationsaufwand seitens des Vorstands
stiege enorm, und ein Nachfolger hätte es sehr viel schwerer alle
Vorgänge nachzuvollziehen. Eine ordentliche Überprüfung wäre in der
Praxis, je nach Nutzungsgrad solcher Accountwechselmöglichkeiten,
nicht mehr leistbar.

In Bezug auf die Überprüfbarkeit spricht allerdings nichts gegen eine
Löschung von Daten, wenn diese Löschung erst nach einer gewissen Frist
(z.B. 5 Jahre) durchgeführt wird. In einer solchen Frist bestünde
ausreichend Gelegenheit Manipulationen aufzudecken. In jedem Falle
müssen die LiquidFeedback-Accounts sowie deren
Verknüpfungsinformationen zur Mitgliederverwaltung (Invite- und
Referenzcodes) für eine solche Zeitdauer gespeichert bleiben, da
ansonsten bei einer späteren Überprüfung stets behauptet werden
könnte, dass es sich bei einem Sockenpuppenaccount um einen regulär
anonymisierten Account gehandelt habe.

Soweit zur Frage der Vertretbarkeit von Löschungen in Bezug auf die
Überprüfbarkeit. Inwieweit jegliche Form von Löschungen allerdings
praktisch durchsetzbar sind, wenn über 10000 Mitglieder auf den
Datenbestand zugreifen können, bleibt offen. Warum den Teilnehmern des
Systems überhaupt ein Zugriff auf die Daten möglich gemacht werden
muss, habe ich ja bereits erläutert.

Anmerken möchte ich, dass alle einsichtigen Daten auch OHNE das
Anbieten einer expliziten Downloadfunktion von Nutzern abgespeichert
werden können (im Zweifelsfalle durch "Datei -> Speichern Unter"). Das
Bereitstellen einer Downloadfunktion senkt das Bedürfnis der
Teilnehmer, selbst entsprechende Spider zu entwickeln, die - das muss
gesagt werden - bestimmte Profildaten dann vielleicht NICHT
herausfiltern.

Ob der Datenbestand nur den Parteimitgliedern bzw. Systemteilnehmern
oder der gesamten Öffentlichkeit zur Verfügung gestellt wird, halte
ich bezüglich der Überprüfbarkeit für weitgehend irrelevant, doch auch
hier sollte man sich nicht der Illusion hingeben, dass Daten, welche
im Zugriffsbereich von über 10000 Personen liegen, geheimzuhalten
sind.

Zur politischen Frage, ob wir unsere Entscheidungsprozesse vollständig
transparent gestalten wollen, könnte ich zwar als Pirat etwas sagen -
in meiner Rolle als Entwickler möchte ich hierzu jedoch keine Stellung
nehmen.

Abschließend noch ein kleiner Zusatzhinweis für Jens, der das
Vorhandensein von Primärschlüsseln ansprach: Die Primärschlüssel
lassen sich nur dann anderen Datensätzen zuordnen, wenn ein anderer
Datenbankdump der selben Datenbank von einem anderen Zeitpunkt
vorliegt. In einem solchen Falle wäre aber eine Zuordnung von
Datensätzen aufgrund der Stimmenverteilung ohnehin möglich. Auch ohne
Primärschlüssel ließen sich eindeutige Accountmerkmale berechnen. Das
Modifizieren von Primärschlüsseln halte ich aus diesem Grunde in
keinem Falle für gewinnbringend.

Ich hoffe den Lesern meines Textes etwas mehr Klarheit darüber
verschafft zu haben, welche Löschungen bei LiquidFeedback technisch
möglich sind, und welche Auswirkungen bestimmte Löschungen haben (oder
auch nicht haben).

Liebe Grüße
Jan Behrens

=====

(weitergeleitet, da Jan diese Liste nicht nutzt)
Gruß Skipper
_______________________________________________
Aktive mailing list
Aktive AT lists.piratenpartei.de
https://service.piratenpartei.de/mailman/listinfo/aktive

--- End Message ---