BE Diskussion:Liquid Democracy — Anforderungen, Betrieb und Sicherheitsrichtlinien

Zur Diskussion der vorgeschlagenen Satzungsänderungen siehe auch Diskussionsseite zu Satzungsänderungsvorschlägen.

Falscher Zeitpunkt

Ich halte es für fatal, zu diesem Zeipunkt überhaupt Regeln und Satzungsvorschläge für Liquid Democracy festzulegen. Der Einführungsprozess von Liquid Democracy in der Piratenpartei sollte durch empirische Erfahrungen mit unterschiedlichen Implementationen geprägt sein und nicht aus irgendwelchen abstrakten Ideen entstehen. Die so gefassten Regeln sind auf jeden Fall verdammt dazu, fehlerhaft zu sein und basieren auf zu provisorischen Vorstellungen davon, was LD überhaupt sein und leisten kann. --Pudo 01:10, 4. Nov. 2009 (CET)

Die Regeln sind bewusst sehr knapp gehalten, um das klassische Problem der Fehler am Reißbrett zu vermeiden. Vielleicht wird man sogar noch Regelungen streichen müssen. Natürlich kann es sehr gut sein, dass sich bestimmte Minimalregelungen dennoch als unpraktisch herausstellen; dann wird man einen Änderungsbeschluss brauchen. --Jbe 13:27, 4. Nov. 2009 (CET)

Das Bestreben, LD von Anfang an bürokratisch zu verankern entspringt vermutlich aus der Idee, dass ein unkontrollierter Testbetrieb keinerlei Verbindlichkeit entfalten könnte. Diese Idee ist falsch, denn eine Wirkung auch von Test-LDs entsteht ja schon durch die Teilnahme vieler Piraten, nicht erst durch die Nennung in irgendeiner Satzung. Gleichzeitig geht man so nicht das Risiko ein, bei einer gescheiterten Einführung mit eigenartigen LD-Fragmenten in der Satzung sitzen zu bleiben.

Selbstverständlich gelten die aufgestellten Regeln nur für ein Liquid Democracy System, welches die Stellung eines Parteiorganes erlangt. Niemandem ist es untersagt in Squads oder anderen Arbeitsgruppen irgendwelche Tools zu verwenden. Eine schnellstmögliche Verankerung von Liquid Democracy halte ich deshalb für wichtig, da wir bezüglich unserer Entscheidungen basisdemokratisch bleiben wollen. Bei einem anhaltenden Wachstum der Mitgliederzahlen dürfte sich das ohne Liquid Democracy schon in sehr kurzer Zeit als äußerst schwierig herausstellen. --Jbe 13:27, 4. Nov. 2009 (CET)

Wir brauchen dringend LD, also kaufen wir uns jetzt in LD ein auch wenn es LD noch nicht gibt und wie die Implikationen nicht kennen? Finde ich keine Argumentation. Das ist irgendwie wie ein Auto zu kaufen weil einem die Farben im Prospekt besonders gefallen. --Pudo 13:36, 4. Nov. 2009 (CET)

Ohne Zweifel ist die schnelle und vernünftige Implementation einer Software notwendig, damit Satzungsänderungen überhaupt Sinn machen. Ich sehe aber nicht, warum man nicht an beidem gleichzeitig arbeiten kann. --Jbe 14:34, 4. Nov. 2009 (CET)

Ich möchte auf den einstimmigen Vorstandsbeschluss vom 20. September 2009 des Berliner Landesvorstandes hinweisen: "Der Vorstand möge das LD Squad beauftragen, die Einführung und einen Pilotbetrieb des Liquid Democracy Systems vorzubereiten und die für einen verbindlichen Einsatz notwendigen Satzungsänderungen auszuarbeiten." --Jbe 12:49, 5. Nov. 2009 (CET)

Siehe auch: Protokoll des LD-Squad vom 11. Nov. 2009

Gleiche Wahl

Wie kann man von gleicher Wahl sprechen, wenn durch Stimmdelegationen offensichtlich ein ungleiches Stimmgewicht einzelner Teilnehmer zustande kommt? Man braucht ziemlich viel Phantasie um auf eine Konstruktion zu kommen, in der Delegated Voting einer "gleiche Wahl" entspricht. --Pudo 01:10, 4. Nov. 2009 (CET)

Ich denke man kann durchaus von gleicher Wahl sprechen: Es hängt ja nicht davon ab, wieviel Gewicht die Abstimmung eines einzelnen hat, sondern vielmehr davon, dass alle mit den gleichen Chancen im System arbeiten. Jeder darf, wenn er will, abstimmen, mit seiner einen Stimme. Delegated Voting bedeutet in diesem Falle nur, dass ich mich zum einen der Meinung des Delegaten anschließe und zum anderen meine Stimme automatisch angelehnt an sein Abstimmungsverhalten abgebe. Ich habe zu jeder Zeit die Möglichkeit die Entscheidung, dies zu widerrufen und somit immer Kontrolle über meine Stimme. (Will sagen: Es ist ja nicht wie 1920 - weil ich angesehener Fabrikbesitzer bin, habe ich mehr Stimmen als meine Mitarbeiter) --HDready 01:32, 4. Nov. 2009 (CET)

Point taken, irgendwie schwammig aber vermutlich hast Du Recht --Pudo 01:53, 4. Nov. 2009 (CET)

Es ist davon die Rede, dass jeder grundsätzlich gleich viele Stimmen hat, die Übertragung von Stimmgewicht jedoch möglich sein kann. Was gemeint ist, sollte also klar sein. Vielleicht passt die Bezeichnung "gleiche Wahl" nicht ganz, weil zur Zeit der Begriffsschöpfung vermutlich niemand an Liquid Democracy gedacht hat ;-) Jbe 14:08, 4. Nov. 2009 (CET)

Da es bei Liquid Democracy um Abstimmungen (zu Themen) und nicht um Wahlen (von Personen) geht, sollte man die Begriffe "Allgemeine Wahl" und "Gleiche Wahl" vielleicht einfach streichen, den dahinterstehenden Text jedoch behalten. --Jbe 15:44, 8. Nov. 2009 (CET)

Eigentlich sollte noch explizit erwähnt werden, dass NUR Piraten abstimmberechtigt sind. --Jbe 14:35, 16. Dez. 2009 (CET)

Veröffentlichung von Abstimmungergebnissen

Der Abschnitt ist undeutlich. Es wird nicht klar, wann bei terminierten Wahlen wie welche Daten bekannt gegeben werden. Ich würde raten:

Nach erfolgter Abstimmung
i.d.R. sofort, maximal nach 23 (WTF?!?) Wochen
als vollständige Angabe, also inklusive Entscheidung, Name/Pseudonym und Delegation

So richtig? Wenn ja: Was soll das bewirken? Ich komme irgendwie auf kein sinnvolles Bot-Verhalten, das hier schädlich wäre...

Das einzige für mich vorstellbare Ziel ist, eine gegenseitige Beeinflussung der Abstimmenden zu verhindern. Warum muss diese Beeinflussung aber verhindert werden? Könnte sie nicht ein konstruktiver Teil der Auseinandersetzung sein? Gegen die massenhafte Mobilisierung von Wählern für eine Position spricht übrigens ebenfalls nichts, man nennt das "Wahlkampf" ;-)

Die Forderung nach einer geheimen Abstimmung macht allerdings gleichzeitig eine Diskussion des Delegationssystems notwendig:

Darf ich nicht wissen, was mein Delegat gewählt hat?
Darf ich nicht wissen, ob mein Delegat gewählt hat?
Müssen die Delegationsdaten (i.e. der Graph) permanent geheim gehalten werden? Schließlich entsprechen meine Delegationen an einen bekannten Vertreter einer bestimmten Position einer Stimme für diese Position?
Kann ich die Stimme meines Delegaten überschreiben?
Müssen durch Delegation entstandene Stimmen in randomisierten, zeitlichen Intervallen abgegeben werden um eine Zuordnung zum Delegaten zu vermeiden?

Diese Punkte sind nicht alle essentiell, aber die Machbarkeit der vorliegenden Regeln sollte irgendwie dargestellt werden --Pudo 01:10, 4. Nov. 2009 (CET)

Habe nochmal zwei Formulierungen geändert, so dass die Absicht deutlicher werden sollte. In Bezug auf die Delegationen gibt es bei einer Geheimhaltung während der Abstimmung in der Tat ein Problem: Entweder weiss ich erst hinterher, wie mein Delegierter abstimmt, oder ich kann mittels Delegation die Geheimhaltung umgehen. LiquidFeedback z.B. gibt (in der aktuellen Version) erst nach Abschluss der Wahl bekannt, wie Mitglieder (incl. eigener Delegierter) abgestimmt haben, um die Wahlintegrität zu gewährleisten (vgl. Geheimhaltung von Exit-Polls). Dies ist meiner Meinung nach auch nicht schlimm, da wenn ich mich mit den Wahloptionen einer konkreten Wahl beschäftigen will, ich ja auch einfach selbst abstimmen kann. --Jbe 14:03, 4. Nov. 2009 (CET)

(Wie) betrifft diese Regelung eigentlich nicht-terminierte Abstimmungen? Ein wesentliches (mir immernoch fremdes) Argument für ein Verbot zur Veröffentlichung von Zwischenergebnissen ist ja die Gefahr, dass Wähler zu einem taktischen Stimmwechsel veranlasst werden, wenn sich ein bestimmtes Wahlergebnis abzeichnet. Bei einer permanenten und durch den Einzelnen jederzeit wiederholbaren Abstimmung trifft dies jedoch nicht zu: es gibt kein "kurz vor der Deadline" und der Informationgewinn einer "halben Abstimmung" steht auch denen zur Verfügung, die bereits vprher ihre Stimme abgegeben haben und ihre Position nun eventuell ändern möchten... --Pudo 15:16, 4. Nov. 2009 (CET)

Nicht-terminierte Abstimmungen sind von der Regel nicht betroffen. Siehe Anmerkungen: "Die Formulierung 'noch laufender verbindlicher Abstimmungen mit einem feststehenden Endzeitpunkt' wurde unter anderem gewählt, um dynamische Abstimmungsmodelle (wie z.B. derzeit von Adhocracy implementiert) nicht von vornherein auszuschließen." --Jbe 15:29, 4. Nov. 2009 (CET)

Ui, mein Fehler! Werde zunehmend zum Fan dieses Vorschlags :-) (Ja, das ist möglich, auch wenn ich hier dauernd Steine werfe; es sind schließlich gut gemeinte Steine) --Pudo 15:31, 4. Nov. 2009 (CET)

Das Verbot der Veröffentlichung von Zwischenergebnissen bei Abstimmungen mit feststehendem Endzeitpunkt hat die gleiche Begründung wie das z.B. das Verbot der Veröffentlichung von Exit-Polls bei der Bundestagswahl. --Jbe 15:36, 4. Nov. 2009 (CET)

Im Liquid Democracy Squad wurde der Passus noch weiter entschärft. Es heißt jetzt: "Abstimmungsdaten noch laufender verbindlicher Abstimmungen [...] können hiervon bis zum Abschluss der Abstimmung [...] ausgenommen werden [...]." --Jbe 23:44, 11. Nov. 2009 (CET)

Moderation

Den Text finde ich hochideologisch und den Versuch die Moderation einer so komplexen Software in 4 Sätzen abzuhandeln nicht ausreichend. Wie wäre es, am laufenden System herauszufinden welche Mechanismen benötigt werden? Außerdem würde ich auf die unangemessene Verwendung des juristischen Terms "Zensur" verzichten. Alternativ kann man natürlich an dieser Stelle Drittwirkung diskutieren aber irgendwas sagt mir, dass es hier darum nicht wirklich ging ;-) --Pudo 01:10, 4. Nov. 2009 (CET)

Mir war das mit der Zensur gar nicht aufgefallen. Aber ja, Mechanismen findet man im laufenden Betrieb. Wie ist es beispielsweise mit der gemeinsamen Arbeit an einem Vorschlag zu einem Problem, wenn niemand editieren darf? Schicken wir uns dann nebenbei Mails "editier mal das so um"? Viel interessanter ist hier doch, wie bei einem Wiki History & Benachrichtigung als mögliche Tools zu haben, und jeder darf editieren, solang noch nicht abgestimmt wird. So kann ich jederzeit den Urzustand wiederherstellen, aber habe dennoch die Möglichkeit, konstruktive und vor allem notwenige Änderungen von anderen zuzulassen. Das nimmt auch eine Menge Arbeit von den Admins, da jeder Initiator eines Vorschlags zum Wächter dessen wird und so enger in die LD eingebunden wird - auch in die administrative Seite des Tools. --HDready 01:44, 4. Nov. 2009 (CET)

Ich sehe keinen Grund, warum irgendwer eingestellte Daten löschen können sollte. Eine Sortierung nach Bewertungen und/oder Filterung nach Benutzerwunsch ist ja nicht ausgeschlossen. --Jbe 14:15, 4. Nov. 2009 (CET)

Ja, Löschen ist in der Tat eines der langeweiligeren Szenarios, aber es sollte Teil eines umfassenderen Moderationsframeworks sein. Spannender sind solche Fragen: Wer entscheidet, wann über was Abgestimmt wird? Unter welchen Bedingungen können Abstimmungen abgebrochen werden? Wer kann einzelne Beiträge verändern? Wer legt die Struktur der Inhalte fest, an der sich anschließend die themenbezogenen Delegationen festmachen? Welche Anträge schließen sich gegenseitig aus, welche können als komplementär abgestimmt werden? Die habt ihr im Entwurf hier ausgelassen; das finde ich gut; aber ich würde Löschungen in den Kontext irgendwie einordenen.... Dunno wie. --Pudo 15:21, 4. Nov. 2009 (CET)

Unter "Moderation" verstehe, ich, dass es einen Moderator gibt, der entscheidet, was gelöscht wird, und über was abgestimmt wird. Es spricht nichts dagegen, dass wenn sich demokratisch eine Mehrheit von Mitgliedern dazu ausspricht einen Antrag von einer Abstimmung auszuschließen, man diesen Antrag aus der Liste der abzustimmenden Anträge streicht. Das heisst aber NICHT, dass dies ein "Moderator" oder ein "Moderatorenteam" machen muss, und es heisst ebensowenig, dass man deshalb einen Antrag gänzlich aus dem System löschen muss! --Jbe 15:43, 4. Nov. 2009 (CET)

Ne, darum ging es mir nicht zwangsläufig - ob das ein Team von Mods, eine Metabstimmung o.ä. ist würde ich auch vollkommen offen lassen wollen - die grundsätzliche Funktion einer Diskurssteuerung muss nur irgendwie erfüllt werden. Mit welchem Begriff würdest Du denn diese Funktionen zusammenfassen? --Pudo 15:46, 4. Nov. 2009 (CET)

Ich würde diese Frage eben NICHT offenlassen wollen, da es meiner Meinung nach kein Team von Leuten geben darf, die darüber entscheiden über welche Anträge abgestimmt wird, und welche Anträge keine "Relevanz" haben (vgl. Wikipedia). Ich bin der Meinung, dass die Formulierung "darüber hinaus findet jegliche Form von Zensur ausdrücklich nicht statt" soetwas wie Metaabstimmungen keinesfalls ausschließt. --Jbe 15:56, 4. Nov. 2009 (CET)

Ich glaube ich verstehe Deine Sorgen, die Frage ist nur ob so ein idealer Ablauf des Systems gewährleistet wird. Die beiden anderen Alternativen die ich sehe sind: alle dürfen einzeln alles (Extrem-Wiki) oder nur alle zusammen dürfen irgendwas (Metametametabstimmungen). Beide Ansätze haben basisdemokratischen Charme, und stellen sicher für einzelne Probleme gute Ansätze dar. Dennoch haben beide Schwachstellen, führen sie doch in der Praxis vermutlich entweder zu zuviel oder zu wenig Aktivität im System. Ich bin großer Fan offener ("alle dürfen alles") und selbst-sortierender Systeme, die mit "zu viel Noise" umgehen sollen - halte es allerdings für unpragmatisch hier von vorne herein eine Inklusionisten-Ideologie einzubauen; da man so einem Scheitern offener Mechanismen nicht pragmatisch begegnen kann. --Pudo 16:12, 4. Nov. 2009 (CET)

Scheitert der Ansatz, dass man einflussnehmende Antragskommissionen oder Moderatoren nicht weitestgehend loswerden kann, dann würde ich Liquid Democracy insgesamt als gescheitert betrachten. Wir sollten nicht aus dem Auge verlieren, warum wir überhaupt Liquid Democracy einführen wollen. --Jbe 16:17, 4. Nov. 2009 (CET)

Noch eine Anmerkung zu Wikipedia: Wikipedia ist eine Enzyklopädie, und keine Demokratieplattform! Bei Liquid Democracy ~~sollten~~ müssen wir höhere demokratische Ansprüche haben, als dies derzeit z.B. bei der Wikipedia der Fall ist. --Jbe 16:37, 4. Nov. 2009 (CET)

Wenn "Demokratie" (d.h. Gleichberechtigung aller am politischen Prozess, ohne Informationsunterdrückung) eine "Ideologie" sein soll, dann lasse ich mich gerne als ideologisch bezeichnen ;-) --Jbe 02:18, 5. Nov. 2009 (CET)

Irgendwie schon. Nicht, dass ich mir nicht auch eine demokratische Plattform wünsche. Das wäre toll. Ich suche nur bisher vergeblich nach einem Beispiel für eine Web-Community auf die das auch tatsächlich zutreffen würde. (Das beste was mir bisher eingefallen ist ist Debian, aber das ist ein schiefer Vergleich). Ich glaube, dass Demokratie auch da stattfindet, wo nach transparenten Regeln moderiert wird. Die Demokratie soll in der Entscheidungsfindung stattfinden und sie auf die Diskussion auszudehnen ist wünschenswert aber keine conditio sine qua non. Welche Formen von Moderationsbedarf es aber tatsächlich gibt; und ob denen mit rein demokratischen Werkzeugen beigekommen werden kann ist aber grade vollkommene Spekulation. Würdest Du denn aber zustimmen, dass eine vollkommen demokratisch verwaltete (und nicht zumindest meritokratisch moderierte) Seite absolutes Neuland ist? --Pudo 00:55, 6. Nov. 2009 (CET)

Habe gerade nochmal Absatz 3 des §15 im Parteiengesetz gelesen: "Das Antragsrecht ist so zu gestalten, daß eine demokratische Willensbildung gewährleistet bleibt, insbesondere auch Minderheiten ihre Vorschläge ausreichend zur Erörterung bringen können." Auch wenn der Paragraph wohl nur auf "Organe" anzuwenden ist, und man sich vermutlich darüber streiten kann, ob "Liquid Democracy" ein solches sein sollte (oder juristisch überhaupt sein kann), sollte klar sein, was der Gesetzgeber hier eigentlich beabsichtigt hat. Die ernsthafte Forderung (die ich schon von mehreren Seiten gehört habe), dass einige Personen die Möglichkeit haben sollten, bestimmte Anträge zu löschen, ~~lässt mich daran zweifeln, ob ich in der richtigen Partei bin~~ --Jbe 02:56, 5. Nov. 2009 (CET)

Ich wäre ehrlich interessiert wo so eine Form von Offenheit mit Nachhaltigkeit existiert. Lass uns mal überlegen, wo findet das statt? Dann können wir gucken was man braucht um es zu tun. Mir fällt grade nichts ein, aber das muss nix heißen. --Pudo 00:55, 6. Nov. 2009 (CET)

Ich kann verstehen, dass die Forderung nach Moderationsfreiheit (im Sinne von "keine Zensur") aus technischer Sicht Bauchschmerzen bereitet, wenn man immer die Implementierung im Hinterkopf behält. Ein ganz einfacher Ansatz (der auch in Wikis Anwendung findet), ist Dinge nicht wirklich zu löschen, sondern sie per Historie nachvollziehbar zu behalten. Damit hat man schon die halbe Miete. --Jbe 01:06, 6. Nov. 2009 (CET)

Ich könnte mir auch vorstellen, dass Beiträge nicht mehr geändert werden können (Außnahme, dass sie wegen Gesetzesverstößen gelöscht werden müssen). Wenn man den Beitrag verbessern möchte, dann muss man halt einfach einen Nachfolge-Klon anlegen. Dadurch bleiben Abstimmungen immer noch zu den Ursprünglichen Posts assoziiert. Dies hat allerdings die Gefahr dass sich Abstimmungen etc. zu sehr zergliedern, weil es dadurch viele ähnliche Vorschläge gibt. Der Vorschlag von Liquid Democracy/Votorola/Theorie könnte das Problem aber eventuell lösen. --Wobble 16:05, 6. Nov. 2009 (CET)

Der Ansatz von LiquidFeedback sollte dieses Problem auch lösen können. Hierbei haben Initiatoren die Hohheit über Antragsänderungen, jeder ist aber immer berechtigt einen Alternativvorschlag einzubringen. Erreicht dieser ein Unterstützerquorum, gelangt er in die Abstimmung. Am Ende wird per Präferenzwahl (Schulze-Methode) abgestimmt. --Jbe 16:11, 6. Nov. 2009 (CET)

Du bist in der richtigen Partei. Lass dich bitte nicht von einigen Wenigen verunsichern. Wir sind sehr froh, dass du das ld tool gemacht hast und werden und massiv dafür einsetzen, dass ld jetzt in die Satzung reinkommt!--RP 00:40, 6. Nov. 2009 (CET)

Ich muss meinen Beitrag zur Frage, ob ich in der richtigen Partei bin etwas korrigieren. Er war polemisch. Sorry. Die Bedenken hier in diesem Thread seitens von Pudo sind den Überlegungen bezüglich der Implementierbarkeit geschuldet. Ich habe ja ebenso bei der Sicherheit angemerkt, dass man Anforderungen nicht zu hoch stellen solle. Ich möchte den Befürwortern bestimmter Moderationssysteme nicht unterstellen, dass sie undemokratisch denken würden. Nochmal Sorry! Das ändert aber trotzdem nichts an meiner persönlichen Meinung und Einschätzung, dass ein Demokratiesystem die angesprochenen Probleme lösen muss, und dass es gilt die Zeit von Moderatoren und Antragskommissionen zu überwinden. --Jbe 01:25, 6. Nov. 2009 (CET)

Ich wollte nocheinmal kurz anmerken, dass es verschiedene Formen von Moderation gibt. Unser derzeitiger Entwurf schließt lediglich Moderation durch die vom Vorstand bestellten technischen Administratoren des Systemes aus, sowie Moderation durch Löschung (mit Ausnahme bei gesetzlicher Verpflichtung). Das gesamte entstehende System muss allerdings "demokratischen Grundsätzen" genügen. Das sollte für ein Liquid Democracy Tool selbstverständlich sein. --Jbe 01:17, 6. Nov. 2009 (CET)

Sicherheit

Kritik: web-basiert ist unsicher

Vorsicht: Anforderungen nicht zu hoch stellen, sonst wird eine Implementierung nie fertig oder verschlingt unangemessen viele Ressourcen!

Sicher, aber wenn man in den Parlamentsbetrieb geht, wird man die ganze Sache nochmal neu aufrollen müssen, denn web-basierte Applikationen können einfach nicht wirklich sicher gemacht werden. Am Schluss könnte nur ganz selten hier und da manipuliert werden, und der einfache Pirat, der aufschreit, wird als Denunziant diffamiert. Gerade wir Piraten sollten unsere Apps auf eine höheren Sicherheitsniveau bauen, als eine durchschnittliche Firma oder Bank. Es geht hier schließlich auf absehbare Zeit um reale Beschlüsse mit realen politischen Folgen, sei es in Münster, in Berlin, im Landtag NRW oder im Bundestag. —lynX

Meiner Meinung nach sind Firewalls, Code-Reviews, etc. nur ein Weg um Betriebsstörungen durch Hacker zu erschweren. Manipulationen 100%ig ausschließen können diese Maßnahmen nicht – dazu ist das gesamte technische System viel zu komplex. Wenn Webapplikationen unsicher sind, welche Art von Programmen wären denn dann sicher? Der Einsatz eines dezentralen Systemes, welches sich z.B. auf mathematische Verschlüsselungsverfahren verlässt, erhöht zumindest die Komplexität noch weiter. Aufgrund nicht auszuschließender Manipulationen werden andere Organe nicht verpflichtet, Entscheidungen des Systemes umzusetzen. In unserem Entwurf für die Satzung heißt es: "Alle Organe und Mandatsträger sind grundsätzlich dazu angehalten, jedoch nicht verpflichtet, sich entsprechend dieser getroffenen Entscheidungen zu verhalten." Natürlich ist es im Sinne der Basisdemokratie wünschenswert dennoch möglichst verlässliche Ergebnisse zu ermitteln. Deshalb haben wir folgendes gefordert: "Die Berechnungsgrundlagen von Abstimmungsergebnissen oder Antragsbewertungen müssen nach Abschluss des jeweiligen Themas (z. B. durch eine endgültige Abstimmung) jedem Benutzer des Systems noch für mindestens 23 Wochen zur Verfügung gestellt werden. In den Berechungsgrundlagen sind Namen oder Pseudonyme der Abstimmenden und bei Stimmübertragung auch die der Delegierenden enthalten. [...] Die Information darüber, welche alten Pseudonyme welchem Mitglied zugeordnet waren, sind in Form einer Papierakte für 3 Jahre aufzubewahren. Die Landesmitgliederversammlung kann beantragen, dass diese Papierakte von der Wahlkommission geprüft wird.". Vorstand und Mandatsträger werden sich entsprechend ihrer Umsetzung der Beschlüsse aus Liquid Democracy insbesondere bei den jeweils nächsten internen Wahlen verantworten müssen. Diese Personenwahlen finden natürlich außerhalb von Liquid Democracy statt, da sie nach PartG §15 und PartG §17 geheim sein müssen. BTW: Ich persönlich möchte mir (derzeit) weder von der Piratenpartei noch von einer anderen Partei vorschreiben lassen, welche Programme ich auf meinem Computer zu installieren habe ;-) --Jbe 18:37, 3. Nov. 2009 (CET)

Da stimme ich jetzt mal zu! Diese erste Version eines ld-tools ist der Anfang zur Verwirklichung einer wirklich großen und wichtigen Piratenidee. Kommt jetzt die Angst vor der eigenen Courage hoch? Natürlich stehen wir am Anfang eines jahrelangen Entwicklungsprozesses und müssen uns diese Zeit auch geben, aber jetzt sollten wir endlich starten mit ld. Auch indem wir es in die Satzung einbauen!--RP 00:13, 6. Nov. 2009 (CET)

Ich habe keine Angst, im Gegenteil, ich finde die Ansprüche sind nicht zu hoch und besitze die Courage zu sagen, eine GUI-Applikation mit integrierter GPG-Engine zur dezentralen + cryptologisch gesicherten Implementation von LD ist nicht wirklich aufwendiger als der jetzige Ansatz - er ist lediglich vollkommen anders, und man muss sich die Frage stellen, ob es sinnvoll ist ein System zu bauen, welches nur die erwünschte Funktion liefern wird, aber nicht die angemessene Sicherheit. Ich finde es null tröstlich, dass unsere Parlamentarier dann letztlich eh machen dürfen, was sie wollen. Das haben wir bei anderen Parteien auch schon. —lynX

Hash von Passwort, Nachvollziehbarkeit

Aus Hauptartikel zu Benutzerkonten:

Vorschlag: "... sind diese ausschließlich als Hash von Passwort, eines serverseitigen Geheimnisses sowie eines pro Benutzer eindeutigem Salting zu speichern." Ein einfacher Hash ist für die Tonne, die umgekehrten Tabellen gibt's bei Google. Drahflow 21:53, 8. Nov. 2009 (CET)

Du hast natürlich technisch vollkommen recht, aber bitte lass uns nicht anfangen hier technische Details zu diskutieren, das führt an anderer Stelle ins Verderben. --Pudo 22:28, 8. Nov. 2009 (CET)

Mir ist das Problem bewusst; solche Details sollten eigentlich von der Forderung der "dem Stand der Technik entsprechenden Sicherheitsmaßnahmen" abgedeckt sein. Da hier aber das Passworthashing explizit erwähnt wurde, wäre es entweder konsequent das Salting auch zu benennen, oder den ganzen Punkt zu streichen. Ich finde, dass man sowas wie Passworthashing schon konkret fordern kann... Ebenso auch CSRF-Protection, da letzteres gerade bei Webanwendungen sehr wichtig ist. Aber vielleicht geht das auch alles schon zu weit, und man sollte es abstrakter halten. --Jbe 23:08, 8. Nov. 2009 (CET)

Wie wärs mit: "Die Software muss die Einrichtung von Benutzerkonten für jeden Piraten unterstützen. Für den Fall einer Authentisierung mittels Kennwörtern sind diese ausschließlich mittels eines dem Stand der Technik entsprechenden Einweg-Verschlüsselungsverfahrens, welches Zufallsdaten ("Salt") einbezieht, zu speichern." --Jbe 23:25, 8. Nov. 2009 (CET)

Entsprechend der Diskussion beim Squad Treffen habe ich den Punkt ganz gestrichen. --Jbe 23:58, 11. Nov. 2009 (CET)

Ich überlege, ob es nicht vielleicht sinnvoll ist, den Passus Nachvollziehbarkeit zu streichen, da Administratoren eigentlich immer einen Weg finden können, solche Maßnahmen zu umgehen. (Es sei denn man führt komplexe 4-Augen-Prinzipien, externe Log-Server etc. ein.) Die Nachvollziehbarkeit soll ja gerade NICHT durch komplizierte technische Feinheiten erreicht werden, sondern durch die Möglichkeit der Einsichtnahme durch jeden Benutzer, die bereits im Absatz Veröffentlichung der Abstimmungsergebnisse gefordert ist. --Jbe 23:32, 8. Nov. 2009 (CET)

In der Sitzung des Liquid Democracy Squads wurde dieser Absatz modifiziert. --Jbe 23:46, 11. Nov. 2009 (CET)

Korruption

Wenn man jederzeit nachschlagen kann, welche Leute der falschen Meinung sind, und mit welcher Stimmengewichtung, ermöglicht man Lobbyisten ganz gezieltes arbeiten: Sich die richtigen Leute herauspicken. Warum der Rest der Leute es nicht merken wird, wann jemand gekauft wurde, habe ich versucht auf User:lynX/Demokratie 2.0 zu erläutern. Zu denken, man würde Korruption sofort sehen und an den Pranger stellen können, ist hochgradig blauäugig. So gesehen kann ich mir nicht vorstellen, dass solch ein System im harten realen Politikleben, wo es um knallharte wirtschaftliche Interessen geht, ohne Geheimhaltung funktionieren kann. —lynX

Zu diesem Thema bin ich neulich über folgende Seite gestolpert: Condorcet Internet Voting Service. Die machen wohl was mit Geheimhaltung durch Kryptographie. Habe aber bisher noch nicht die Zeit gehabt, mir das im Detail anzuschauen, aber wollte euch den Link nicht vorenthalten. Ich halte allerdings immer noch den Ansatz der vollständigen Offenlegung (mit Ausnahme einer Pseudonymisierungsmöglichkeit der Accounts, siehe Abschnitt Zugangsverwaltung) für die beste Lösung, da so keinerlei Softwareinstallation bei den Benutzern erforderlich ist und man sich außerdem nicht auf die Nicht-Existenz bestimmter mathematischer Lösungsverfahren verlassen muss. Das Gesamtsystem kann schneller umgesetzt werden und einfacher verwendet werden. Im Squad haben wir z.B. das letzte mal über das Verwenden von SSL-Client-Zertifikaten zur Authentisierung geredet. Solche Lösungen können zwar theoretisch ganz toll sein, aber das 1000 Usern zu erklären braucht mehrere Call-Center ;-) Abgesehen davon stellt sich bei der Verwendung von spezieller Software die Frage, welche Betriebssysteme unterstützt werden sollen? Eine Web-Applikation, die ihre Daten einfach offenlegt, umschifft diese ganzen Probleme. --Jbe 13:10, 15. Nov. 2009 (CET)