LQPP/Fragen

Aus Piratenwiki Mirror
< LQPP
Version vom 15. September 2010, 14:14 Uhr von imported>Shw
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen
Auf dieser Seite können Fragen bezüglich der Bundesweiten Einführung von Liquid Feedback gestellt werden. Sie werden nach Möglichkeit zeitnah beantwortet werden. Diese Seite soll in erster Linie Unklarheiten und Befürchtungen aus der Welt schaffen und dient insbesondere nicht dazu, Funktionen oder Prinzipien des Systems grundsätzlich in Frage zu stellen. Sie ist von daher nicht als Diskussionsseite zu verstehen. Stellt eure Fragen bitte sachlich und freundlich, die Personen die sie beantworten werden sind auch nur Menschen. Wir freuen uns natürlich auch über Spenden für Liquid Feedback:
Empfänger: Piratenpartei Deutschland
Kontonr.: 7006 027 900
BLZ: 430 609 67
Bank: GLS Gemeinschaftsbank
Verwendungszweck: Spende von Name, Vorname, PI, LQFB
Bei Piraten ist PI die Mitgliedsnummer, bei nicht Piraten empfiehlt sich die Adresse.

Bitte schau vor dem Fragen auch nochmal in das umfangreiche Liquid Feedback FAQ ob Deine Frage vielleicht schon dort beantwortet wurde.

Frage: Welche Anforderungen (und Fragen) zur Ausarbeitung der Nutzungsbedingungen werden gestellt?

Wenn ich der Rechtsabteilung meiner Firma oder auch unserem Datenschutzbeauftragten (extern) einen Vertrag oder auch Nutzungsbedinungen für unsere Firmenseiten ausarbeiten lassen will - dann muss ich dem Anforderungen stellen.

  • Was will ich machen/erreichen
  • Was davon kann ich wie erreichen
  • Was davon ist nicht oder nur unter großen Risiken möglich

Welche Anforderungen (und Fragen) zur Ausarbeitung der Nutzungsbedingungen werden gestellt?

Antwort

Unser Ziel ist, dass LiquidFeedback möglichst transparent das Meinungsbild der Mitglieder abbildet, was erfordert, dass die Prozesse, die im System stattfinden und vor allem die Abstimmung möglichst dauerhaft nachvollziehbar sind.

Dabei wollen wir neben den hohen Transparenzansprüchen an das System, einen möglichst hohen Datenschutz und Persönlichkeitsschutz für die Mitglieder bieten.

Dies wollen wir dadurch erreichen, dass alle Prozesse, die im System stattfinden dauerhaft gespeichert und öffentlich einsehbar sind, während die Nutzer die Möglichkeit haben ein Pseudonym zu nutzen und umfangreich über Risiken, Systemsicherungsmaßnahmen und Speicherung von Daten sowie Speicherungszweck aufgeklärt werden. Dabei soll sicher gestellt werden, dass möglichst niemand das Pseudonym einzelnen Nutzern zuordnen kann, wenn der Nutzer dies nicht selber preisgibt. Um dies zu gewährleisten, soll unter anderem eine Clearingstelle eingerichtet werden. Die genauen Prozesse diesbezüglich werden hier ausgearbeitet und beschrieben: http://wiki.piratenpartei.de/LQPP/Betriebsdoku

Um eine umfangreiche Aufklärung der Nutzer sicherzustellen, wurde die Kanzlei dazu beauftragt, die Nutzungsbedingungen und die Datenschutzerklärung ohne Schönfärberei so auszuarbeiten, dass diese datenschutzrechtskonform und für jeden Nutzer transparent und klar verständlich sind. Dabei wurde klargestellt, dass wir unter der Maßgabe der Transparenz des Systems einen maximalen Datenschutz für die Nutzer wollen.

Eine anonyme Nutzung ist dabei nicht möglich, da sichergestellt werden muss, dass das System nur von Piraten genutzt wird und entsprechend eine Möglichkeit bestehen muss, dass Accounts beim Austritt gelöscht werden.

Frage: Speicherung in alle Ewigkeit?

Aus der Antwort kann man herauslesen, das weiterhin beabsichtigt ist, Daten im System niemals zu löschen. Ist das korrekt? ValiDOM

Antwort

Im Moment ist geplant die Daten nicht zu löschen, um das System möglichst transparent zu gestalten und nachvollziehbare Meinungsbilder zu erhalten. Es wird aber über eine Sperrung der Daten nach einer bestimmten Zeit nachgedacht.

  • Wo/Wie kann man sich in dieses Nachdenken einbringen? ValiDOM
    • Du kannst Dich an christopher.lauer@piratenpartei.de mit Deinen Vorschlägen wenden.--Christopher Lauer 12:55, 23. Jun. 2010 (CEST)
      • Danke, das werde ich auch tun. Aber: haben wir sonst nicht eigentlich offene Diskussionsprozesse? Gibt es keine Gruppe, die das LQFB für den Bundesverband voranbringt? Ich habe hier einige bayr. Piraten die sich da gern einbringen würden. Oder sind Diskussionen unerwünscht? :D ValiDOM
        • Die Entwickler und ich stehen mit einigen Mitgliedern des Landesverbandes Bayern in Kontakt, die ihr Interesse bekundet haben an LF mitzuarbeiten. Wir haben offene Diskussionsprozesse, Du kannst Dich jederzeit an alle Beteiligten wenden und einbringen. Allerdings werden nicht mehr Grundlegende Voraussetzungen, um Liquid Feedback zu betreiben geändert werden. Das Team um Alexander Morlang, das sich grade mit der Realisierung von LF auf Bundesebene beschäftigt, arbeitet momentan auf hochturen, um den vom Bundesparteitag gesetzten Termin am 15.7. einzuhalten. --Commodore 13:38, 23. Jun. 2010 (CEST)
      • Ich hab jetzt rausfinden können, dass es eine Mailingliste für das Thema gibt: hier "bundesliquid" abonieren
  • Ist es noch aktuell, dass Daten nicht gelöscht werden sollen? --KH 17:23, 21. Jul. 2010 (CEST)
    • Ja (mit der unten aufgeführten Ausnahme). Simon Weiß 18:26, 21. Jul. 2010 (CEST)
  • Bittet ein einzelner Pirat um Löschung seiner Daten/seines Accounts: Wie soll damit umgegangen werden? --KH 17:23, 21. Jul. 2010 (CEST)
    • Der reguläre Prozess zur dauerhaften Sperrung eines Accounts beinhaltet die Löschung fast aller persönlicher Daten aus der Datenbank. Dazu gehören das Profil, die gespeicherten Kontakte, die Einstellungen im Frontend, Loginname, Passwort, die hinterlegte Emailadresse, Themenbereichsmitgliedschaften, Delegationen und Abstimmungen in noch nicht abgeschlossenen Themen. Nicht gelöscht werden das Pseudonym und die Pseudonymhistorie; die Löschung dieser Daten ist jedoch ebenfalls möglich und kann beim Vorstand beantragt werden. Eine Löschung sämtlicher Beiträge eines Benutzers wäre jedoch nicht möglich, da dies alle Themen berühren wurde, an denen er sich beteiligt hat. Simon Weiß 18:26, 21. Jul. 2010 (CEST)
      • Ergänzung: Beim regulären Prozess wird insbesondere auch der Invitecode und damit die Verbindung zwischen Teilnehmer und Account gelöscht. Simon Weiß 18:08, 22. Jul. 2010 (CEST)

Frage: Risiko von Globaldelegationen

Verstehe ich das korrekt, das man durch eine einmalige Aktion die eigene Stimme global/dauerhaft an einen anderen delegieren kann? Wenn ja: Widerspricht dieses "fire and forget" nicht dem Prinzip, das man "mitmachen" soll und und wie werden die Risiken einer solchen "Blankovollmacht" vermieden? tarzun

Antwort

Bitte schau in das bereits bestehende FAQ und überprüfe, ob Deine Frage dadurch geklärt werden konnte.

  • Tut es leider nicht. Ich sehe dort nicht, das Variante "Account anlegen, Globaldelegation vergeben und LQFB dann nie wieder anfassen" ausgeschlossen ist. Ich halte es aber für, hm, ungeschickt, wenn man es erlaubt, das man sich nach einer initialen Einrichtung "für immer" ausklinken kann. Ist Ziel von LQFB nicht auch eine *aktive* Teilnahme? tarzun 17:02, 24. Jun. 2010 (CEST)
Ziel von LiquidFeedback ist, eine aktive Teilnahme zu ermöglichen, nicht aber diese zu erzwingen. So ist es möglich eine Globaldelegation zu vergeben, und sich dann nicht mehr zu beteiligen, wobei diese "Blankovollmacht" jeder Zeit wieder entzogen werden kann. muuhh 17:39, 24. Jun. 2010 (CEST)
Wann werden Accounts denn inaktiv und stirbt mit dem Account die Delegation?
Die Accounts werden nicht automatisch inaktiv. Sie werden aber bei einem Stimmrechtsverlust (z.B. weil Mitgliedsbeiträge nicht gezahlt wurden) vorübergehend und bei Parteiaustritt dauerhaft deaktiviert. Damit entfällt dann auch die Stimmbrechtigung und damit die Delegation. muuhh 19:19, 24. Jun. 2010 (CEST)
Anmerkung: Es gibt keinen Grund Globaldelegationen anders zu behandeln als Themenbereichsdelegationen (zumal man aus Themenbereichsdelegationen eine Globaldelegation konstruieren kann). Insofern macht es Sinn für beide Delegationsarten eine einheitliche Verfallsregelung nach Nichtaktivität (wie z. B. in der Berliner Instanz beschlossen) festzulegen. Themendelegationen werden hingegen mit dem Abschluss des Themas ohnehin wirkungslos. --Skipper 20:29, 10. Jul. 2010 (CEST)

Frage: Wie werden die Einstellungen in Bezug auf Sichtbarkeit von Daten ohne Anmeldung sein?

LF erlaubt ja verschiedene Grundeinstellungen bezüglich der Sichtbarkeit von Initiativen:

  • Keine Sichtbarkeit ohne Anmeldung
  • Sichtbarkeit der Initiativen (ohne personenbezogene Daten)
  • Volle Sichtbarkeit aller Daten

Wir wird dies im Bund sein? Ike 14:19, 23. Jun. 2010 (CEST)

Antwort

Im Moment ist geplant, dass alle Initiativen und die Pseudonyme sichtbar sein werden.

Zur Klarstellung: Die Initiativen und die Pseudonyme (die ja ggf. auch die Klarnamen sein können) werden also auch ohne Anmeldung sichtbar sein? Dies bedeutet also, dass es passieren kann, dass diese Seiten (incl. des Namens) sicherlich auch von Suchmaschinen indiziert werden - mit allen bekannten Folgen - dies ist Absicht? Ike 14:09, 24. Jun. 2010 (CEST)
Genau deshalb wird jeder Nutzer in den Nutzungsbedingungen umfangreich aufgeklärt und darauf hingewiesen, dass man ein Pseudonym wählen muss, das man sonnst nirgends verwendet, wenn man vermeiden will, dass Rückschlüsse gezogen werden können. Jeder der dann seinen Klarnamen angibt, muss sich der bekannten Folgen bewusst sein. muuhh
Auf der Berliner Mailingliste ist eine hitzige Diskussion über eine Initiative entbrannt, die Pseudonyme im Berliner Liquid Feedback abschaffen und alle Nutzer zur Veröffentlichung ihres Realnames zwingen möchte. Damit wären dann vollständige politische "Gesinnungsprofile" möglich. Wie soll eurer Meinung nach sichergestellt werden, dass im Bundes-LF nicht auch eines Tages Pseudonyme aus "Transparenz-Gründen" abgeschafft werden, wenn sich das System erst einmal etabliert hat?
Die Piratenpartei ist basisdemokratisch organisiert und somit kann nicht verhindert werden, dass eine Mehrheit eine Entscheidung durchsetzt, welche die Rechte einer Minderheit (in diesem Falle diejenigen, die LiquidFeedback nur pseudonym nutzen wollen) betrifft. Auch Vorstände und Systemadministratoren könnten die Durchsetzung einer solchen Entscheidung allenfalls verzögern, aber nicht verhindern wenn die Mehrheit auf die Durchsetzung besteht. So funktioniert Demokratie nunmal. Den betroffenen Mitglieder bleibt es aber unbenommen ihre Rechte gerichtlich durchzusetzen, falls diese verletzt sind. Trotz alledem ist es aus datenschutzrechtlichen Gründen nicht möglich bestehende Pseudonyme aufzudecken. Wollte man in Liquidfeedback nur noch Klarnamen zulassen, könnte man also diejenigen die sich weigern den Klarnamen anzugeben nur aus dem System ausschließen, nicht aber deren Pseudonyme aufdecken.
Demokratie bedeutet immer auch Minderheitenschutz. Und Basisdemokratie bedeutet nicht, dass man sich über grundsätzliche Schutzprinzipien hinwegsetzt. Warum soll es ermöglicht werden, das Abstimmungsverhalten von Personen zu prüfen? In wie weit ist der "Transparenzeffekt" hier nützlicher als der mögliche Schaden? Werden Leute, die z.B. LQFB-Teilnehmer aufgrund der öffentlich einsehbaren Daten erpressen, auch irgendwo transparent aufgelistet? datenritter 21:16, 12. Jul. 2010 (CEST)
Zum einen ist es nötig sicherzustellen, dass hinter jedem Teilnehmernamen in LiquidFeedback, ob nun als Pseudonym oder als Klarnamen ein Pirat steht und es keine "Sockenpuppen" gibt, damit das Ergebnis glaubwürdig ist. Insofern muss erreicht werden, dass sich jedes Mitglied nur einen Account anlegen kann, welcher bei Parteiaustritt wieder gelöscht wird. Außerdem muss nachvollziehbar sein, wie das Abstimmungsergebniss zu stande kommt um zu vermeiden, dass das System unbemerkt verfälscht werden kann. Dies ist der Wahlcomputerproblematik sehr ähnlich. Um dies zu vermeiden, wird jedem Benutzer angezeigt welches Pseudonym bzw. welcher Klarnamen wie gestimmt hat. Die Frage, ob LiquidFeedback nur noch unter Klarnamen verwendet werden soll, betrifft vorallem die Frage, inwieweit man von den Mitgliedern das verlangen soll, was die Piratenpartei von der Politik fordert, nämlich Transparenz und das der Einzelne für seine Entscheidung die Verantwortung trägt. Bis jetzt ist nicht vorgesehen, dass Leute die LiquidFeedbackteilnehmer erpressen irgendwo aufgelistet werden. Erpressung ist eine Straftat nach § 253 StGB. Sollte jemand Opfer einer Erpressung im Zusammenhang mit LiquidFeedback werden, kann er sich jederzeit melden um Unterstützung zu erhalten. -muuhh 10:49, 15. Jul. 2010 (CEST)

Frage: Wird die API erreichbar sein?

Einige Landesverbände experimentieren derzeit mit der API und bauen mit dessen Hilfe Mailbenachrichtigungen, Twitter-Nachrichten o.Ä. Dazu muss die API geöffnet sein. Wird dies der Fall sein? Und wie sieht es aus, wenn die API um die Abfrage personenbezogener Daten erweitert wird. Wird dies dann automatisch für den Bund übernommen? Ike 14:19, 23. Jun. 2010 (CEST)

Antwort

Nach dem jetzigen Planungsstand soll die API für die teilnehmenden Piraten in der Form, wie sie jetzt von der Software unterstützt wird, verfügbar sein.

Weitere technische Informationen zur API finden Interessierte hier: http://www.public-software-group.org/liquid_feedback_frontend_api

Frage: Verlorengegangene Anmeldedaten?

Die Clearingstelle soll ja ein dazwischengeschaltetes Element sein, um die Zuordnung zur tatsächlichen Person weiter zu verschleiern. Was passiert aber, wenn man den Token, den man von der Clearingstelle erhalten hat verliert, ohne sich an LF angemeldet zu haben? Wie kann man einen neuen Token anfordern, ohne seine Identität preisgeben zu müssen?

Und was passiert, wenn man die Zugangsdaten an LF (wenn man sich dort per Token angemeldet hat) verloren hat? Ike 14:24, 23. Jun. 2010 (CEST)

Antwort

Die Vergabe der Zugangsschlüssel und die Rolle der Clearingstelle wird hier beschrieben: http://wiki.piratenpartei.de/LQPP/Betriebsdoku#Prozesse_Abgleich_Mitgliederverwaltung_und_LiquidFeedback-System 

Geht nun der Referenzschlüssel verloren, bevor sich ein Mitglied angemeldet hat, so kann dieser auch nochmals bei der Mitgliederverwaltung erfragt werden, da die Referenzschlüssel dort den Namen zugeordnet sind.

Falls jemand sein Passwort verliert, besteht die Möglichkeit, dieses zurückzusetzen.

Wenn der Anmeldenamen verloren geht, kann man von der Emailadresse mit der man den LiquidFeedback Account angelegt hat eine Mail an die Admins schicken. Die können der Adresse den Anmeldenamen (welcher ein anderer ist als das ggf. verwendete Pseudonym) zuordnen.

Falls man auch diese Emailadresse nicht mehr findet, muss der Account wie bei einem ausgetretenen Mitglied gelöscht und ein neuer erstellt werden.

Frage: Welche Daten werden exportiert?

Werden für die Zuweisung der LF-Tokens Daten aus der Mitgliederverwaltung exportiert? Und wenn ja, welche sind das? Hintergrund der Frage ist dieser Beschluss des letzten LPT in RLP (Automatisierte Datenverarbeitung in LQFB) und die Klage von Bodo Thiessen. Ike 16:34, 29. Jun. 2010 (CEST)

Antwort

Nein. Es wird lediglich jedem Mitglied innerhalb der Mitgliederverwaltung ein Referenzschlüssel zugewiesen und diesem mitgeteilt, damit es sich einen Einladungsschlüssel geben lassen kann. Eine genaue Beschreibung des Verfahrens findet sich unter LQPP/Betriebsdoku#Prozesse_Abgleich_Mitgliederverwaltung_und_LiquidFeedback-System. Zu keinem Zeitpunkt werden andere Daten aus der Mitgliederverwaltung exportiert. Simon Weiß 17:31, 29. Jun. 2010 (CEST)

Okay. Wie werden die Mitglieder über ihren Code benachrichtigt? Per Mail oder postalisch? Ike 00:32, 30. Jun. 2010 (CEST)
Per Email.--muuhh 00:44, 30. Jun. 2010 (CEST)

Frage: Sperrung/Deaktivierung von Accounts

Es ist ja möglich, Accounts bei Parteiaustritt oder Beitragsrückständen zu sperren. Was passiert mit den geperrten Accounts mit nicht abgeschlossenen Themen, in denen diese sich beteiligen? Werden Unterstützungen entzogen? Was passiert mit empfangen Delegationen? --Haibaer 10:45, 30. Jun. 2010 (CEST)

Antwort

Sobald ein Account gesperrt ist, hat er kein Stimmgewicht mehr. Auch in einer laufenden Abstimmung wird keine Stimme gewertet, auch wenn sie schon vor der Sperrung abgegeben wurde. In allen Themen, in denen die Unterstützungen nicht schon durch Erreichen der Abstimmungsphase nicht mehr änderbar sind, entfällt auch die Unterstützung und zählt nicht mehr zum Erreichen von Quoren. Ebenso werden auch ausgehende Delegationen nicht mehr wirksam. Eingehende Delegationen spielen keine Rolle mehr, da keine Abstimmung oder sonstige Beteiligung durch den gesperrten Account möglich ist. Simon Weiß 15:21, 2. Jul. 2010 (CEST)

Frage: Invitecodes in Datenbankdump?

Sind im veröffentlichten Datenbankdump die Invitecodes enthalten? Falls nicht, wie kann ein Mitglied, das sich noch nicht angemeldet hat, prüfen, dass sein Invitecode nicht unrechtmäßig verwendet wird? Und wie kann die Clearingstelle prüfen, dass nur Invitecodes verwendet werden, die aktiv sind?

Antwort

Im Datenbankdump sind keine Invitecodes enthalten, die Zuordnung zwischen Accounts und Invitecodes ist nur den Administratoren bekannt.

Um zu verhindern, dass sich nicht berechtigte Personen (insbesondere die Admins, die Clearingstelle oder der Vorstand) Accounts mit den Codes von Piraten anlegen, die sich nicht an LF beteiligen, ist ein unter LQPP/Betriebsdoku#Prozess_Teilnehmerkreisprüfung dokumentierter Prozess definiert. Wenn der Referenzschlüssel eines Mitglieds benutzt wurde, um einen Account anzulegen, wird es darüber per Mail informiert, und kann sich beim Vorstand melden, wenn es dies nicht selbst getan hat. Simon Weiß 12:05, 15. Jul. 2010 (CEST)

Nachtrag: Auf https://lqfb.piratenpartei.de gibt es gerade einen Testlauf, da kann man sich anmelden und auch mal anschauen, wie so ein Datenbankdump aussieht. Simon Weiß 12:13, 15. Jul. 2010 (CEST)

Frage: API-Key und Pseudonyme Nutzung/Nutzung des API-Keys einer anderen Person?

Über den API-Key kann ja durch die Admins grundsätzlich eine Zuordnung zum entsprechenden Useraccount durchgeführt werden - was ein Problem bei der pseudonymen Nutzung von LF darstellt. Ist es deswegen grundsätzlich möglich, einen vom Useraccount entkoppelten API-Key zu erhalten?

Oder: Darf der API-Key eines anderen Users verwendet werden, wenn dieser der Nutzung zugestimmt hat?

Antwort

Ein Problem mit der pseudonymen Nutzung entsteht durch die Zuordenbarkeit der API-Keys nicht: da die Zuordnung zum Account stattfindet, ist der Schutz vor der Zuordnung zur eigenen Person durch die Pseudonymisierung in vollem Maße gegeben.

Dies ist ein Trugschluss. Gerade wenn man einen Bot programmiert, der zu festen Zeiten die Daten abruft, (alle X Minuten) kann über die Logfiles der Schluss vom API-Key auf den User getroffen werden. Dadurch kann also das Pseudonym aufgedeckt werden. Ike 00:01, 21. Jul. 2010 (CEST)
Ich verstehe hier nicht ganz was du meinst. Wie soll über die Logfiles das Pseudonym eines Benutzers aufgedeckt werden? Die IP wird ja nicht geloggt. Und vor allem, wieso sollte dies bei Zugriffen über die API anders sein als bei solchen über das Webinterface? Simon Weiß 00:16, 21. Jul. 2010 (CEST)
Es wird gerade zu Anfang nicht viele Bots geben, die regelmäßig alle paar Minuten auf das System zugreifen. In den Logfiles wiederum wird die angeforderte URL stehen - in der der API-Key steht. Über das Wissen, wer alles Bots betreibt, kann dann ein Rückschluss auf den API-Key getroffen werden. Wenn dann bekannt ist, welche Person hinter dem API-Key steht, sehen die Admins, welches Pseudo diese Person benutzt.
Wer Wert auf die Sicherheit seiner Pseudonymität legt, sollte eben nicht unter seinem Klarnamen auftreten. Das gilt für Handlungen im System und Bezugnahmen auf die eigene Identität darin ebenso wie Zugriffe auf die API. Simon Weiß 12:44, 21. Jul. 2010 (CEST)

Die Zuordnung der Schlüssel zu Teilnehmern ist bewusst eingerichtet worden. Weder wird es davon unabhängige Schlüssel geben noch ist die Verwendung der API-Schlüssel anderer Benutzer zulässig. Simon Weiß 15:57, 20. Jul. 2010 (CEST)

Gut, dann werde ich mir noch überlegen, was ich nach Ende der Testphase unternehme. Ike

Frage: Ist es nötig, dass in den Nutzungsbedingungen ausgerechnet der Begriff Raubkopie (wenn auch nur in Anführungszeichen) verwendet wird?

In den auf vorstand.piratenpartei.de veröffentlichten Nutzungsbedingungen für Liquid Feedback steht unter dem Punkt 6.3 "Anderweitig unzulässige Inhalte":

"Inhalte, die urheber- und/oder leistungsschutzrechtlich geschützte Positionen Dritter verletzen (z.B. „Raubkopien“ von Musik, Filmen und Software zum Gegenstand haben)."

Weshalb findet dieser umstrittene Begriff ausgerechnet in einem Dokument der Piratenpartei Verwendung? Siehe auch Kritik am Wort auf Wikipedia. --MrHan 23:11, 19. Jul. 2010 (CEST)

Antwort

Nötig ist die Verwendung des Begriffs "Raubkopie" an dieser Stelle tatsächlich nicht, ich persönlich denke auch dass er hier vermieden werden sollte. Änderungen der Nutzungsbedingungen in derartigen Detailfragen sind möglich, sowohl noch vor Aufnahme des Betriebs als auch danach durch entsprechende Beschlüsse. Simon Weiß 14:37, 20. Jul. 2010 (CEST)

Fragen zu den Nutzungsbedingungen aus Mail

Die folgenden Fragen entstammen einer E-Mail an den Bundesvorstand und werden hier mit Erlaubnis des Autors wiedergegeben und beantwortet. Simon Weiß 20:07, 20. Jul. 2010 (CEST)

Frage

>3.2 Bei der Wahl deines Teilnehmernamens wie auch deines >Anmeldenamens im Rahmen des Registrierungsprozesses darfst du keine >Namen von dritten Personen angegeben.

Wie ist das gemeint. Muss ich dafür sorge tragen das den Nickname den ich dort eingebe niemand jemals irgendwo im Internet benutzt hat? Und welchen Zweck hat die Trennung Teilnehmernamen und Anmeldenamen? Was passiert wenn mein Nick zufällig schoneinmal von jemanden anders benutzt wird. Was passiert bei Mehrfach vorkommen von Namen wie z.B. Peter Müller (Beispiel mit häufigen Namenskonstelationen)

Ich schlage vor die Formulierung wie folgt zu ergänzen:

Bei der Wahl deines Teilnehmernamens wie auch deines Anmeldenamens im Rahmen des Registrierungsprozesses darfst du keine Namen von dritten Personen angegeben. die geeignet sind, deine Meinungsäußerungen mit anderen Parteimitgliedern in Verbindung zu bringen.

Antwort

Gemeint ist hier tatsächlich nur, dass keine Namen verwendet werden sollten, die den Eindruck erwecken, dass der Account einer bestimmten anderen Person zugeordnet ist. Eine Einschränkung auf Parteimitglieder ist dabei nicht unbedingt sinnvoll, zumal eine Parteimitgliedschaft ja auch nicht allgemein bekannt sein muss. Was mehrfach verwendete Namen angeht, gilt: Wer zuerst kommt, mahlt zuerst.

Frage

>3.5 Zwei grundsätzliche Einschränkungen bei der Registrierung >gibt es: Wenn ein Parteimitglied nach seiner Aufnahme in die >Piratenpartei den fälligen Mitgliedsbeitrag bereits mehr als drei >Monate schuldig geblieben ist, behalten wir es uns vor, die >Registrierung abzulehnen. Ebenso behalten wir es uns vor, die erneute >Registrierung eines einmal aus LiquidFeedback ausgeschlossenen >Parteimitglieds genau zu prüfen und gegebenenfalls auch zu verweigern.

Heißt das ich kann wenn ich einmal meinen Beitrag nicht gezahlt habe, und irgendjemanden gefällt mein Gesicht nicht, nicht mehr an einem Meinungsbildungswerkzeug der Piraten teilnehmen? Dies finde ich mehr als unpassend. Hier sollten genaue Gründe für einen ausschluss aus dem LQFB genannt werden und Rechtsmittel (BSG) eingeräumt werden.

Ich schlage einen Unterpunkt vor in dem die Ausschlusskriterien aufgelistet sind z.B. verbreitung verfassungswidriger Schriften. Die aufgelisteten Ausschlusskriterien sollten nur in grobe Kategorien unterteilt werden, um es nicht unnötig auf zu blähen. Desweiteren schlage ich vor, das eine Einspruchsmöglichkeit vor dem BSG oder einem Obmann gegen den Ausschluss ermöglicht wird.

Antwort

Selbstverständlich sollen, was die Feststellung der Stimmberechtigung und ggf. den Ausschluss aus LiquidFeedback angeht, die gleichen Regeln für alle Mitglieder gelten. Die Möglichkeit, vor dem Schiedsgericht Einspruch gegen Entscheidungen einzulegen, die als willkürlich oder ungerechtfertigt gesehen werden, besteht immer, auch wenn es hier nicht an jeder Stelle explizit erwähnt wird.

Frage

>5.1.3 Wie in Ziffer 4.2 der Datenschutzerklärung erläutert, ist es >jedem Teilnehmer zu jedem Zeitpunkt gestattet, die gesamte >LiquidFeedback-Datenbank herunterzuladen und zu speichern. Hiervon >ausgenommen sind selbstverständlich die Bestands- und Nutzungsdaten >sowie alle Daten der Teilnehmerprofile. Alle anderen Inhalte stehen >aber zum Download bereit. Um den Download auch rechtlich zu >ermöglichen, räumst du uns das Recht ein, dem downloadenden Teilnehmer >das einfache Recht zum Download und zur Speicherung auch deiner Inhalte >einzuräumen.

Dies würde eine Nutzung der Daten durch dritte auch zu kommerziellen Zwecken ermöglichen. Wie wird sichergestellt, das dies nicht geschieht? Ich halte den Download der gesamten DB für eher fragwürdig und sehe keinen direkten Sinn dahinter.

Antwort

Den Benutzern wird das Recht eingeräumt, die Datenbank herunterzuladen und zu speichern, damit jeder die Ergebnisse des Systems selbst nachvollziehen und prüfen kann. Es sind keine Daten darin enthalten, die nicht auch ohne eine solche Downloadmöglichkeit für jeden Benutzer verfügbar wären.

Dieses Recht erstreckt sich aber nicht darauf, die heruntergeladene Datenbank weiterzugeben oder zu kommerziellen Zwecken zu nutzen.

Frage

Zu 5.3.2: ich halte die CC3.0 hier für eher weniger angebracht, weil damit der Zwang einer Namensnennung auch ausserhalb von LQFB unbedingt notwendig ist. Ich schlage hier vor dem User auswählen zu lassen, welche Lizenz er für seine Inhalte möchte. Ich kann mir gut vorstellen, das es genügend nutzer gibt, die eine zusammenbringung seiner Pol. Meinung und seines Namens ausserhalb von LQFB nicht gut heißt.

Antwort

Die Wahl der Lizenz ist hier deshalb so ausgefallen, weil Beiträge im Wiki ebenfalls unter CC3.0 veröffentlicht sind und wir die Kompatibilität zwischen den beiden Systemen sicherstellen wollen. Die Pflicht der Namensnennung ist hier bereits durch einen Link auf die Seite in LiquidFeedback erfüllt.

Frage

Zu 6.1 ist es abwählbar das mir andere LQFB User Nachrichten senden können? Wie wird automatischer Spam per Macro unterbunden?

Antwort

Es ist innerhalb von LiquidFeedback nicht möglich, anderen Benutzern Nachrichten zu schicken, das Problem stellt sich also nicht.

Frage

>7.3 Wie in Ziffer 3.1 der Datenschutzerklärung erläutert >behalten wir es uns überdies vor, in solchen Fällen die Pseudonymität >der Nutzung von LiquidFeedback zu durchbrechen und deine Identität zu >erforschen und offenzulegen.

Wem gegenüber offenlegen? Parteiintern, richtig öffentlich, nur ggü. Strafverfolgungsbehörden? Ab wann wird offengelegt? Ggü. der Polizei, der Staatsanwaltschaft oder nur mit Richterlichen Beschluss?

Antwort

Eine genaue Beschreibung des Prozesses zur Auflösung der Pseudonymisierung findet sich unter LQPP/Betriebsdoku#Prozess_Auflösung_der_Pseudonymität. Dort ist auch beschrieben, unter welchen Umständen dieser Prozess stattfinden kann. Man beachte, dass er in jedem Fall einen Vorstandsbeschluss benötigt und der Vorstand sich vor den Mitgliedern der Partei verantworten muss.

Frage

>8. Unsere Haftung >Wir haften grundsätzlich nach den gesetzlichen Bestimmungen. Zwei >Einschränkungen gelten dabei aber: Sofern Schäden bei dir aus dem >Verlust von Daten resultieren, haften wir dafür nicht, soweit die >Schäden durch eine regelmäßige und vollständige Sicherung aller >relevanten Daten durch dich vermieden worden wären.

Heißt das ich bin für eine Datensicherung meiner Initiativen verantwortlich? Welche Daten muss ich sichern und welche Sichert ihr?

Antwort

Wenn dir Inhalte, die du in Liquidfeedback eingestellt hast, so wichtig sind, dass du ihren Verlust nicht in Kauf nehmen möchtest, ist es sinnvoll, sie auch außerhalb des Systems zu speichern. Dass dir durch den Verlust von Daten in LiquidFeedback Schaden entsteht, ist zugegebenermaßen unwahrscheinlich.

Frage

>9.3 Ebenso behalten wir es uns vor, den Teilnehmer-Account >zeitweilig oder dauerhaft zu sperren, wenn dem Teilnehmer, aus welchen >Gründen auch immer, zweiteilig oder dauerhaft sein ordentliches >Stimmrecht als Mitglied der Piratenpartei entzogen wurde.

Auch wenn ein Parteimitglied sein Stimmrecht verliert, kann er noch an der Willensbildung der Partei ausserhalb von Abstimmungen und Wahlen teilnehmen. Hier möchtet ihr ihn ausschließen? Das sehe ich sehr kritisch. Dieses Tool soll die Meinungsbildung innerhalb der Piraten vorranbringen. Hier sollte ein differenzierteres Sperrvorgehen durchgeführt werden.

Antwort

Wer durch Nichtzahlung von Mitgliedsbeiträgen sein Stimmrecht verliert, kann nach unserer Satzung sogar seine Mitgliedschaft verlieren, eine Sperrung des LF-Accounts ist also kaum unverhältnismäßig. Eine Aberkennung des Stimmrechts findet auch ansonsten nicht ohne guten Grund statt. Es geht hier zudem nur darum, dass man sich dieses Recht vorbehält; das schließt ein differenzierteres Vorgehen nicht aus.

Frage

>10.4 Eine Reaktivierung eines Teilnehmer-Accounts nach Kündigung >ist grundsätzlich nicht möglich.

Wie sieht das mit einem neuen Account aus? Ist dies ohne weitere Probleme möglich?

Antwort

Das Anlegen eines neuen Accounts ist in diesem Fall möglich.

Frage

>12.2 Diese Möglichkeit der Änderung der Allgemeinen >Nutzungsbedingungen besteht weder für Änderungen, die Inhalt und Umfang >der für den jeweiligen Teilnehmer bestehenden Kernnutzungsmöglichkeiten >von LiquidFeedback zum Nachteil des Teilnehmers einschränken, noch für >die Einführung von neuen, bisher nicht in den Allgemeinen >Nutzungsbedingungen angelegten Verpflichtungen für den Teilnehmer.

Diesen passus würde ich rausnehmen, es ist zwar für den User schlechter, aber euch nimmt es in zukunft Handlungsspielraum. Was ist wenn sich Gesetze so ändern das eine Änderung der Nutzungsbedinungen entgegen diesen Paragraphen notwendig ist?

Antwort

In einem solchen Fall impliziert dieser Abschnitt der Nutzungsbedingungen lediglich, dass die Zustimmung zu neuen Nutzungsbedingungen explizit gegeben werden muss und nicht durch die im vorherigen Abschnitt beschriebenen Widerspruchsregelung erfolgen kann.

Frage

In der Datenschutzerklärung (die ich zugegebener Maßen nur überflogen habe) ist in "2.1.2 Schlüsselerstellung und Verwaltung" die Schlüsselerstellung geregelt. Die findet doch allerdings bereits vor dem Einverständnis statt, ist es trotzdem Sinnvoll dies in der DSE zu Regeln die ich danach akzeptieren muss?

Antwort

Dieser Teil der Datenschutzerklärung dient nur der Erklärung der Funktionsweise des Systems. Die Erstellung und der Versand der Schlüssel bedürfen keiner eigenen Einwilligung.

Frage: Kann man Ziffer eindeutig machen?

Wir haben schon in den 3 Abschnitten der Bundessatzung das Problem, dass alle Paragraphen mit der Nummer 1 beginnen. Wäre es nicht möglich den Datenschutz- und Nutzungsbedingen eigenständige Nummernkreise zu geben (dies macht Verweise auf Ziffern eindeutiger und erspart die (nicht an allen Stellen vorhandene) Angabe auf welches Dokument sich die Ziffer bezieht. --eckes

Antwort

Das wäre theoretisch möglich, es handelt sich aber um zwei verschiedene Dokumente. Simon Weiß 12:41, 21. Jul. 2010 (CEST)

Frage: Könnte man eindeutige Kennzeichnung regelmaessig ändern?

Wenn schon Details zu Abstimmunsgergebnisse ewig gespeichert werden sollen (warum?) dann sollte wenigstens die eindeutige ID die alle Aktionen verknüpft nicht ewig beibehalten werden. Alle X Monate (z.b. jedes Jahr) sollten für jeden Account neue IDs vereben werden, eine Verknüpfung der Namenshistorie soll über diesen Wechsel nur auf Wunsch des Teilnehmers möglich sein (nur in dem Fall unter Mitnahme der Delegationen).

Begründung: wenn man LF nutzen möchte muss man sich auch ein Stück weit zu erkennen geben. Mitglieder die den Realnamen verwenden sind durch die dauerhafte Speicherung gegenüber "vollanonymen" Mitgliedern benachteiligt (obwohl sie wesentlich "wertvoller" mitarbeiten können). Wenn die IDs die alle Aktionen verknüpfen öfters gewechselt werden, so kann jeder nach einer gewissen zeit "neu" anfangen. Die Clearingstelle kann natürlich (falls gewünscht) alle Inkarnationen der IDs speichern - aber am besten wäre es generell die Datenhaltung nicht endlos zu betreiben. Abstimmungen sind nicht endlos anfechtbar, LF muss dies auch nicht unterstützen. --eckes

Antwort

Die dauerhafte Speicherung findet einerseits zur Sicherung der Nachvollziehbarkeit und Schtz vor Manipulationen statt, andererseits aus Gründen der Transparenz um die Grundlagen von Entscheidungsprozesse auch in Zukunft noch erkennbar zu machen. Eine eventuelle Löschung wäre zudem auch nicht wirksam.

Der Wechsel der ID eines Benutzeraccounts (sofern damit die eindeutige ID und nicht der Benutzername gemeint ist) ist technisch nicht möglich, weil dann Einträge in der Datenbank einer nicht mehr existierenden ID zugeordnet wären, die Datenbank wäre also nicht mehr konsistent. Allerdings ist es natürlich prinzipiell problemlos möglich, einen Benutzeraccount zu sperren und seinem Besitzer einen neuen Referenzschlüssel zuzuordnen, mit dem er einen neuen Account anlegen kann. Dieser Vorgang ist zumindest für den Fall vorgesehen, dass das Pseudonym eines Benutzers gegen seinen Willen aufgelöst wird. Man könnte diskutieren, dies auch auf Wunsch oder zumindest in begründeten Einzelfällen zuzulassen; eine regelmäßige Sperrung und Neuerstellung aller Benutzeraccounts ist aber nicht sinnvoll. Simon Weiß 13:01, 21. Jul. 2010 (CEST)

Frage: Inwieweit sind die Nutzungsbedingen jetzt extern untersucht worden?

Ich habe bisher nur 2 Gespräche mit der Kanzlei JBB im Vorstandsprotokoll finden können. Welche Ergebnisse hatten die Gespräche und sind weitere geplant? Insbesondere haben die Anwälte nur Fragen beantwortet (Welche?) oder auch den kompletten Text geprüft? Wie ist das mit dem Punkt 4.3 - haben die Anwälte bestätigt dass unser Ansrpruch auf "ewige Nachvollziehbarkeit" eine begründete Ausnahme von der Löschmöglichkeit ist? Wird es noch einen Review der aktuellen Fassung geben? --eckes

Antwort

JBB hat den Text der Nutzungsbedingungen und der Datenschutzerklärung nicht nur nachträglich geprüft, sondern in seiner ersten Version verfasst. Danach wurden von seiten der Piratenpartei allerdings noch einige Anpassungen vorgenommen. Punkt 4.3 wäre kaum in dieser Form in die Datenschutzerklärung aufgenommen werden, wenn ernsthafte Zweifel an seiner rechtlichen Zulässigkeit bestanden hätten. Eine weitere Besprechung mit JBB (wie sie z.B. bei einer weitergehenden inhaltlichen Änderung der jetzigen Texte stattfinden müsste) würde zusätzliche Ausgaben erfordern. Simon Weiß 14:42, 21. Jul. 2010 (CEST)

Frage: Informationsquellen von JBB

Aus welchen Quellen hat JBB seine Informationen über die Funktionsweise und die Anforderungen des Liquid-Feedback-Systems erhalten? Stützen die sich ausschließlich auf die Gespräche mit Christopher Lauer oder haben sie andere Erkenntnisquellen herangezogen? --02:13, 21. Jul. 2010 (CEST)

Antwort

Es fanden mehrere Gespräche mit JBB statt, an denen von Seite der Piraten nicht nur Christopher Lauer sondern unter anderem auch die Entwickler von LiquidFeedback teilgenommen haben. Simon Weiß 14:48, 21. Jul. 2010 (CEST)

Frage: Linkhaftung?

Laut Nutzungsbedingungen hafte ich für den Inhalt verlinkter Seiten. Wie soll ich denn verhindern dass auf einer Seite die ich jetzt verlinke in ein paar Jahren illegale Inhalte auftauchen? Wollt ihr mich wirklich dafür haftbar machen? Ich empfehle dringend eine Überarbeitung dieses Paragraphen. --- Acamir 14:27, 21. Jul. 2010 (CEST)

Antwort

Du haftest nach Ziffer 7.2 grundsätzlich selbst für alle von dir eingestellten Inhalte. Die Alternative dazu wäre eine Haftung durch die Partei, das wiederum wäre wohl nur bei einer genauen Prüfung all dieser Inhalte vertretbar.

Das bedeutet allerdings weder, dass du in einem Fall wie dem von dir beschriebenen auf keinerlei Unterstützung der Piratenpartei hoffen könntest, noch dass die Piratenpartei in einem solchen Fall selbst gegen dich vorgehen würde. Simon Weiß 15:49, 21. Jul. 2010 (CEST)

Frage: Schulze-Methode/Ja-Nein-Enthaltung?

Angeblich wird in LF die 12pxSchulze-Methode verwendet. Als Condorcet-Verfahren ist sie jedoch als Ranking-Wahl konzipiert, das heißt es gibt keine Zustimmung, sondern nur eine Reihenfolge. Wie wurde die Verknüpfung der Schulze-Methode mit der Zustimmung/Ablehnung/Enthaltung umgesetzt und sind sich die Benutzer/Entwickler den Konsequenzen bewusst (zB im Bezug auf taktisches Wählen, das laut Hilfe-Text nicht möglich sein sollte).

Antwort

In der Abstimmung werden zusätzlich zur Reihenfolge auch Zustimmung, Enthaltung bzw. Ablehnung angegeben, was z.B. so aussieht:

  • 1. Präferenz A (Zustimmung)
  • 2. Präferenz B (Zustimmung)
  • 3. Präferenz C (Zustimmung)
  • 4. Präferenz D (Enthaltung)
  • 5. Präferenz E (Ablehnung)
  • 6. Präferenz F (Ablehnung)

Das Ranking durch die Schulze-Methode findet dann nur noch unter denjenigen Alternativen statt, die mehrheitliche Zustimmung haben. Die Frage, ob dieses Vorgehen den relativen Schutz vor taktischem Wählen, den man durch die Schulze-Methode hat, erhält, ist diskutiert worden und kann wohl im Wesentlichen mit ja beantwortet werden. Simon Weiß 16:21, 10. Aug. 2010 (CEST)

Eine Option wäre eine synthentische enthaltung einzuführen, das Ranking normal durchzuführen und eine Ablehnung zu konstantieren wenn keine Alternative besser als die Enthaltung war. --eckes

Fragen von Justus

Frage: Wie kann das System bei einem Public Denial Angriff trotzdem nachvollziehbar sein?

Der Public Denial Angriff ist ein Szenario in dem nicht entschieden werden kann ob eine Manipulation von Server- oder von Nutzerseite vorliegt. Dabei tritt eine Gruppe von Personen, deren erklärtes Ziel die radikale Veränderung von LiquidFeedback ist, und beschwert sich über Manipulationen an ihrer Stimmabgabe. Es ist jetzt für einen Dritten (und auch für einen vertrauenswürdigen Administrator) unmöglich zu sagen, ob die Gruppe a) eine tatsächliche unentdeckte Manipulation berechtigt kritisiert oder b) eine Manipulation erfunden hat um LiquidFeedback zu diskreditieren. Da a) und b) nicht voneinander unterscheidbar sind ist die nachvollziehbarkeit des Vorgangs und damit des Systems ausgeschlossen.

Antwort

Zunächst sollte festgehalten werden, dass eine Reihe von technischen Maßnahmen existiert, die dafür sorgen, dass eine solche Manipulation durch die Administratoren nicht ohne weiteres unerkannt durchgeführt werden kann:

Jede Eingabe in die Kommandozeile wird geloggt und sowohl auf dem Server als auch extern bei der Bundes-IT gespeichert. Der Server ist so konfiguriert, dass keiner der zugriffsberechtigten Administratoren eine Shell als ein anderer Benutzer öffnen kann. Alle entsprechenden Befehle müssen mit sudo ausgeführt werden und werden auch noch einmal separat geloggt. Datenbankabfragen und -eingriffe werden ebenfalls geloggt und extern gespeichert (bei datenschutzrelevanten Abfragen in verschlüsselter Form, so dass nur die Administratoren und der Bundesvorstand gemeinsam eine Entschlüsselung durchführen können). Alle Änderungen der Datenbank werden dabei nicht über die SQL-Konsole, sondern über ein Skript ausgeführt. Verschlüsselte Backups der Datenbank werden außerdem mit höherer Frequenz als die Datenbankdumps angelegt und extern gespeichert, so dass sich eventuelle Manipulationen zeitlich eingrenzen lassen.

Trotzdem kann man natürlich nicht prinzipiell ausschließen, dass die Administratoren eine Manipulation der Datenbank vornehmen, die durch diese Maßnahmen nicht aufgedeckt wird. Mit einer Manipulation, wie sie hier beschrieben ist, also eine Änderung von Stimmen im Vertrauen darauf, dass diese Änderungen als Vortäuschen einer Manipulation von Außen wahrgenommen werden, ist aus dem Grund nicht zu rechnen, dass sie denjenigen, die sie durchführen, letztendlich keinerlei Vorteil gibt, sie aber gleichzeitig einem enormen Risiko aussetzt.

Selbst wenn nämlich ein Administrator ein Ergebnis auf diese Art manipulieren würde, und selbst wenn es ihm gelingt, den Verdacht völlig von sich abzulenken, wäre nichts gewonnen. Wenn ein Teilnehmer äußert, seine Stimme wäre X und nicht Y gewesen, kann unklar sein, ob eine Manipulation tatsächlich stattgefunden hat oder nicht; nicht unklar ist aber, dass der Teilnehmer seine Stimme als X gewertet wissen möchte. Da in LiquidFeedback keine unmittelbar verbindlichen Entscheidungen getroffen werden, sondern nur Meinungsbilder als Grundlage dafür entstehen, ist es problemlos möglich, eine korrigierte Version des Ergebnisses als gültig zu betrachten.

Es dürfte auch kaum möglich sein, eine solche Manipulation mehr als einmal durchzuführen. Falls Teilnehmer wiederholt aussagen, dass ihre Stimme manipuliert wurde, sind eine ganze Reihe von Maßnahmen denkbar, um dies auszuschließen oder die Manipulation aufzudecken (zusätzliche technische Überprüfungen, Austausch von Administratoren, Hinterlegen von Stimmzetteln).

Im Verhältnis zum nicht vorhandenen Nutzen ist das Risiko der Aufdeckung einer solchen Manipulation enorm. Es ist richtig, dass zwischen den beiden Szenarien einer Manipulation und eines gezielten Angriffs durch Vortäuschung einer Manipulation zunächst einmal nicht anhand der Daten im System unterschieden werden kann. Das bedeutet nicht, dass ein Nachweis nicht anderweitig möglich ist. Selbst wenn keines der beiden Szenarien ausgeschlossen werden kann, dürfte der damit potentiell einhergehende Vertrauensverlust kaum im Interesse der Administratoren sein; in solch einem Fall ist es z.B. durchaus denkbar, dass sie auch ohne Nachweis einer Schuld ihrer Beauftragung enthoben werden.

Frage: Wie werden stochastische Angriffe auf Basis des Public Denial Angriffs verhindert?

Stochastische Angriffe bauen auf der Wahrscheinlichkeit einer Kontrolle durch den Benutzer auf. Wenn der Benutzer mit dem Ergebnis nicht auch gleichzeitig die Abstimmdetails erhält, lässt sich vom Server aus ermitteln wer die Ergebnisse nachprüft. Auf Basis dieser Daten lässt sich dann eine Wahrscheinlichkeit konstruieren mit der man über einen bestimmten Zeitraum von einigen Tagen bis Wochen ständig die Anzahl an Manipulationen erhöht. Unter Zuhilfename des Public Denial Angriffs lassen sich absolute Mehrheiten von Stimmen manipulieren ohne, dass eine Entdeckung durch die Transparenz des Systems möglich ist.

Antwort

Zu den technischen Maßnahmen zur Verhinderung einer solchen Manipulation siehe oben. Ansonsten gilt: Nachvollziehbarkeit ist dann gewährleistet, wenn das Ergebnis nachvollzogen werden kann; das bedeutet nicht zwingend, dass es auch an jeder Stelle nachvollzogen wird. Natürlich sind Manipulationen denkbar, die dort durchgeführt werden, wo dies nicht passiert; der Sinn von Nachvollziehbarkeit ist es immer, ein so hohes Entdeckungsrisiko zu gewährleisten, dass die Manipulation sich nicht lohnt.

Das ist aber auch bei einer stochastischen Analyse, wie sie hier beschrieben wird, noch der Fall. Zunächst kann man auch mit einer solchen Analyse das Verhalten von Menschen in der Vergangenheit nicht mit hinreichender Sicherheit benutzen, um ihr zukünftiges Verhalten vorherzusagen; bei einem Versuch, eine solche Manipulation über eine längere Zeit aufrechtzuerhalten, würde die Wahrscheinlichkeit, entdeckt zu werden, auf Dauer gegen eins gehen. Zudem könnte bei einer Erfassung, welche Benutzer ihre Stimmabgaben prüfen, nicht berücksichtigt werden, dass durch die Offenheit der Abstimmung bei LiquidFeedback auch eine gegenseitige Kontrolle möglich ist und stattfindet.

Sobald aber ein solcher Manipulationsversuch auffliegt, befindet man sich wieder im Fall der ersten Frage.

Frage: Wie wird sichergestellt, dass kein Admingeheimwissen durch Systemmanipulation entsteht?

Antwort

In dieser allgemeinen Form lässt sich die Frage nur durch einen erneuten Verweis auf die bereits in der Antwort auf die erste Frage erläuterten technischen Maßnahmen beantworten.

Prinzipiell wird Admingeheimwissen dadurch verhindert, dass auf der einen Seite so wenig Daten wie möglich erhoben werden und auf der anderen Seite so viele erhobene Daten wie möglich öffentlich gemacht werden, soweit es der Datenschutz erlaubt.

Frage: Was sind die Ziele der LQFB-Verantwortlichen?

Um die Gefahr einer suggestiven Frage abzuwenden bitte ich hier auch explizit darum im Falle der nichtexistenz derartiger Ziele ausdrücklich darauf hinzuweisen, dass es sie nicht gibt. -Justus 14:02, 25. Aug. 2010 (CEST)

Antwort

Unser Ziel ist es, für die Piratenpartei Deutschland eine möglichst gut funktionierende Instanz von LiquidFeedback zu betreiben, in der unter möglichst hoher Beteiligung der Parteimitglieder Meinungsbilder entstehen können, die dem Vorstand und anderen Parteiorganen als Orientierungshilfe bei Entscheidungen dienen können und in der Anträge für Parteitage vorbereitet werden können. Was die damit verbundenen weitergehenden Ziele anbelangt, kann man gut aus der Begründung des Antrags Z013 zitieren, der auf dem letzten Bundesparteitag mit 80% Mehrheit angenommen wurde:

"Um weiterhin basisdemokratisch Entscheidungen treffen zu können, benötigen wir eine Alternativlösung zu den bisher bei Parteien üblichen Vertreterversammlungen. Ziel ist es, dauerhaft auf ein Delegiertensystem zur Entscheidungsfindung innerhalb der Partei zu verzichten. Die Einführung von LiquidFeedback für qualifizierte Meinungsbilder der gesamten Basis soll den ersten Schritt darstellen, die Idee der Basisdemokratie in der Piratenpartei zu erhalten und eine "Vergrünung" zu verhindern."

Darüber hinaus verbindet sich mit dem gesamten Projekt der Basisdemokratie in der Piratenpartei natürlich die Hoffnung, ein Vorbild auch für andere Parteien und sonstigen politischen Einrichtungen sein zu können. Simon Weiß 15:14, 15. Sep. 2010 (CEST)

Frage: Deine Frage hier kurz?

Antwort