Benutzer Diskussion:YourEyesOnly/Bürgschaft

Keyring-Seite

Gibt es schon eine Vorlage für die Unterseite? --DaB. 18:43, 8. Feb. 2008 (CET)

Nein, da wollte ich noch ein wenig am Layout arbeiten, das ist noch häßlich. Außerdem sollten ein paar mehr Informationen drauf. --Markus Mueller 18:52, 8. Feb. 2008 (CET)

Bißchen streng?

Die Unterscheidung zwischen Urbürgen, Vollbürgen und verbürgten Benutzern ist m.E. keine schlechte Idee. Ich finde die umseitig aufgeführten Zahlen (drei Vollbürgen notwendig) jedoch zu streng. Das würde meine Grundidee, daß im Prinzip schon ein Stammtischbesuch ausreicht, um verbürgt werden zu können, aushebeln. Auf welchem Stammtisch finden sich schon drei Urbürgen? Selbst auf JCs letzter Party waren bei insgesamt 100 Gästen wohl keine drei Urbürgen dabei. Das System würde deshalb fast komplett an den Urbürgen hängen (wie viele sind das? 5? 10? 20?) und nie ein Selbstläufer werden. Man sollte deshalb die notwendigen drei Urbürgen durch eine (höhere) Zahl an Vollbürgen ausgleichen können. --Fritz @ 18:56, 8. Feb. 2008 (CET)

reinquetsch: Tut jetzt nicht direkt was zur Sache, aber nach meiner Zählung und unter der Annahme, dass auch Beisitzer zum Vereinsvorstand zählen, waren auf der letzten JC-Party allein 11 Vereinsvorstands-„Urbürgen“ anwesend. Reicht also dicke :-) — ^PDD — 21:48, 8. Feb. 2008 (CET)

Nun, eine Verbürgung kann ja auch ohne Urbürgen erfolgen. Nur Vollbürgen können auf diese Weise nicht generiert werden. Es ist übrigens Sinn der Sache, dass ein einzelner Stammtisch nicht gleich alle Verbürgungsstufen erledigen kann. Im Grunde soll eine Vollverbürgung nur zu unterschiedlicher Zeit an unterschiedlichem Ort durch unterschiedliche Urbürgen geschehen können. Das erhöht die Sicherheit des Systems, dass darauf ausgelegt ist, dass es zu keinem Zeitpunkt kompromittiert sein darf.

Im weiteren kann ich Deine Bedenken bestehen, aber Du solltest daran denken, dass die Zahl der Urbürgen durch ehemalige Vorstandsmitglieder und Personen, die wir einfach mal aus offensichtlichen Gründen zu Urbürgen erklären (z.B. bekannte Administratoren, die ihre Identität voll preisgeben, als Beispiel fiele mir etwa Uwe Gille ein; oder Personen, die nahezu alle Urbürgen persönlich kennen), erheblich höher werden kann, als Du jetzt vielleicht meinst. Bevor das System rund läuft, dauert es sicher ein paar Monate, danach sollte es aber sehr einfach sein, seine Verbürgung durchzubekommen. --Markus Mueller 19:02, 8. Feb. 2008 (CET)

Ok, wenn "offensichtliche Bekannte", ich nenne z.B. mal Jcornelius oder SVL, als Urbürgen zählen, dann ist mein Einwand weniger gewichtig. Es klingt im Text nur etwas zu sehr auf Wikimedia oder die Foundation bezogen. Die Frage, die sich hier allerdings stellt, wäre dann aber, ab wann jemand "offensichtlich bekannt" ist. --Fritz @ 19:06, 8. Feb. 2008 (CET)

Einfach pragmatisch und unkompliziert entscheiden. Wenn jemand seit langem mitarbeitet, ständig auf Fotos von Stammtischen zu sehen ist und zuhause schonmal ne Grillparty für Wikipedianer gegeben hat, dann bescheinige ich z.B. Benutzer:Jonathan Groß gerne, dass unter dem Gesichtspunkt seiner Identitätssicherheit seine Eignung zum Urbürgen zweifelsohne gegeben ist. --Markus Mueller 19:10, 8. Feb. 2008 (CET)

Pragmatisch ist genau, was ich gemeint habe. Und wenn wir ehrlich sind, ist es doch so, daß die "offensichtlich bekannten" Benutzer diejenigen sind, für die sich eine große Zahl (sagen wir 20 oder 30) von "einfachen Bürgen" verbürgen würden. --Fritz @ 19:24, 8. Feb. 2008 (CET)

Ich denke mal drüber nach, wie man das kodifizieren könnte. Vielleicht, dass der Vorstand darüber berät, wer als Urbürge geeignet ist. Das ist jetzt zwar eine willkürliche Festlegung, aber das Gremium hätte zumindest die Infrastruktur, sowas zu diskutieren und bestünde nur aus Urbürgen. Dazu müsste man allerdings erstmal klären, ob da überhaupt alle mitmachen würden usw. Also in dieser Hinsicht besteht noch Nachbesserungsbedarf, ganz sicher. --Markus Mueller 19:28, 8. Feb. 2008 (CET)

„Pragmatisch“ ist das Wort der Stunde. Morgen abend findet vor Konnopke’s Imbiss in Berlin ein erstes Bürgschafts-Bestätigungstreffen statt. Achim bringt seine neue Digitalkamera mit (zur Dokumentationszwecken), er, Finanzer und ich unsere Personalausweise… Wer sich anschließen mag, plant den Termin einfach ein. Hinterher gibts Currywurst und Pils. Die genaue Zeit wird hier noch bekanntgegeben. Herzliche Grüße --Frank Schulenburg 20:02, 8. Feb. 2008 (CET)

Mmh, der Regel nach wäre ich dann von zwei Urbürgen bestätigt, dürfte aber selber nicht bürgen, weil ich ja kein Urbürge bin; oder anders: trifft sich bsp. der Stammtisch Ostwestfalen ohne Urbürgen könnte niemand anders für die Anwesenden Bürgen, weil ja niemand Vollbürge und alle unverbürgt sind obwohl da evtl. denn 10 Leute sich gegenseitig bestätigen könnten – oder was habe ich nicht verstanden? Könnte man zudem bitte das "-klassen" ersetzen, ist in meinen Augen eine sehr suboptimale Namenswahl. Und schlußendlich: Ich habe nirgends finden können, wie ich mir jetzt so'ne Hash-Code-Zahl aus Namen und Geburtsdatum bastle – gibts da ein gemeinfreies und biologentaugliches Tool? Gruß -- Achim Raschka 20:43, 8. Feb. 2008 (CET) (der sich auf Currywurst mit Darm und Pils freut)

Das wird ja wohl möglich sein, Dich instantan zum Urbürgen zu befördern. Du bist ja über Deinen Arbeitsplatz identifikabel. Wenn sich der Stammtisch Ostwestfalen trifft, dann haben wir in der Zwischenzeit hoffentlich genug Vollbürgen dort, die schonmal bürgen können, Urbürgen braucht es ausschließlich für die Beförderung zu Vollbürgen. Ich glaube, das muss man mal deutlich herausstellen, das scheint zu sehr unterzugehen.

Das wird die ersten Wochen sowieso so aussehen, dass jeder sich erstmal einträgt, traurig seinen leeren Schlüsselring durch die Finger dreht und nur nach und nach eine Verbürgung nach der nächsten herintröpfelt. Erst wenn eine kritische Masse von Vollbürgen existiert, werden alle weiteren Verbürgungen extrem schnell vonstatten gehen (große Wikipedia-Ereignisse dürften das sehr stark beschleunigen). Je mehr Leute sich allerdings schonmal in die Liste eintragen und sich einen leeren Schlüsselring anlegen, desto eher wird man sehen und planen können, bei welchen Gelegenheiten man sich gegenseitig verbürgen kann. Oft braucht es dann nur einen in der Kette zum Vollbürgen zu machen und schon valididieren sich von ganz alleine ganze Bürgekaskaden nachträglich durch. --Markus Mueller 20:53, 8. Feb. 2008 (CET)

Achim, du magst dich nicht mehr erinnern, aber du warst mal Vereinsvorstand und soweit ich die Regeln verstehe, zählst du damit eh als Urbürge. -- southpark Köm ? | Review? 20:47, 8. Feb. 2008 (CET) der sich fragt ob Aufwand und Ertrag bei dem System wirklich in einem sinnvollen Verhältnis stehen, aber das grad nicht als sein Problem ansieht :-)

Die Möglichkeiten einer eineindeutigen und zugleich anonymen Zuordnung finde ich schon spannend, es ist immer eine Frage, was man draus macht. Ich kann mich allerdings nicht erinnern, damals als Vorständler irgendwem meinen Ausweis gezeigt zu haben, zudem ich ja ncoh unter dem Account Nec rophorus tätig war. Gruß -- Achim Raschka 21:09, 8. Feb. 2008 (CET)

Mmh, also in Wikipedia fand ich es ja schon immer spannender, was jemand schreibt als wer es tut und außerhalb wollt ich auch noch nie Ausweise sehen, aber mal schauen was draus wird; aber zumindest wirst du zustimmen, dass dasselbe Zottelhaarige etwas damals bei den Vereinstreffen auftauchte wie diesmal bei Konopkes. -- southpark Köm ? | Review? 21:12, 8. Feb. 2008 (CET)

Ich möchte den Diskussionsfaden wieder etwas aufnehmen. Als Vollbürge braucht man mindestens 10 Verbürgte sowie 3 Urbürgen. Da wir aktuell keine Verbürgten haben und insgesamt nur 11 Urbürgen sollten wir die Grenze von 8 auf 5 senken. Auf 13 kann keiner kommen, es sei den wir wählen uns noch ein paar Stewards oder bringen fehlende Mitglieder des frischen Vereinsvorstandes dazu, hier mitzumachen. Sobald es mehr Verbürgte als Urbürgen gibt, könnte man wieder auf 8 umstellen. Gerne könnte man dann auch drei Verbürgungen nachholen. Was meint ihr? Viele Grüße --Marbot 15:56, 1. Jul. 2008 (CEST)

Widerspruch?

Es ist durchgängig von behördlichen Dokumenten die Rede, im hinteren Teil steht dann aber etwas zu Studentenausweisen, die nicht notwendigerweise behördlich sein müssen. Kann man die Formulierung hier nicht etwas vereinfachen? sebmol ^{? !} 18:59, 8. Feb. 2008 (CET)

Da kennst Du Dich besser aus, wenn Du helfen kannst? --Markus Mueller 19:03, 8. Feb. 2008 (CET)

Gerade getan. sebmol ^{? !} 19:11, 8. Feb. 2008 (CET)

Danke. Schön mein krauses Geschreibsel vereinfacht. :-) --Markus Mueller 19:13, 8. Feb. 2008 (CET)

Urbürgen

Sollten nicht auch diejenigen Benutzer die gegenüber der Foundation ihre Identität nachweisen müssen (Stewards, CU-Berechtige etc.) als Urbürgen zählen? Liesel 20:41, 8. Feb. 2008 (CET)

Ja. --Markus Mueller 20:54, 8. Feb. 2008 (CET)

Sagt mir jemand bitte, was genau ich nun tun soll? Eine konkrete Anleitung Schritt-für-Schritt wäre irgendwie hilfreich. Da ist euch CFT voraus ;-) sebmol ^{? !} 21:36, 8. Feb. 2008 (CET)

Langsam, langsam. Ich arbeite gerade an der auf der Hauptseite verlinkten Anleitungs-Seite. --Markus Mueller 22:06, 8. Feb. 2008 (CET)

Fertig... bitte noch verbessern, ich muss dringend ins Bett jetzt. --Markus Mueller 22:58, 8. Feb. 2008 (CET)

Das OTRS-Team muss sich auch ohnehin identifizieren und arbeitet mir Klarnamen. Diese Gruppe würde ich auch als Urbürgen sehen - spätestens mit dem geplanten Treffen in Ffm. --ST ○ 10:54, 10. Feb. 2008 (CET)

Events mit hinreichend Urbürgen

Ich denke, in diesem Frühjahr/Sommer stehen einige Events mit hinreichend Urbürgen/Bürgen an, sammeln wir doch mal:

• Wikipedia:Treffen der Wikipedianer
  • u.a. Wikipedia:Berlin - 15. Februar; Wikipedia:Frankfurt - 16. Februar

• Wikipedia:Redaktion Medizin/Treffen - 1./2. März
• Wikipedia:Foto-Exkursion Berlin 2008 - 26. April
• Wikipedia:Redaktion Biologie/Treffen - 12-15. Juni
• Wikipedia:Academy

... -- Achim Raschka 21:16, 8. Feb. 2008 (CET)

Noch eine Frage: Wenn man bsp. die Authentifizierung via Mail zuließe, könnte das Ganze noch beschleunigt werden. So könnte ich bsp. einen Ausweisscan an mehrere Urbürgen schicken; Wäre das im Sinne des Systems? -- Achim Raschka 21:59, 8. Feb. 2008 (CET)

Eher nein. Schließlich könntest du wer weiß was für Ausweise durch die Gegend schicken. --DaB. 23:52, 8. Feb. 2008 (CET)

Also bei Benutzern, die ich schon jahrelang persönlich kenne, würde mir persönlich ein Scan vom Ausweis reichen (bei Achim reicht mir sogar eine Einladung zur Currywurst) :-) --Frank Schulenburg 23:56, 8. Feb. 2008 (CET)

Mir im Prinzip auch, insbesondere bei Achim, aber nachdem ich jetzt eine Nacht darüber nachgedacht habe, muss ich sagen: wir schwächen dadurch das Sicherheitskonzept des Systems erheblich. In diesem Fall hier wäre das Vertrauen natürlich gerechtfertigt, aber wenn man diese Möglichkeit grundsätzlich zulässt, könnte mal jemand dabei sein, der den Scan um ein Winziges (1 Buchstabe oder 1 Zahl) verändert. Dadurch würde sich die Ausgangsphrase um 1 Bit ändern und ein komplett unterschiedlicher Schlüssel entstehen. Wenn sich dieselbe Person dann zu anderer Gelegenheit anderen Bürgen mit seinem unverfälschten Pass und einem Sockenpuppenaccount vorstellt, dann kann er sich einen zweiten Account verbürgen lassen.

Als nächstes dachte ich daran, diese Methode zuzulassen, wenn wenigstens einer in der Reihe der Bürgen den Originalausweis gesehen hat. Dann kann jemand natürlich den Scan nicht verändern, ohne das es spätestens dann auffällt, wenn die korrekte Ausgangsphrase gebildet wird. Ist aber trotzdem keine Lösung, denn das Sicherkonzept beruht allein darauf, dass es nicht möglich ist, 5 unehrliche Bürgen zu finden. Wenn ich das Verschicken von Ausweisen zulasse, dann kann ich 4 ehrliche Bürgen durch einen manipulierten Scan betrügen und brauche nur noch 1 unehrlichen Bürgen zu finden, der mit mir gemeinsame Sache macht (oder sogar gar keinen, wenn ich selbst Vollbürge bin und meine Sockenpuppe dann selbst bestätige).

Insofern: das Erlauben des Verschickens von Ausweisscans ist eine verführerische Sache, wenn man gerne schnell verbürgt werden will, aber der Vorteil des Verfahrens hier ist, dass es sehr sicher ist. Wenn man einfach nur schnell „dazugehören“ will, sollte man das Taxmann-Carl-Verfahren wählen, wo dann allerdings so gut wie keine Absicherung gegen die Bestätigung von Zweitaccounts besteht. --Markus Mueller 11:01, 9. Feb. 2008 (CET)

Berechnungssoftware

Wenn ich nicht ganz doof bin, denke ich dass man damit: http://serversniff.de/crypt-hash.php den Key berechnen kann. Liesel 21:35, 8. Feb. 2008 (CET)

DaB.s Berechnungs-Tool ist ja auch schon vorne verlinkt (und wenn das Tool ordentlich mitlogt, hat DaB. bald eine schöne Liste und kann z. B. unseren Geburtstagskalender updaten...) — ^PDD — 21:59, 8. Feb. 2008 (CET)

ein ungefragtes updaten des Geburtstagskalenders wäre ein massiver verstoss gegen den datenschutz! --Jom _Klönsnack? 11:12, 10. Feb. 2008 (CET)

Zum Zeitpunkt meiner Frage gabs das noch nicht ;-) Liesel 22:18, 8. Feb. 2008 (CET)

Die beiden auf der Hauptseite genannten Programme erzeugen bei mir unterschiedliche Hashs. Wenn ich bei der Foundation als Steward registriert bin, bin ich dann auch Urbürge? —DerHexer (Disk., Bew.) 22:42, 8. Feb. 2008 (CET)

Dann hast Du etwas falsch gemacht. Wenn Du alles richtig gemacht hast, geben die Programme alle denselben Wert aus. Du hast doch nicht im zweiten Tool ein Zeilenumbruch drinnen gehabt? --Markus Mueller 22:57, 8. Feb. 2008 (CET)

Die Nullen werden bei DaB.s Programm verschluckt, weswegen PDD diesen Link bis zum Fix erstmal entfernt hat. —DerHexer (Disk., Bew.) 22:59, 8. Feb. 2008 (CET)

Hab's repariert. --DaB. 23:51, 8. Feb. 2008 (CET)

Moin Hexer, wenn Du gegenüber der Foundation deine Identität bestätigt hast, dann bist Du selbstverständlich auch Urbürge. Grüße --Frank Schulenburg

Kollisionsverringerung

Warum bringt man den Benutzernamen nicht mit im Hash unter - das würde die Kollissionsgefahr massiv verringern - Alternativ könnte man auch einen Salt einbauen und den Hash in der Form "Salt:Hash" angeben... ⑊ C-M ^hä? 22:45, 8. Feb. 2008 (CET)

Hehe, ne, das geht gerade nicht. Darüber bin ich auch kurz gestolpert. Tipp: Du darfst nichts einbauen, was nicht konstant aus den Identifikationsdokumenten hervorgeht. - Die Kollisionsgefahr halte ich für nahe 0, weil Name und Jahr das Geburtstagsparadoxon extrem entschärfen. --Markus Mueller 22:56, 8. Feb. 2008 (CET)

Aber die Persönlichen Daten sollen doch eh mit dem Benutzernamen verknüpft werden - ansonsten kann man sich das ganze sparen. ⑊ C-M ^hä? 23:29, 8. Feb. 2008 (CET)

Ah, pass auf, dann schauen wir und mal ein Beispiel an. Das System basiert auf der Idee, dass es für eine Person mit vertretbarem Aufwand nicht möglich ist, zwei unterschiedliche Hashes zu generieren. Wenn wir uns bei diesem Verfahren allein auf unveränderlichke Merkmale beschränken (nämlich Name und Geburtstag), dann entsteht grundsätzlich derselbe Hash. Wenn wir nun irgendeine Variable in die Ausgangsphrase einführen (Username, Salt, laufenden Nummer des Schlüssels), dann kann ich zwei Hashes erzeugen, die komplett unterschiedlich sind (immerhin sind Hashes so konzipiert, dass sie so zufällig wie irgend möglich sind). Mit zwei Keys kann ich aber versuchen, zu manipulieren: ich kann zu unterschiedlichen Bürgen gehen und mich mit unterschiedlichen Benutzernamen bestätigen lassen. Da das System Anonymität unterstützt, könnte ich mit realtiv wenig Aufwand eine Sockenpuppe bestätigen lassen. Es wäre immer noch mit sehr viel mehr Aufwand und Risiko als z.B. bei Carls Verfahren (ist nicht böse gemeint, Carl) verbunden, aber es wäre doch insgesamt gesehen zu einfach.

Bei dem tatsächlichen Verfahren kann ich nicht zu zwei Bürgen gehen und mit je unterschiedlichen Accounts einen Hash generieren, denn es käme jeweils derselbe Key heraus. Das fiele sofort auf (weil Kollision) und ich wäre des Betrugs überführt (oder wir haben doch eine echte Kollision, wo man dann eine Verfahrensänderung einführen müsste). Die Kollisionen und die Abkopplung des Accountnamens vom Schlüssel sind also sogar zentraler Teil des Sicherheitskonzepts. --Markus Mueller 10:49, 9. Feb. 2008 (CET)

Geburtsort? -- Mathias Schindler 12:11, 9. Feb. 2008 (CET)

Augenfarbe? ⑊ C-M ^hä? 17:04, 9. Feb. 2008 (CET)

datenschutz

da in anderen systemen mein geburtsdatum in zusammenhang mit meinem namen bereits zwingend zur erzegung eines passwortes genutzt wird , bin ich nicht bereit mein geburtsdatum 5 anderen wikipeianern zu offenbaren. wie soll das jetzt gehen, bin ich dadurch user 2. klassse? das system wo auch das geburtsdatum gefordert wird ist eine behörde, so das wenig hoffnung besteht, das dort geändert wird --Jom _Klönsnack? 23:38, 8. Feb. 2008 (CET)

Solange du den Namen dieser Behörde nicht mitteilst (und das solltest du aus Rufschädigungsgründen lieber nicht, da eine Behörde sträflich nachlässig arbeitet, die aufgrund von Namen und Geburtsdatum authentifiziert; das sind ja mehr oder weniger öffentliche Daten von dir, die ich bei jedem Adresshändler erwerben kann, wenn ich will), sollte kein Problem bestehen, oder? — ^PDD — 23:48, 8. Feb. 2008 (CET)

Lohnt sich der Aufwand?

Ausgezeichnet gemacht. Wirklich mit Hand und Fuß. Man kann das vielleicht auch für Zwecke nutzen, die sich jetzt noch nicht abgezeichnet haben. --Carl 01:29, 9. Feb. 2008 (CET)

angesichts dessen dass sich irgendwie noch gar keine konkreten zwecke abgezeichnet haben, ist das zu vermuten... oder gibt es einen bestimmten grund warum das jetzt kommt? -- southpark Köm ? | Review? 18:12, 9. Feb. 2008 (CET)

Ach, und ich hatte schon gehofft, Southpark schreibt dauerhaft Großbuchstaben, wo sie hingehören. -- Martin Vogel 17:03, 13. Feb. 2008 (CET)

Bestätigungstreffen, heute (Berlin)

Datei:Konopke.jpg

Für das bereits oben angekündigte Treffen (Konnopke’s Imbiss, Prenzlauer Berg) schlage ich 18.30 Uhr vor. Die letzte Currywurst gibt's um 19 Uhr – hinterher können wir den Abend gemütlich ausklingen lassen. Wer kommt? --Frank Schulenburg 11:21, 9. Feb. 2008 (CET)

1. --Frank Schulenburg 11:21, 9. Feb. 2008 (CET)
2. --Michail 11:42, 9. Feb. 2008 (CET)
3. -- Achim Raschka 11:44, 9. Feb. 2008 (CET) (mit Knips
4. Sargoth^¿!± 16:03, 9. Feb. 2008 (CET) Aber leider nix mit ausklingen, habe nen Spieleabend. Der ist für 19:00 Uhr angesetzt, mehr als eine halbe Stunde für die Fahrt zu verschieben möchte ich nicht.
5. — ^PDD — 16:09, 9. Feb. 2008 (CET) Eintlich nur wegen die Wurscht...

   Scheint 'n wahnsinnig wichtiges Treffen zu sein, wohl 'ne echte Wikipedia:Weichenstellung für die Zukunft, verpackt zwischen Pommes und Mayo, was? Mal angenommen man kommt dahin, holt sich nun 'ne Zurriwurst und 'n Pilsken. Was passiert dann mit einem? Kriegt man da 'ne Sockenpuppenbescheinigung? :-) --Schlesinger ^schreib! 17:06, 9. Feb. 2008 (CET)

6. Ich verbürge mich als meine eigene Socke. :P --J. © RSX/RFF 17:16, 9. Feb. 2008 (CET)

   Im Geiste. Wie gern wär ich dabei! [ˈjoːnatan gʁoːs] (ad fontes) 20:58, 9. Feb. 2008 (CET)

Diskussion

Damit wenigstens ein Unverbürgter als verbürgt (und satt) nach Hause schlendern kann, brauchts die kritische Masse von 6 Teilnehmern (davon 5 Urbürgen), richtig? — ^PDD — 15:20, 9. Feb. 2008 (CET)

Kann man das nicht nächste Woche machen? Da ist wenigstens keine Uni mehr, vulgo, es stehen keine Prüfungen vor der Tür. —DerHexer (Disk., Bew.) 15:24, 9. Feb. 2008 (CET)

Man kann das natürlich auch einfach jede Woche machen :-) — ^PDD — 15:27, 9. Feb. 2008 (CET)

Nächste Woche sind weder Frank noch Michail in Berlin und eigentlich war der ursprüngliche Plan ja nur Currywurst essen zu gehen ;O). Ich kann aber auch gerne eine fixe Bürgstelle eröffnen, über Besuch beim abendlichen Bier freue ich mich immer ... (vor allem, wenn es mitgebracht wird) -- Achim Raschka 15:29, 9. Feb. 2008 (CET)

Mich darf auch jeder besuchen, wenn er eine Currywurst von Konnopke mitbringt. Frank, bring mir bitte eine mit. Aber warm sollte sie noch sein, wenn ich sie bekomme! --Markus Mueller 18:23, 9. Feb. 2008 (CET)

Schade, dass ihr das so spät auf Wikipedia:Berlin angekündigt habt... wär sonst für ne halbe Stunde vorbeigekommen, jetzt isses leider zu spät :(. Euch trotzdem viel Spaß ;). Grüße --APPER\^☺☹ 18:37, 9. Feb. 2008 (CET)

Namen herausfinden

Hmmm. SHA256 ist schnell genug in software gelöst, dass man damit einfach mal so lange hashes ziehen kann, bis der Plaintext schon dabei ist. Angenommen, ich kenne von einer Person nur den Vornamen, reicht ein Wörterbuch und ein mäßig aktueller Rechner aus, um (die häufigeren) Nachnamen und Geburtsdatum einer Person herauszufinden. Bei den Menschen, deren Benutzername dem Realnamen entspricht, ist der Aufwand natürlich noch geringer. Naja, kein wahnsinnig großes Ding, sollte man halt nur berücksichtigen.

Mit einer Zeile in der Shell braucht man für einen Zeitraum von 10 Jahren bei bekanntem Vor- und Nachnamen auf einem handelsüblichen Notebook etwa 1:30 minuten. Zu berücksichtigen ist hier, dass das die denkbar langsamste Methode ist (und ich ein hundsmiserabler coder bin), spezialisierte Programme, die sich nicht dauernd selbst aufrufen müssen und sonstigen Kram machen müssen, wären vermutlich um den Faktor 100 bis 1000 schneller, vor allem, wenn man mehrere Namen und anderes gleichzeitig abklopft. Der umgekehrte Weg á la "Personalabteilung von Siemens will wissen, wie viele Mitarbeiter einen Wikipedia-Account haben (...und an der Bürgschaft teilnehmen...)" dürfte zeitlich auch nicht mehr als 20 Minuten kosten.

presroi@tippy2:~$ time for y in $(seq 1960 1990); do for m in $( seq -w 1 12 );
 do for d in $( seq -w 1 31); do echo -n "$d$m$y: "; echo -n "Frank Schulenburg $d$m$y"|sha256sum; done done done | 
grep a87324b9103e7b55873a11b791afb001b6008355ab25cdbb7fe1b88a8dd35005

19051969: a87324b9103e7b55873a11b791afb001b6008355ab25cdbb7fe1b88a8dd35005  -

real    1m36.583s
user    1m6.984s
sys     0m37.886s

-- Mathias Schindler 13:20, 9. Feb. 2008 (CET)

<quetsch> Ich habe ein paar Newlines in den Einzeiler hinzugefügt, sonst wird die Seite hier sehr breit --Church of emacs ツ ⍨ 17:18, 9. Feb. 2008 (CET)

verstehe wieder kein Wort ;O) So please demonstrate with my data - Code steht da, Name sollte dir bekannt sein: Wann hat selbiger Geburtstag? -- Achim Raschka 13:29, 9. Feb. 2008 (CET) - P.S.: Lösung

Also. Die Programmzeile von mir da oben macht genau das: Von einer Person, deren Namen bekannt ist, das Geburtsdatum herausfinden. Und natürlich gibt es genug Leute, die damit kein Problem haben. Es sollte halt nur gesagt werden, dass jemand, der sich diese ID zulegt, nicht damit rechnen sollte, dass die dort darin hinterlegten Informationen nicht für jederman zugänglich sind. -- Mathias Schindler 13:44, 9. Feb. 2008 (CET)

Wer seine Anonymität wirklich wahren möchte, der wird hier nicht seinen Vornamen herausposaunen. Und das Geburtsdatum von Achim kenne ich ohnehin :-) Also: Errechne mal bitte alle Angaben von einem Pseudonym-Account, von dem du nicht den Vornamen kennst. --Frank Schulenburg 14:32, 9. Feb. 2008 (CET)

Wenn von dem Klartext keine einzige Information bekannt ist, wird das natürlich schwieriger. Man kann das durch Wörterbuchangriffe natürlich sehr gut eingrenzen. --Mathias Schindler 14:43, 9. Feb. 2008 (CET)

Naja, wer seine Anonymität so wirklich wahren möchte, wird nicht einfach Personalausweise rumzeigen... Das Verfahren ist ja eh nur für Leute, die fast ihre Anonymität wahren möchte und ich würde mal davon ausgehen, dass die Gruppe derjenigen die ihren Vornamen, nicht aber Nachnamen und Geburtsdatum bekannt geben will, zumindest vorhanden ist. Klappt das eigentlich auch mit Geburtsdatum und ohne Namen? -- southpark Köm ? | Review? 14:39, 9. Feb. 2008 (CET)

Es gibt einen Unterschied, ob eine Person den Namen nur im direkten Kontakt zwischen zwei Leuten zeigt oder "potentiell in die ganze Welt herausposaunt". Wenn ich weder Vornamen noch Nachnamen, noch Geburtsjahr habe, ist das schon etwas aufwändiger. mdcrack schafft 42 Millionen md5-hashes pro Sekunde. Wie schnell das Ding bei SHA256 ist, weiss ich nicht. Gehen wir mal von 1 millionen hashes pro Sekunde aus:

1 Jahr = 356. Wir wissen, dass die Leute in der Regel zwischen 16 und 56 Jahre alt sind. Nehmen wir die 1000 häufigsten Vornamen und die 1000 häufigsten Nachnamen, brauchen wir 3,9 Stunden für die möglichen Kombinationen. Und ja, das war eine wahnsinnig grobe Rechnung. Wenn es nachher 3,9 Tage sind oder nur mit den 500 häufigsten Vor- und Nachnamen klappt, seis drum.-- Mathias Schindler 15:01, 9. Feb. 2008 (CET)

-- Mathias Schindler 14:43, 9. Feb. 2008 (CET)

Eine zumindest teilweise Hilfe kann hier tatsächlich ein Salt sein. Im normalen Klartext kommen beispielsweise keine Klammern vor. Statt "Mathias Schindler 06111981" könnte man also einen Salt einfügen, den ich nur angeben muss, wenn ich im direkten Kontakt einen Bürgen suche. Der Klartext könnte dann zum Beispiel "Mathias Sch{Brockhaus ist eine witzige Firma}indler 06111981" lauten, damit wäre das stupide Durchprobieren der Hashes nicht mehr praktikabel. -- Mathias Schindler 14:47, 9. Feb. 2008 (CET)

Damit das mit dem Ansatz dieses Systems noch vereinbar ist, müsste der Salt neben dem Hash veröffentlicht werden, womit, wenn ich das nicht völlig falsch verstehe, wieder einiges an Sicherheit verloren geht. sebmol ^{? !} 14:54, 9. Feb. 2008 (CET)

(nach zweimaligem BK) Jeder entscheidet eben über den Grad seiner Anonymität selber. Tatsache ist: System A (Carl) ist kinderleicht auszutricksen und bei System B (Markus) ist das Geburtsdatum zu errechnen, wenn man seine Anonymität durch Angabe des Vornamens ohnehin teilweise aufgegeben hat und darüberhinaus einen gängigen Nachnamen hat. Da ist es dann eine persönliche Entscheidung, was einem wichtiger ist.

Ein viel wichtigerer Punkt: Bisher haben sich sowohl bei System A und B nur Nutzer eingetragen, die ich zu 90% persönlich kenne. Besondere Aussagekraft hat das ganze (zumindest für mich) bisher nicht. --Frank Schulenburg 14:54, 9. Feb. 2008 (CET)

*quetsch* Ich denke, bei dem System hier ist das ganz natuerlich. Ich werde mich wohl erst dann eintragen, wenn ich eine vage Chance sehe, dass ich in nicht allzu ferner Zukunft ein paar Leute treffen kann, die wenigstens Vollbuergen sind. Bis dahin muss das System erst einmal in Fahrt kommen (d.h. ein Netz von Vollbuergen existieren sein) - da wird wohl noch einiges Wasser den Edo-Fluss hinablaufen. -- Arcimboldo 04:43, 22. Feb. 2008 (CET)

und was ist mit jemand, der sich nicht eintragen möchte? ist er dann in zukunft ein benutzer 2. klasse? irgendwie verdächtig? darf der zukünftig irgendwas nicht mehr? contra-grund bei adminwahlen?--poupou review? 15:01, 9. Feb. 2008 (CET)

Die Frage stellt sich doch gar nicht. Das System gibt dir die Möglichkeit eine 1:1-Bezeihnung von Personen zu Accounts herzustellen; es sagt dir also, dass Benutzer:Achim Raschka eindeutig eine real existierende Person ist während du diese Auskunft über Benutzer:plusterms, Benutzer:Necrophorus und Benutzer:Bambee Rap-tor nicht hast (und bei den dreien wohl auch nie bekommen wirst). Es gibt dir aber keine Auskunft darüber, dass ein Benutzer:Bambee Rap-tor (so eine reale Person ohne anderen Hauptaccount dahinterstehen sollte) ein schlechterer Account ist als der verifizierte Achim Raschka. Was du aus dieser Information für deinen Umgang mit Achim Raschka und Bambee Rap-tor ziehst bleibt dir ebenso selbst überlassen wie für den Umgang mit anonymen IP-Nutzern. Ob es irgendwann tatsächlich mal Konsequenzen haben sollte und bsp. nur noch eindeutig zuordnenbare Personen zu Adminwahlen zugelassen werden oder abstimmen dürfen, ist eine Entscheidung der Community und ihres Konsens – und einen entsprechenden Konsens würde ich in den nächsten 5 Jahren nicht erwarten -- Achim Raschka 15:12, 9. Feb. 2008 (CET)

naja, wenn die entscheidung hier mitzumachen, eine entscheidung darüber ist, wieviel anonymität man preisgeben möchte, ist das schon ein ansatz, der für mich dem bisherigen grundsatz des projektes, dass jeder auch vollkommen anonym an allem teilnehmen kann, widerspricht. ich möchte einfach ungern über die hintertür zur öffentlichen preisgabe irgendwelcher persönlicher daten kommen.--poupou review? 15:34, 9. Feb. 2008 (CET)

Zweifelhafte Anonymität

Eine Sache, die mir bei dem Vorschlag aufgefallen ist: Wenn jemand mich aus dem realen Leben kennt und mein Geburtsdatum herausfindet, dann kann er damit sehr einfach feststellen, was für ein Benutzerkonto ich in der Wikipedia habe. Die Anonymität funktioniert somit nur in die eine Richtung, also dass niemand von meinem Benutzerkonto auf meine reale Person schließen kann, aber anders herum wird sie durch die Bürgschaft zunichte gemacht (schließlich kann jeder nach "site:de.wikipedia.org [Hash von Name+Geburtsdatum]" googeln). Nicht, dass mich das in irgendeiner Weise betreffen würde, aber ich finde das sollte man schon in dem Vorschlag erwähnen. --Church of emacs ツ ⍨ 12:56, 9. Feb. 2008 (CET)

Das ist meiner Meinung nach ein ziemlich gewichtiger Einwand. sebmol ^{? !} 14:33, 9. Feb. 2008 (CET)

Mit dem einfügen eines Salt wie Mathias oben vorschlägt wäre auch dieses Problem behoben, oder? --Nina 14:51, 9. Feb. 2008 (CET)

Ja, ich habe die sonstige Diskussion oben nicht besonders verfolgt (aber mir gerade nochmal angeschaut). Prinzipiell ist das ein ähnliches Problem, dass nur durch einen geheimen Salt gelöst werden kann. Sowas wie Hash[Hash[Name+Geburtsdatum]+Geheimes Passwort]. Das geheime Passwort wäre dann der Schlüssel zum Erstellen der Hashes, den nur ein Mitarbeiter der WMF hat. Problem ist natürlich, dass damit die ganze Geschichte sehr intransparent wird. --Church of emacs ツ ⍨ 15:28, 9. Feb. 2008 (CET)

Mathias' und Churchs Einwände sind sehr ernst zu nehmen - das liebe ich so an öffentlich diskutierten Fragen über Kryptographie (letztlich gehört es ja dazu), dass man immer wieder merkt, woran man alles nicht gedacht hat.

Ein Salt ist hier die einzige Lösung, um den Datenschutz zu retten, aber es muss ein Salt sein, der entweder aus den Dokumenten eindeutig hervorgeht oder ein nicht-trivial für Dritte einsehbares biometrisches Merkmal, um die Eineindeutigkeit von Hash zu Person weiterhin zu gewährleisten. Hm... mal nachdenken. --Markus Mueller 15:36, 9. Feb. 2008 (CET)

Der Personalausweis enthält irgendwelche Nummern, da könnte man sich ein paar raussuchen (z.B. jede zweite Ziffer). Dann muss der Angreifer schon meinen Perso haben oder eine Kopie davon, damit ihm das was nützt. --Church of emacs ツ ⍨ 15:43, 9. Feb. 2008 (CET)

Der einzige Salt, der eindeutig aus allen amtlichen Papieren (Ausweis, Pass, Führerschein) hervorgeht und nicht trivial ist, ist der Geburtsort - und den könnte man dann bsp. an beliebiger Stelle im Code einsetzen. -- Achim Raschka 15:45, 9. Feb. 2008 (CET)

Ja, an den Geburtsort hatte ich gedacht, aber das erlaubt aber leider immer noch die rekursive Suche nach Klarnamen von Benutzern, wenn es sich z.B. um meinen Angestellten, meine Ex-Freundin oder meinen Professor handelt. --Markus Mueller 15:47, 9. Feb. 2008 (CET)

Jeder Account hier hat doch eine eindeutige Benutzer-ID (über Einstellungen). Wie wäre es damit? --Frank Schulenburg 15:51, 9. Feb. 2008 (CET)

Oder der Nick selbst? --Fritz @ 15:53, 9. Feb. 2008 (CET) - Nee, Denkfehler, man könnte durch Probieren mit allen Accounts in der Liste doch auf das Ergebnis kommen. Wäre allerdings recht aufwendig... --Fritz @ 15:54, 9. Feb. 2008 (CET)

Neinein, über die Accountschiene (Nr, Name etc.) kommst man nicht weiter, weil Sockenpuppe(n) und Hauptaccount dann unabhängig voneinander bestätigt werden können. Verletzt die Eineindeutigkeit. --Markus Mueller 15:55, 9. Feb. 2008 (CET)

(nach BK)

Ist dem so; Wenn mein Code bsp. durch den Geburtsort modifiziert wird in Achim Ra{Bad Neuenahr}schka 25011969, weil ich als Salt-Position die Stelle nach dem ersten Vokal im Nachnamen wähle. Arbeitgeber haben alle Daten meines Ausweises (in Form einer Kopie), dementsprechend gibt es kein Salt, dass der Arbeitgeber nicht kennen kann und das in amtlichen Papieren vorkommt. Mann könnte das Salt natürlich auch WP-spezifisch machen: Bsp: Drittes Wort des ersten Beitrags des Benutzers, der verifiziert wird ... -- Achim Raschka 15:53, 9. Feb. 2008 (CET)

Bringt nichts, weil der Angreifer das genauso rekonstruiert wie Du das konstruierst. --Markus Mueller 15:55, 9. Feb. 2008 (CET)

Wp-spezifisch nützt leider nichts, weil Account und Person dann nicht mehr eineindeutig wären. --Markus Mueller 15:57, 9. Feb. 2008 (CET)

Tscha, dann bleibt nur noch die Geheimwaffe: Die Code-CD - der vierte Track einer definierten Musik-CD, die nur dem Identifiziertem und den Bürgen bekannt ist und vom Ersteren in Ehren gehalten werden muß sein Leben lang -- Achim Raschka 15:59, 9. Feb. 2008 (CET) Bsp.: Achim Ra{I'm in the mood}schka 25011969

oder die Lieblingsfarbe… *g* --Frank Schulenburg 16:02, 9. Feb. 2008 (CET)

Auch das nicht. Es darf nichts sein, was nur Bürge und Verbürgtem bekannt ist, weil ich sonst beim nächsten Bürgen etwas anderes angeben kann (mit anderem Accoun natürlich). Es muss etwas sein, was alle Bürgen bei allen Verbürgenden überprüfen können.

Was mir bisher eingefallen ist, dass man mit Hilfe der großen Handlinien einen eindeutigen Zahlenwert konstruiert (als Beispiel bitte mal diesen Handabdruck ansehen: http://www.playbush.de/hand.htm). Man müsste sich nur ein Verfahren überlegen, was a) extrem einfach nachzuvollziehen ist und b) robust genug ist, um in jedem Fall ein eindeutiges Ergebnis zu liefern. --Markus Mueller 16:12, 9. Feb. 2008 (CET)

Ich zitiere: „Der Personalausweis enthält irgendwelche Nummern, da könnte man sich ein paar raussuchen (z.B. jede zweite Ziffer). Dann muss der Angreifer schon meinen Perso haben oder eine Kopie davon, damit ihm das was nützt.“ Wieso kann man das nicht machen? Wäre auch gut das zu klären, bevor wir uns in Berlin treffen. —DerHexer (Disk., Bew.) 16:20, 9. Feb. 2008 (CET)

Gerade der als Beispiel genannte Arbeitgeber hat immer eine Kopie des Ausweises. Wir klären das schon – und wenn nicht gibts trotzdem lecker Currywurst -- Achim Raschka 16:22, 9. Feb. 2008 (CET)

Also nö, wenn ich anfangen muß, biometrische Daten zu erfassen, indem ich Handlinienkreuzungswinkel messe oder Augenbrauenhaare zähle, wird selbst mir irgendwann das Verhältnis von Kosten und Nutzen inplausibel. Ausweis o.ä. gerne, Wp-spezifisches und evtl. einen besonderen Gimmick auch - aber alles darüber hinaus wird echt unspaßig -- Achim Raschka 16:21, 9. Feb. 2008 (CET)

Ja, schön ist das alles nicht, ich weiß. Da auch der Perso nicht Grundvoraussetzung sein soll (was machen dann unsere ausländischen Mitarbeiter?), bleiben wohl nur weitere Dokumente als Quelle für Werte. Mit Geburtsort könnte man zumindest schonmal sehr viele Unbefugte ausschließen. Wenn alle Menschen einen Führerschein hätten, könnte man das Erwerbsdatum der Fahrerlaubnis eintragen, aber da erzähle ich dem nächsten Bürgen, dass ich keine solche besitze und habe schon 2 Hash-Identitäten. Mädchenname der Mutter ist für die Kinder schwer sicher nachzuweisen. Sonst noch jemand Ideen? --Markus Mueller 16:28, 9. Feb. 2008 (CET)

mm, ich könnte in dem Berechnungstool einen Salt miteinrechnen. Der wäre dann für jede Person gleich, aber jedem außer mir unbekannt. Dann könnte niemand mehr mittels bekannten Daten auf den Benutzernamen schließen und auch das Geburtsdatum könnte man nicht mehr errechnen (sofern man nicht mein Tool dazu missbraucht).

Nachteil: Alle müssten nochmal ihren Hash berechnen (weil der sich ja ändert) und ihr müsstet eben darauf vertrauen, das ich keinen Mist baue. --DaB. 16:23, 9. Feb. 2008 (CET)

Ist 'ne gangbare Idee, erfordert aber das Vertrauen, dass Du nicht mitloggst oder den Salt absichtlich oder unabsichtlich verrätst (oder jemand auf dem Weg mitbekommt) und ist dann für alle Zukunft von Deiner Person abhängig. Das geht aber schon in eine gute Richtung, wie kann man das vielleicht noch verbessern? --Markus Mueller 16:30, 9. Feb. 2008 (CET)

Wie wäre es, wenn man die Ausgangsphrase aufteilt, so dass sie aus Plaintext + Salt besteht. Die Bürgen sollten dann Plaintext und Salt getrennt prüfen können, der Key aus Kombination beider Elemente gebildet. Über den Plaintext lassen wir noch ein zweites Hash-Verfahren laufen, nehmen aber z.B. nur jede 2. oder 3. Ziffer als Prüfsumme. So ist es unmöglich, aus der Prüfsumme den Hash zu rekonstruieren, aber Bürgen könnten den Hash erzeugen und daraus die Prüfsumme wieder herstellen. Mathias? --Markus Mueller 16:35, 9. Feb. 2008 (CET)

Nur woraus soll der Salt bestehen? --DaB. 16:38, 9. Feb. 2008 (CET)

Für mein meta-Passwort hab ich Zufallszahlen, -buchstaben und -zeichen per Steganos Passwort-Manager in einer Stärke von 128bit per Mausbewegung über den Bildschirm anlegen lassen. Das sollte doch auch hier möglich sein. —DerHexer (Disk., Bew.) 16:41, 9. Feb. 2008 (CET)

Ja, natürlich. Nur kann man das dann nicht mehr nachrechnen. Es geht doch in der Debatte darum, das sowohl jemanderman den Hash erzeugen können muss (zum Bürgen), andererseits es schwer sein soll, aus (teilweise) bekannten Daten auf andere Teildaten oder den Hash zu schließen. --DaB. 16:43, 9. Feb. 2008 (CET)

Zur Identifizierung können doch die Daten beim Treffen notiert werden oder auch gleich in dein Programm eingegeben werden. Denn da ist doch der Salt drin. Dann vergleicht man die Hashs. Meinungen dazu? —DerHexer (Disk., Bew.) 16:46, 9. Feb. 2008 (CET)

(BK) @DaB.: Ein geheimer Salt ist – wie ich oben schon geschrieben habe – imho die einzige Möglichkeit die Anonymität zu bewahren. Einzig der Person, die den geheimen Salt besitzt, muss vertraut werden (was unter Umständen für manche schon eine Einschränkung bedeuten könnte). Für mich stellt sich die Frage, ob das praktikabel ist: 5 Personen nehmen Name+Geburtsdatum auf, leiten den Hash davon auf kryptographisch gesichertem Wege an eine zentrale Vertrauensperson weiter; diese Person fügt den geheimen Salt hinzu, bildet wieder den Hash und veröffentlicht das Ergebnis. Ein bisschen viel Theater für ein paar Sockenpuppen --Church of emacs ツ ⍨ 16:44, 9. Feb. 2008 (CET)

Es ging vielleicht einen Tick einfacher. Man veröffentlicht den mit SHA-256 generierten Schlüssel (ohne Salt) nicht, sondern sendet ihn an die zentrale Instanz. Diese prüft auf Kollisionen und schickt den Key mehrfach durch andere Kryptoverfahren, die unbekannt sind. Das Ergebnis wird veröffentlicht. --Markus Mueller 16:57, 9. Feb. 2008 (CET)

Das ist eigentlich ziemlich gleich zu dem, was ich vorgeschlagen habe... --Church of emacs ツ ⍨ 17:03, 9. Feb. 2008 (CET)

Oh Gott, ich brauch mehr Kaffee. Mehr Kaffee! --Markus Mueller 17:07, 9. Feb. 2008 (CET)

• Okay, neue Idee. Es gibt zwei Schlüsselarten. Wer auf Anonymität nicht angewiesen, verwendet den PIS. Wer hohe Anonymität und Datenschutz haben will, der bekommt einen SPIS (Sicherer PIS). Der funktioniert so, wie Church vorgeschlagen hat. Die zentrale Instanz wählt ein symmetrische Verschlüsselungsverfahren, so dass sie aus dem SPIS irgendwie wieder einen PIS machen kann, bzw. zu jedem PIS einen SPIS, um auf Kollisionen zu prüfen. --Markus Mueller 17:11, 9. Feb. 2008 (CET)

Klinkt ok. Aber warum dann nicht gleich für alle anonym? --Church of emacs ツ ⍨ 17:14, 9. Feb. 2008 (CET)

Ich hab nun mein Programm mal so modifiziert, das es auch einen gesalzenen hash mit ausgibt. Könnte ja mal etwas mit rumspielen. Um das 1 Personenproblem zu lösen, könnte ich ja den Hash in der Geschäfststelle in einem versiegelten Umschlag hinterlegen - dann könnte das System auch weiterleben, wenn mir was passieren sollte und das Tool gewartet werden muss. --DaB. 17:12, 9. Feb. 2008 (CET)

Und wenn die bösen Sockenpuppenterroristen kommen und den Umschlag klauen? :P --Church of emacs ツ ⍨ 17:16, 9. Feb. 2008 (CET)

Okay, dann hätten wir einen Hash und einen S-HASH, und jeder könnte sich überlegen, ob er lieber den PIS oder den Salted-PIS verwenden will. Problem jetzt: Dein Tool liefert mir jetzt zu jedem gegeben Plaintext beide Hashes. ist das nicht eine sehr gute Angriffsmöglichkeit, da mit Plaintext und normaler Hash bekannt sind und ich nur den Salted-Hash noch zuordnen muss? (Dass man den Salt errechnet, ist wohl auch ein möglicher Angriff, aber vermutlich nicht so leicht) --Markus Mueller 17:17, 9. Feb. 2008 (CET)

Der normale Hash bleibt natürlich nur solange drin, bis wir uns geeinigt haben, das Verfahren umzustellen. --DaB. 17:19, 9. Feb. 2008 (CET)

Ich habe immer noch nicht verstanden, warum manche mit sicherem (gesalzenen) Hash rumlaufen sollen, und andere nicht. Salz für alle! --Church of emacs ツ ⍨ 17:20, 9. Feb. 2008 (CET)

Davon gehe ich auch aus. --DaB. 17:21, 9. Feb. 2008 (CET)

Mir fällt auf, dass hier vor allem um die RL-Anonymität gerungen wird. Wie ich unten anführte, halte ich die Umkehrung für problematisch - jemand, der deine RL-Daten kennt ( zB. Arbeitgeber) sowie das Verfahren, kann damit den WP-Nick finden und somit ein Userverhalten nachvollziehen. Schön für den Arbeitgeber wenn er sehen kann, was jemand während des Krankenstandes macht. Solange das nicht auszuschließen ist, halte ich dieses Verfahren - so verlockend es insgesamt vom Ergebnis her scheint - für unannehmbar. Ein Tool, welches in der Verifizierung die BenutzerID im Hintergrund unsichtbar miteinbezieht, wäre wahrscheinlich das sinnvollste. Diese ID kann niemand ohne Kenntnis des Nicks wissen. --Hubertl 05:38, 10. Feb. 2008 (CET)

Sie darf aber im Hash keine Rolle spielen, weil ja sonst mit jedem Benutzeraccount einen anderen bekomme.

Der gesalzene Hash hilft auch nicht, da ihn ja jeder aus den Grunddaten V+N+GD generieren können muss. (Wenn ich das richtig verstanden habe und nichts übersehen habe in der Disk)

Einzige halbwegs akzeptable Lösung: gesHash wird wie gehabt generiert, verlässt aber das System nicht. Der Benutzer gibt einmal V+N+GD und seinen Benutzernamen ein und der sHash wird unter seinem Benutzernamen gespeichert. Zur überprüfung gibt mann wieder alles ein und bekommt dann nur ein "passt" oder "passt" nicht zurück und kann vielleicht in der Datenbak gleich zusätzlich eintragen, dass man es überprüft hat. Da es ein gesHash ist, kann auch niemand etwas mit der Datenbank anfangen. Und im Programm wird es hoffentlich auch irgendwie verschlüsselt hinterlegt sein. Und das Salz kommt eben auch noch in den Tresor. Aber auf einer WP-Seite veröffentlichen oder den gesHash anzeigen ist nicht drin. --Franz (Fg68at) 10:25, 14. Feb. 2008 (CET)

zweck?

mir wird aus dem text auf der vorderseite noch nicht ganz klar, wofür wir das brauchen, bzw. was es uns nützt, wenn es das gibt. wäre es möglich, das nochmal etwas klarer, möglichst mit beispielen, darzustellen? an welcher stelle des projekts würde durch dieses system eine vereinfachung oder verbesserung eintreten?--poupou review? 14:52, 9. Feb. 2008 (CET)

Wenn du verbürgt bist, kannst du damit nachweisen, dass du keine Sockenpuppe bist --Church of emacs ツ ⍨ 16:37, 9. Feb. 2008 (CET)

und? -- southpark Köm ? | Review? 17:58, 9. Feb. 2008 (CET)

Ich glaube, auf lange Sicht steckt dahinter, dass nur mehr verbürgte User (Nicks) bei Abstimmungen teilnehmen können. Wogegen ich vorerst einmal nichts hätte, falls nicht gewichtige Argumente dagegen sprechen. --Hubertl 05:41, 10. Feb. 2008 (CET)

Salt-Prüfsummen-Verfahren

Nochmal im Detail, wie ich mir das sicherere Verfahren vorstelle. Wir teilen die Ausgangsphrase in Vorname, Name, Geburtstag und Salt auf. Ich wähle als Salt mal "Gargoyle". Die Ausgangsphrase sieht dann bei mir so aus:

"Markus Mueller 28021972 Gargoyle"

Der SHA-256-Hash darüber ist 8b1e6e2d98ab67b3fae4dc781c710efedae6788ee91c744a5ac7d242dd54a0d7 und ohne den Salt für niemanden zu erraten (wobei ich besser eine zufällige Zahlen-Buchstabenkombination als Salt gewählt hätte, aber mal für den Moment...)

Außerdem bilde ich jetzt noch die MD5-Summe über den ersten Teil "

"Markus Mueller 28021972"

Die MD5-Summe ist fe36b4097e639f0de4c247cc0e18217b. Statt diese aber nun komplett zu veröffentlichen, was den Angriff ermöglichen würde, nehme ich jetzt nur jede dritte Ziffer, das wäre:

f60e9dc7087

Diese Prüfsumme veröffentlichen wir zusammen mit dem PIS. Die Bürgen können nun, wenn sie die Dokumente überprüfen, die Ausgangsphrase ohne Salt auf Korrektheit überprüfen. Niemand kann also durch Veränderung des Salt zwei Identitäten vortäuschen, weil die Prüfsumme immer gleich bliebe. Auf der anderen Seite kann man aus dem verstümmelten Hash, der Prüfsumme, nichts rekonstruieren. --Markus Mueller 16:43, 9. Feb. 2008 (CET)

IMHO ein Denkfehler drinne, da der Angreifer ja auch einfach jede dritte Ziffer nehmen kann --Church of emacs ツ ⍨ 16:48, 9. Feb. 2008 (CET)

Nur gibt es jetzt sehr viele Ausgangstexte, auf die der hash zutrift. --DaB. 16:51, 9. Feb. 2008 (CET)

Nein, Church hat recht. Wir gehen davon aus, dass der Plaintext bekannt ist, ich den Nutzernamen finden will, daraus kann ich die Prüfsumme schon im vorhinein konstruieren. --Markus Mueller 16:59, 9. Feb. 2008 (CET)

Ja, bei diesem Angriffsszenario gibt es gar keine Probleme bezüglich jeder dritte Buchstabe --Church of emacs ツ ⍨ 17:02, 9. Feb. 2008 (CET)

(BK) Ist richtig, aber wie viele Ausgangstexte gibt es, die in der Form „[üblicher Vorname] [üblicher Nachname] [1-31][1-12][1900-200]“ aufgebaut sind? --Church of emacs ツ ⍨ 17:01, 9. Feb. 2008 (CET)

Für diese spezifische Prüfsumme sicher nur diesen einen. Selbst wenn es mehrere gibt: für den Angreifer ist die Wahrscheinlichkeit, dass sich hinter dem Pseudonym, was dem PIS zugeordnet ist, die gesuchte Person befindet, etwa 99,9999999%. Das ist ungefähr so, wie eine DNA-Überprüfung vor Gericht: bei einer Übereinstimmung kommst Du mit dem Hinweis auf das Geburtstagsparadoxon nicht mehr da raus, weil Du nämlich nicht irgendwer, sondern *der* Verdächtige bist. --Markus Mueller 17:04, 9. Feb. 2008 (CET)

Alternativvorschlag: Wir machen DAB's tool verbindlich, erzeugen einen langen (2048 Bit) geheimen Salt - dieser ist nur DAB. bekannt - und lassen das Tool den Hash berechnen. Das Tool wird zusätzlich mit einem Captcha versehen um automatisiertes massenhaftes Erstellen und damit einen Bruteforce-Angriff zu verhindern. Da der Salt nimandem zum überprüfen (geht ja mit dem Tool) bekannt sein muss, die Kentniss des Salts jedoch zwingend notwendig ist um den Hash zu berechnen kann nimand versuchen an Namen, Vornamen und Geburtstag zu gelangen. ⑊ C-M ^hä? 17:19, 9. Feb. 2008 (CET)

Kryptographisch hier kein Widerspruch, das Hauptproblem ist aber, dass ständig die Daten über das Netz gehen. Selbst wenn wir https oder ähnliches verwenden, bleibt den „Paranoikern“ das Argument, dass die Daten mitgeloggt werden. Und gerade das Problem der „Paranoiker“ (Anonymität) wollten wir doch gerade lösen... da haben wir also keinen Boden gutgemacht leider. --Markus Mueller 17:23, 9. Feb. 2008 (CET)

• Frage: gäbe es denn keine Möglichkeit, mit einem Public-Key-Verfahren diesen Salt irgendwie so zugänglich zu machen, das man den PIS selbst erzeugen könnte, ohne den Hash selbst zu kennen? --Markus Mueller 17:26, 9. Feb. 2008 (CET)

IMHO nein. Ein Schlüssel muss bei einem asymetrischen System geheim bleiben. Da man aber sowohl den Schlüssel zum Verschlüsseln (für die hasherstellung) als auch den Schlüssel für die Entschlüsslung (zum Hash-Überprüfen) braucht, geht das hier nicht. --DaB. 17:30, 9. Feb. 2008 (CET)

Reine Verständnisfrage: der supergeheime und extralange Salt-Wert steht natürlich im Java-Code des Tools auf dem Toolserver und ist damit jedem der sehr vielen TS-Accountinhaber zugänglich. Yes or no? — ^PDD — 17:27, 9. Feb. 2008 (CET)

Jain. Im Moment steht er noch im Bytecode des tools. Theorethisch könnte jeder TS-User den Code nehmen und decompilieren und da den Code finden. Wenn wir aber ernst machen, dann lager ich den Key in eine Datei aus. Dann können nur noch die TS-Admins den Key lesen. Ich könnte das Tool aber auch auf meinen Server umziehen, wenn ihr das wollt. Dann komm nur ich an den Key. --DaB. 17:33, 9. Feb. 2008 (CET)

Public-Key wäre eine Möglichkeit. Also: 1. Personengruppe erstellt über Brute-Force angreifbaren Hash; 2. Hash wird mit DaB's Public Key verschlüsselt; 3. Der Key wird übersendet. Vorteile: Die übersendeten Informationen sind dank langem key quasi nicht angreifbar. Wer den private key von DaB. stibizt, kann auch nicht die Daten einfach so herausbekommen, sondern muss immerhin Brute-Forcen --Church of emacs ツ ⍨ 17:32, 9. Feb. 2008 (CET)

Nee, irgendwie macht das alles kein Sinn. Egal was man macht, in dem Moment in dem irgendwelche Hashes öffentlich werden, ist Brute Force möglich --Church of emacs ツ ⍨ 17:35, 9. Feb. 2008 (CET)

Ich dachte eher an folgendes:

1. Man erzeugt den Hash über den Plaintext
2. Man verschlüsselt den Hash mit einem Public Key
3. Das Ergebnis schickt man einen Mailserver, der die Mail automatisch auswertet
4. Der Server entschlüsselt die verschlüsselte Mail, nimmt den Hash, fügt einen Salt an und Hashed erneut
5. Der Server sendet den neuen Hash per Mail zurück

So bekommt nur 1 Instanz den Hash, aber niemand den Plaintext. Oder habe ich jetzt wieder einen Denkfehler gemacht? --Markus Mueller 17:39, 9. Feb. 2008 (CET)

Ist aber dann SEHR aufwändig. Sowohl für den Ersteller, als auch für alle Leute, die den Hash danach prüfen wollen. --DaB. 17:42, 9. Feb. 2008 (CET)

Wenn jemand an Stelle 2 die Nachricht abfängt, kann er Brute-Forcen. --Church of emacs ツ ⍨ 17:44, 9. Feb. 2008 (CET)

Äh, gegen den Hash, der im Container der PGP-Verschlüsselung liegt? Ich denke nicht, wenn man einen 8192bit-Key verwendet. --Markus Mueller 17:46, 9. Feb. 2008 (CET)

Man braucht zum Brute-Forcen ja auch nicht den private key, sondern nur den public key. Man brute-forcet einfach mal publicKey[Hash[üblicher Vorname] [üblicher Nachname] [1-31][1-12][1900-200]] --Church of emacs ツ ⍨ 17:50, 9. Feb. 2008 (CET)

wie wäre es, wenn man statt Public Key ein OTP verwendet? Der Server sendet für einen einzelnen Verschlüsselungsvorgang einen sehr einfachen Einmal-Key, der mit einem sehr einfachen Verfahren zur Veränderung des Hashs verwendet wird und nach kurzer Zeit oder direkt nach Benutzung verfällt? --Markus Mueller 17:52, 9. Feb. 2008 (CET)

Bitte, wer soll solch ein komplexes Verfahren noch durchführen wollen? --DaB. 17:54, 9. Feb. 2008 (CET)

Nein, das soll ja einfacher werden als das PK-Verfahren. Das soll so funktionieren: ich rufe den toolserver auf, der spuckt mir eine vierstellige Zahl aus. ich nehme den Hash, verändere ihn mit dieser Zahl und sende das Ergebnis an den Server. Der Server stellt selbständig den ursprünglichen hash wieder her, führt das obige Verfahren aus und gibt den fertigen Key aus. --Markus Mueller 17:56, 9. Feb. 2008 (CET)

Dann kan mein Tool aber auch gleich obrige Sachen durchführen. Den es ist bereits im Besitz des hashes - du hast dem Tool also schon alle vertraulichen Daten gezeigt. Ob es nun dann auch noch den Salt kennt und deinen hash damit salzt ist doch egal. --DaB. 18:02, 9. Feb. 2008 (CET)

Im Grunde genügt es, wenn es einen sicheren Übertragungsweg gibt (https). Was wir gewinnen müssen zum jetzigen Tool auf dem toolsever ist zweierlei: 1. Abfangen sehr, sehr schwer machen, 2. keine Übermittlung der Daten im Klartext, sondern nur des Hashs, so dass beim Bekanntwerden die Daten nur sehr schwer rekonstruierbar sind. Den dritten Punkt, dass der öffentliche Schlüssel wertlos ist, garantieren wir mit dem Salt. --Markus Mueller 18:05, 9. Feb. 2008 (CET)

Was hälst du davon, wenn ich zusätzlich zu den jetzigen Felder die Möglichkeit hinzufüge, den fertigen Hash zu übermitteln und mein Tool saltet den dann nur noch? Dann können die Leute, die mir nicht vertrauen, den Hash selber auf ihrem PC berechenen, ihn in mein Tool eingeben und erhalten den gesalzenen hash zurück. Und die weniger "paranoiden" können weiterhin die Daten in meinem Tool eingeben, das daraus den Hash berechnet und den auch gleich salzt. --DaB. 18:10, 9. Feb. 2008 (CET)

Klingt für den Moment nach einer guten Lösung. Langfristig könnte man noch ein supersicheres drittes verfahren mit OTP oder secure http anbieten, für die ganz Paranoiden. Aber das hätte erstmal keine Eile, sondern kann noch in Ruhe durchdacht werden. --Markus Mueller 18:16, 9. Feb. 2008 (CET)

Der Vorteil ist natürlich auch, dass die bereits erzeugten Schlüssel und Verbürgungen damit gültig bleiben. Nur falls die Berliner jetzt mitlesen und gar nicht mehr wissen, was los ist. ;-) --Markus Mueller 18:29, 9. Feb. 2008 (CET)

Mal umgekehrt gedacht: (erl., wurde schon oben angesprochen)

Jeder Arbeitgeber kennt die für den Hash geforderten Daten. Nun möchte dieser Arbeitgeber herausfinden, ob zufällig einer seiner Angestellten (den er vielleicht im Verdacht hat) aktiver Wikipedianer ist oder nicht. Und vor allem, wie aktiv und auch vielleicht einmal während der Dienstzeit. Oder vielleicht in einem Zeitraum, wo der lb. Angestellte eigentlich das Bett wg. Krankheit hüten sollte. Oder wenn er einfach nur wissen will, was er so während seines Urlaubs macht (was ja das geringere Problem wäre). Oder er möchte einfach nur wissen, was so sein Angestellter tatsächlich für Edits durchführt. Streitkultur etc, Sperren.

Nun, er gibt einfach Vornamen, Namen und Geburtsdatum ein, generiert den hash und gleicht dies mit der Gesamtliste ab. Es kann gut sein, dass er ihn findet, damit weiß er aber auch, unter welchem Namen diese Person in Wikipedia aktiv ist. Um das zu vereinfachen bedarf es dann nur noch eines kleinen Programms, und mit einem Klick ist er auf der Seite der Benutzerbeiträge dieser Person.

Es reicht wahrscheinlich auch nur ein einziger Edit während der Arbeitszeit, um eine rechtsgültige, fristlose Entlassung auszusprechen, wenn es dem Arbeitgeber in den Kram passt. Er könnte das auch über seinen Server herausfinden, aber nicht, unter welchem Nick er in WP unterwegs ist.

Bin ich wirklich der erste, der dieses Problem erkennt?? --Hubertl 20:10, 9. Feb. 2008 (CET)

Um Mißverständnissen zu begegnen: Ich bin dringend für eine Lösung, die der hier beschriebenen Intention zugute kommt. --Hubertl 20:16, 9. Feb. 2008 (CET)

Um deine Frage zu beantworten: Nein, du bist nicht der erste, das steht schon weiter oben. Unter anderem von Church of Emacs beschrieben. -- Mathias Schindler 20:50, 9. Feb. 2008 (CET)

Danke, ich habs in der Masse der Diskussionsbeiträge einfach übersehen, hätte mich auch gewundert, wenn ich, der ich erst später in die Diskussion eingestiegen bin, das als Allererster herausgefunden hätte. Tja, Prior art --Hubertl 21:03, 9. Feb. 2008 (CET)

Siehe Abschnitt „Zweifelhafte Anonymität“ --Church of emacs ツ ⍨ 22:46, 9. Feb. 2008 (CET)

Zweck zum Zweiten oder Vielen Dank...

für den Crashkurs in (schwacher) Kryptographie. Jeder Hackernewbie hätte seine Freude. Aber selbst wenn das Verfahren nun "sicher" ist (was ich nicht glaube), will ich eines mal klar sagen: mich werden aus Prinzip keine zehn Pferde dazu kriegen, irgend jemandem im Zusammenhang mit Wikipedia meinen Ausweis oder sonstige biometrische Merkmale zu liefern. Schon schlimm genug, dass die das dürfen, so man denn nach usa will.
BTW: im Gegensatz zu Markus^[1] glaube ich keineswegs, dass man so mehr neue oder gar "bessere" Mitarbeiter gewinnt als verliert. Die Wikipedia wurde überhaupt nur groß, weil jeder auf dem Basar - anonym oder nicht - aktiv mitmachen kann, und eben nicht nur eine kleine handverlesene Redaktion in der Kathedrale. Insofern verlangt die oben schon mal gestellte Frage nach dem Zweck dringend eine befriedigende Antwort. --Schwalbe D•C•B 23:21, 9. Feb. 2008 (CET)

Ihr vermischt immer zwei Sachen, die nix miteinander zu tun haben: die Mitarbeit in der Wikipedia und dieses private Projekt hier. Ich mag inzwischen auch nicht mehr darauf antworten. Ignoriert es doch einfach und gut ist. Der Zweck ist: wir gucken erstmal, was dabei rauskommt, was es leisten kann und entscheiden dann. --Markus Mueller 23:36, 9. Feb. 2008 (CET)

entscheiden was? -- southpark Köm ? | Review? 23:45, 9. Feb. 2008 (CET)

Entscheiden, ob das für irgendwas gut sein kann oder nicht. Bei allen solchen sicherheitsrelevanten Verfahren ist es wichtig, sie unbedingt in freier Wildbahn zu testen. Sieht man ja, die erste große Sicherheitslücke ist sofort aufgefallen. Dann muß man ja auch sehen, wie soetwas angenommen wird und wie belastbar das ist. Das ist mit dem Zwillingsverfahren drüben ja genauso.

Wenn man Erfahrungen damit gesammelt hat, dann kann man überlegen, ob es Probleme gibt, die sich besser lösen lassen, wenn Benutzer verbürgt sind. Passives oder aktives Stimmrecht ist dabei doch nur das absolute hypothetisch denkbare Extrem, es ist m.E. unsinnig, sich darüber jetzt schon ernsthaft aufzuregen. Vielleicht ist es aber z.B. schön, wenn man auf seiner Benutzerseite eine Babelbox stehen hat, die „bescheinigt“, dass sich hier ein richtiger Mensch hinter verbirgt. Manche Menschen fühlen sich dann vielleicht wohler, weil sie dann wissen, dass sie sicher nicht mit der Sockenpuppe eines ihnen unbekannten anderen Benutzers kommunizieren. Vielleicht ergibt sich aber auch mal in der Zukunft eine Fragestellung, wo es hilfreich wäre zu eruieren, wieviel echte Personen beteiligt wären. Es gibt auch wissenschaftliche Interessen: möglicherweise können Wissenschaftler dann das Verhalten einer Gruppe von sicher voneinander unterscheidbaren Benutzern untersuchen, was bisher unmöglich ist.

Was mich ankekst ist schon wieder dieses reflexhafte erzkonservative Angstschnappen. Wir richten hier doch keinen orwellschen Überwachungsstaat ein. Das ist ein privates Projekt im Benutzernamensraum und es ist nicht weniger sinnvoll als das Vertrauensnetz, Babelboxen zur Herkunft oder Brummfußens Bewertungssystem. --Markus Mueller 00:00, 10. Feb. 2008 (CET)

Naja, selbst Brummfussens Projekt startete mit einer relativ deutlichen Ansage warum er das macht, ebenso wie die anderen. Und ein "wir exerzieren hier eine relativ aufwändige lösung zu einem problem, das es vielleicht gibt oder mal schauen oder wir wissen noch nicht auf jeden fall können wir darüber nichts sagen" schreit danach dass man sich entweder fragt ob ihr zuviel zeit habt oder ob ihr doch unbedingt provozieren wollt, dass man euch für den intransparentesten haufen östlich des mississppi hält. und ja, dass man vielleicht verrät, dass sowas wie stimmberechtigung als extremfall dran gebunden sein könnte, ist doch schon mal nett, sowas weiss zumindest ich auch gerne ohne dass ich es jemand aus der nase ziehen muss. -- southpark Köm ? | Review? 00:07, 10. Feb. 2008 (CET)

Man kann alles missbrauchen. Du kannst die Stimmberechtigung auch an das Vertrauensnetz oder Brummfußens Bewertungssystem binden. Du kannst die Stimmberechtigung an alles mögliche binden. Machst Du Dir da auch Sorgen? Ich nicht. Ein Meinungsbild, was die Stimmberechtigung derartig verändern will, würde niemals durchkommen. Nicht mal mit einfacher Mehrheit, geschweige denn mit einer m.E. notwendigen ausreichend qualifizierten Mehrheit von 75 % oder 80 %. --Markus Mueller 00:11, 10. Feb. 2008 (CET)

Ich denke, es zeugt nicht von „reflexhaftem Erzkonservatismus“ sich Gedanken über unerwartete bzw. unerwünschte Nebenwirkungen eines Konzepts Gedanken zu machen. Sowas gehört für mich zu einem soliden Risikomanagement dazu. Die Leute, die sich hier solche Gedanken machen, tun das nicht aus Angst und Paranoia sondern vielleicht, weil sie sich aus eigener Erfahrung und intuitiver Herangehensweise heraus diese Fragen stellen. Genauso fair, wie es ist, dieses System zu entwerfen und experimentell umzusetzen, genauso fair ist es, Zweifel anzumelden und auf Risiken hinzuweisen. Beide Seiten haben einen respektvolleren Umgang verdient, als einfach abgekanzelt zu werden. sebmol ^{? !} 00:07, 10. Feb. 2008 (CET)

(bk) Totschlagargument - es lässt sich eben nicht trennen. Es sollen doch zumindest wie auch immer geartete Tatsachen geschaffen werden, nur welche? Heute haben wir die Diskussion um die Adminkaste und deren (angebliche) Klüngeleien. Später findet dasselbe noch in größerem Maßstab zwischen Stimmberechtigten und nicht stimmberechtigten Benutzern statt. Und was wird dadurch besser? Wer lieber WW will, soll doch konsequenterweise auch dort mitarbeiten... Oder geht es gar nicht um Stimmberechtigung? Dann klärt mich doch bitte auf. --Schwalbe D•C•B 23:57, 9. Feb. 2008 (CET)

Geh schlafen, Schwalbe, das wird heute abend nix sinnvolles mehr. --Markus Mueller 00:00, 10. Feb. 2008 (CET)

Dito Markus Liesel 00:12, 10. Feb. 2008 (CET)

Heut morgen aber auch nicht. ;-) --Schwalbe D•C•B 00:14, 10. Feb. 2008 (CET) GN8

Zusammenfassend kann man sagen, das mit beiden Zwillingsprojekten ausgelotet werden soll, in wie weit sich die Nachteile der Anonymität (Unruhe, Missbrauchsmöglichkeiten oder Unsicherheit) mildern lassen, ohne das Ideal der Anonymität aufzugeben. Das ist das Gegenteil von dem was die oder Wikiweise macht. Die Anonymität wird respektiert. Das Bürgensystem könnte als Identverfahren im internationalen Bereich verwendet werden, wenn sich die Benutzer nicht seit Jahren aus dem Projektnamensraum von zu Hause kennen. Oder als Identverfahren für Pseudonyme in urheberrechtlicher Hinsicht im Internet, wenn Personen beweisen wollen dass sie genau dieser WP-Autor sind. Überall dort, wo man einem Benutzernamen zweifelsfrei eine Identität zuweisen möchte oder muss, ohne die Anonymität der Person preis zu geben. Die Gemeinschaftsseite (drüben) könnte das nicht, hat aber zusätzlich eine soziale Wirkung, in dem sie zeigt welche Benutzerkonten Hauptkonten sind und zur aktiven Gemeinschaft gehören. Oder in dem sie Benutzer motiviert, sich ihr anzuschließen. Erfahrungssammlung, welche Verbesserungsmöglichkeiten es in der einen oder anderen Sache gibt und auch um noch ein paar weitere gute Vorschläge zu erhalten. Mir scheint keiner der beiden Testläufe in der originalen Variante als fertiger Ersatz für die leidgeprüfte Stimmberechtigung geeignet. Und ob das notwendig ist oder ob man das machen sollte, wird hier nicht getestet. --Carl 02:33, 10. Feb. 2008 (CET)

Sockenpuppenhysterie

Auf die Gefahr hin, dass das jetzt wieder als "reflexhaftes erzkonservatives Angstschnappen" ausgelegt wird: Ich halte diese ganze Aktion ehrlich gesagt im besten Fall für peinlich, im schlimmsten Fall für projektschädlich. Ähnliches gilt für das Gemeinschaftsseitenprojekt. Weniger, weil ich befürchte, dass meine Daten an die CIA übermittelt werden (wobei der Datenschutz natürlich auch ein ernstes Thema ist), sondern weil diese Aktion ein Problem, das wir IMO in der WP haben weiter verstärkt: Nämlich die Segregation einer Gruppe von aktiven Benutzern, vulgo dass wir gerne mal ein bisschen im eigenen Saft schmoren. Andere Benutzer persönlich zu kennen, ist ja eine feine Sache, aber es gibt auch überaus fähige Autoren, die nicht so viel von dem ganzen Communitygedöns halten und einfach nur hier ihre Arbeit machen – sollen die jetzt zu Benutzern zweiter Klasse abgestempelt werden? Ganz zu schweigen davon, dass der Einstieg für neue Autoren ohnehin schon immer schwieriger wird. Dadurch dass sich die Gruppe der aktiven Benutzer noch mehr neue Spielchen einfallen lässt, um sich abzugrenzen, wird es bestimmt nicht einfacher.

Soweit also meine prinzipiellen Bedenken. Wenn diese Aktion einen wirklichen (und ich meine wirklichen) Nutzen versprechen würde, wäre ich vielleicht bereit, sie über Bord zu werfen. Aber so frage ich mich: Cui bono? Am Ende werden wir vielleicht 100 Benutzer haben, von denen wir dann sicher wissen, dass sie natürliche Personen sind. Und die restlichen zigtausend? Alles Sockenpuppen? Mir kann keiner behaupten, dass wir ein derartiges Sockenpuppenproblem haben, wie es hier einem vorgemacht wird. An jeder Ecke Sockenpuppengespenster zu sehen, ist IMO ohnehin ein Symptom dessen, was ich als "im eigenen Saft schmoren" beschrieben habe. Wenn ich eine Sockenpuppe anlegen will, um einen Editwar zu führen oder auf einer fremden Benutzerdiskussion rumzupöbeln, kann ich das auch weiterhin tun – Authentifizierung hin oder her. Bei den Benutzern, die sich hier authentifizieren lassen werden, würde ich ohnehin nicht davon ausgehen, dass sie Sockenpuppen sind. Und selbst wenn sie es wären, würde es mich nicht stören, solange sie gute Arbeit leisten. Also: Ich bin mir sicher, dass dieses Projekt ebenso wie die Schwesteraktion von Taxman mit guten Absichten gestartet wurde, aber IMHO ist es vor allem eine Beschäftigungstherapie mit wenig Nutzen aber einigen Problemen. --BishkekRocks 11:15, 10. Feb. 2008 (CET)

Wenn Leute zu PGP-Keysign-Partys gehen und sich ihren Key und ihre Identität bestätigen lassen, ist das eine schädliche Sache? Werden Leute, die keine sichere Verschlüsselung für eMails verwenden wollen, dadurch zu Menschen zweiter Klasse abgestempelt?

Wir machen hier mit der sicheren Authentifizierungsmöglichkeit etwas, was außerhalb der Wikipedia von Hackern und Datenschützern wärmstens empfohlen wird, aber innerhalb der Wikipedia soll das projektschädigend sein? --Markus Mueller 11:30, 10. Feb. 2008 (CET)

Übrigens, Menschen neigen von Natur aus zu sozialem Verhalten: sie bilden Grüppchen und grenzen sich von anderen Grüppchen ab. Das ist nichts per se schlechtes, solange es in Maßen geschieht. Wenn Menschen sich in übertriebener Weise von anderen absetzen und andere mit Gewalt draußen halten wollen, dann werden sie es auf erheblich einfachere Weise tun, als über einen so komplizierten Mechanismus wie dem Bürgschaftssystem.

Genausogut kannst Du es aber umgekehrt sehen: vielleicht ist das Bürgschaftssystem ein Verfahren, wo Benutzer, die sonst mühsam um ihre soziale Integration kämpfen müssten, viel leichter die Initiationphase in der Community überspringen können. Dann wäre es eine Hilfe für Neulinge, die nicht erst über Monate „beweisen“ müssen, dass sie gewillt sind, konstruktiv mitzuarbeiten. Vielleicht ist es für einige auch ein positiver Punkt, jemanden nach kürzerer Zeit schon zum Admin zu wählen. Ich kann mir eine ganze Menge positive Effekte vorstellen, die eintreten, wenn ich auf eine Benutzerseite eines mir unbekannten Mitarbeiters komme und sofort sehe, dass derjenige von meinen „Bekannten“ verbürgt wurde. Das ist der Sinn von sozialen Netzwerken, die übrigens IRL überall gefördert werden. --Markus Mueller 11:59, 10. Feb. 2008 (CET)

die 100 benutzer, von denen bishkek spricht, die sich auf das bürgschaftssystem vermutlich einlassen, sind als reale personen im zweifel eh schon aufgrund ihrer teilnahme an stammtischen, workshops oder jcornelius party bekannt. und sicher ist der besuch von solchen RL-anlässen auch für newbies eine gute gelegenheit, schnell tiefer einzusteigen und vertrauen zu gewinnen, bei mir selbst war das durchaus auch so (mein erster stammtisch nach 8 wochen wp hat mir damals in vieler hinsicht die augen geöffnet). dagegen ist auch gar ncihts zu sagen. ich verstehe nur nicht, weshalb das mit einer öffentlichen, wenn auch codierten, darstellung persönlicher daten einhergehen muss.--poupou review? 12:10, 10. Feb. 2008 (CET)

Eine eineindeutige Zuordnung einer Person ist eben nur über persönliche Daten möglich, wenn man das vermeiden könnte, dann wäre das sehr schön; biometrische Daten zu erheben wird aber erst recht abgelehnt. Das Verfahren zur Schlüsselerzeugung selbst soll ja wiederum ein Rückschluss auf diese Daten unmöglich machen.

Die PIS könnte mittelbar z.B. für Abstimmsoftware, wie einige sie für die Einführung geheimer Adminwahlen fordern, nützlich sein. Gerade im Zusammenhang mit automatisiserten Wiederwahlen für alle Admins habe ich von diesem Vorschlag gehört (habe mir allerdings noch keine Meinung dazu gebildet). Man könnte auch anonymisierte Umfragen zu kritischen Projektfragen mit hohem Konformitätsdruck durchführen, die indirekt über den PIS authentifiziert werden. Und am wichtigsten von allem finde ich die Funktion für die Forschung. Viele soziologische und wissensorganisatorische Fragen könnten besser untersucht werden, wenn man eine Gruppe von eineindeutig zuordbaren Personen hat, deren Beiträge oder Artikel man kennt.

Du darfst auch nicht vergessen, dass das Auftauchen auf einem Stammtisch unbeabsichtigt weit mehr Daten von Dir preisgeben wird, als der nackte Name und das Geburtsdatum (Daten, die Du ohnehin überall und ständig im Leben preisgeben musst und deren Bekanntwerden im richtigen Leben wenig Auswirkungen haben dürfte. - Wenn jemand natürlich in seiner Arbeitszeit Wikipedia-Artikel schreibt, und der Arbeitgeber bekommt das raus - das ist Mautprellers Beispiel - ja, sorry, aber dann hat sich derjenige zuerst falsch verhalten und seinen Arbeitgeber betrogen). In der Regel wirst Du auf Stammtischen Deinen Vornamen ohnehin schon angeben, Deine körperliche Erscheinung macht Dich für Dritte hervorragend identifizierbar und das, was jemand an einem Abend erzählt, verrät schon extrem viel diese Person. Insofern ist der PIS eine gute Alternative für Leute, die Stammtische u.ä. gerne aus Anonymitätsgründen meiden, aber dennoch als Teil der Community bestätigt werden wollen (denkbar wären etwa z.B. Professoren oder Politiker oder aber Mitarbeiter, die in kritischen Bereichen wie Antifa oder Sex arbeiten und nicht erkannt werden wollen).

Das schöne ist, dass so ein System sehr viele denkbare Anwendungsmöglichkeiten hat. Natürlich muss man die Risiken und Nebeneffekte bedenken, die soetwas haben kann, aber was hindert uns daran, das Projekt nach 6 Monaten wieder einzustampfen? Gerade um herauszufinden, ob es nicht unbeabsichtigte Seiteneffekte hat, ist es doch wichtig, das erstmal auszuprobieren. Dann können wir in Zukunft sagen, wenn uns jemand sowas aufschwatzen will: brauchen wir nicht, haben wir schon getestet, taugt nichts. Vielleicht können wir danach auch einfach nur klarer definieren, was unsere Bedürfnisse im Bezug auf Identität ist oder wir erkennen bessere Wege, anonyme Partizipation stärker zu fördern. Nichts tun bringt aber auch keine neuen Erkenntnisse. Was ist nur aus "Sei mutig!" geworden? --Markus Mueller 13:05, 10. Feb. 2008 (CET)

es hat doch niemand etwas dagegen, dass hier was ausprobiert wird. nur muss man sich, wenn man sich mit einer initiative vorwagt, eben auch fragen und kritik stellen. du würdest doch selbst auch nicht mit kritik hinter dem berg halten, wenn dir ein vorschlag seltsam, fragwürdig oder nutzlos vorkommnt. die bereitschaft zur auseinandersetzung gehört hier doch eigentlich zur grundausstattung.--poupou review? 13:25, 10. Feb. 2008 (CET)

Sicher, solange die Kritik sachbezogen ist, kann man sich ja auch sinnvoll darüber austauschen. Was nervt sind Argumentationstrategien a la "das haben wir aber immer schon so gemacht" oder wenig hilfreiche Analogien wie "Heimatministerium". Das das ganze etwas Neues ist und damit anders als der alte Zustand, ist eine triviale Aussage, die keinen Informationsgewinn bringt. Hier als erstes zu unterstellen - was hier und dort ja der eine oder andere gemacht hat -, man führe irgendwas Böses im Schilde und wolle andere ausgrenzen oder in ihren Rechten beschneiden, verletzt massiv unseren Grundatz von AGF. Die Ironie dabei ist: gerade weil wir keinen konkreten Zweck genannt haben, also das Verfahren überhaupt nichts verändern will, wird es wegen Intransparenz kritisiert. Also wie man es auch immer macht, es ist immer falsch. --Markus Mueller 13:35, 10. Feb. 2008 (CET)

deinem letzten satz kann ich nur zustimmen.--poupou review? 18:29, 10. Feb. 2008 (CET)

Und insofern kann man es dann auch gleich so machen, wie man es selbst für richtig hält, weil man es ohnehin nicht allen recht machen kann. --Markus Mueller 19:08, 10. Feb. 2008 (CET)

genau. und so machen wir es ja eigentlich auch. die kunst besteht nur darin, sich dann nicht über die anderen aufzuregen. und das scheint mir ein punkt, der noch verbesserbar ist. ;-) --poupou review? 20:04, 10. Feb. 2008 (CET)

Ja Markus, hättest Du das gestern schon geschrieben, so hätten wir jetzt ein Missverständnis weniger auszuräumen. Dieser Zielgruppenargumentation kann ich schon weit eher folgen. Nur sollte dann das Verfahren erst recht wasserdicht sein - technisch und argumentativ. Wenn diese Arbeit nicht geleistet wird oder werden kann, dann wird auch die beispielhaft genannte Zielgruppe der Methode schlicht kein Vertrauen schenken oder auch "nur" den Aufwand scheuen. Deshalb brauchen wir noch immer den freien Gedankenaustausch - von bösen Zungen so gern als Metadiskussion abgestempelt und abgetan. --Schwalbe Disk. 22:23, 10. Feb. 2008 (CET)

Geringe Beteiligung - woran liegt es?

Im Vergleich zum Taxman-Fritz-Carl-Verfahren oder auch der Liste von Hans Koberger ist die Beteiligung hier sehr gering. Liegt das am komplizierten Procedere, haben die Leute Angst sich hier zu entblößen, oder gibt es irgendwelche Ressentiments gegenüber den Initiatoren und dem Verein? Ich beteilige mich zwar an beiden Verfahren, habe sogar die Sache mit dem PIS geschafft, bin aber doch ziemlich irritiert. Gibt es Einschätzungen? --Schlesinger ^schreib! 16:51, 12. Feb. 2008 (CET)

Die Verschlüsselung von eMails mit PGP ist auch langsamer in Fahrt gekommen als ROT-13. Woran liegt das? Ein Public-Key-Verfahren ist aufwendig, aber sehr sicher. Andere Verfahren sind sehr einfach, bieten dafür aber so gut wie keine Sicherheit.

Jeder macht gerne mal ein paar Unterschriften „um zur Gruppe dazuzugehören“, das kostet nichts und hat ja auch keine Folgen. Aber sobald man etwas mehr tun muss, als völlig unverbindlich zu bleiben, und sobald sich das Mitmachen nicht in sofortiger sozialer Anerkennung niederschlägt (ich unterschreib bei dir - du unterschreibst bei mir), ist das den meisten zuviel Arbeit, hat keinen unmittelbaren Wohlfühl-Nutzen und verliert dadurch stark an Attraktivität. Das ist aber ganz normal und irritiert mich gar nicht. --Markus Mueller 17:09, 12. Feb. 2008 (CET)

Dass es „bei der Konkurrenz“ sehr viel dynamischer vorangeht, liegt sicher auch daran, dass man dort sofort nach dem Einstieg sehen kann, wie es vorangeht, während hier bisher noch nix und niemand verbürgt wurde und dadurch das Entstehen neuer Bürgen (solche Sachen leben ja vom Schneeballprinzip) momentan in sehr weite Ferne entrückt scheint. Und ohne Bürgen geht halt nix. — ^PDD — 22:07, 12. Feb. 2008 (CET)

zudem hat es zumindest nach meiner auffassung neben dem fehlenden wohlfühlnutzen eben gar keinen offensichtlichen nutzen, der eine motivation darstellen könnte.--poupou review? 22:53, 12. Feb. 2008 (CET)

Am einfachsten ist es, man liest Benutzer:Frank Schulenburg/Bürgschaft#Anonymität und Datenschutz. Da steht: "Niemand ist gezwungen, an diesem System teilzunehmen, da weder Privilegien noch Nachteile mit der Teilnahme oder Nicht-Teilnahme verbunden sind.". Das heißt auf Deutsch: Es bringt nix, und man fragt sich: "wozu?". -- Martin Vogel 10:40, 14. Feb. 2008 (CET)

Am einfachsten ist es, man liest sich die Seite Benutzer Diskussion:Frank Schulenburg/Bürgschaft durch, denn da steht schon ganz viel zu dem Thema, wozu das alles gut sein könnte. Aber man kann eh schreiben, soviel man will, das liest Martin Vogel sowieso nicht oder er liest es, und ignoriert es, um hier noch ein bisschen weiter rumstänkern zu können. Das heißt auf Deutsch: erklären bringt nix, und man fragt sich auch: "wozu?". --Markus Mueller 11:38, 14. Feb. 2008 (CET)

Das übliche Gemueller. -- Martin Vogel 11:50, 14. Feb. 2008 (CET)

Gang nach Meta

Kann man das Verfahren etwas beschleunigen, in dem man auf die Seite zum Tool einige vereinfachende Verbesserungen unter bringt? Oder wenn man das ganze übersetzt und nach Meta transportiert, dann würde sich vielleicht eine größere Gemeinde finden. --Carl 23:28, 12. Feb. 2008 (CET)

Bringt gar nix, weil persönliche Treffen notwendig sind. Die werden durch Teilnehmer in Lampukistan nicht wahrscheinlicher. --Markus Mueller 12:33, 13. Feb. 2008 (CET)

Ich finde dass das Verfahren durch den Gang nach Meta profitieren würde. Ob die sich dann in Amiland oder Lampukistan bestätigen lassen, spielt imho keine Walze. --Carl 20:20, 17. Feb. 2008 (CET)

Natürlich kann man das Verfahren auch auf Meta installieren und dann in jeder Wikipedia eine nationale Dependance einrichten. Ich halte es aber für sinnvoller, es zunächst nur in einer Wikipedia zu testen und nicht gleich in allen auf einmal. Wenn es sich in DE bewährt, wird man das Verfahren sicher in andere Wikipedias exportieren und frühestens, wenn es in 2 Wikipedias läuft, dann eine internationale Koordinationsseite auf Meta aufbauen. Nur: Warum sollte es jetzt davon profitieren? Ich kann nicht erkennen, inwieweit eine Meta-Seite irgendeinen Gewinn bringen sollte. Dann müssen wir nur 2 Seiten überwachen statt eine. --Markus Mueller 20:35, 17. Feb. 2008 (CET)

Wieso zwei Seiten überwachen? Eine auf Meta reicht. Eine für alle. Wenn am Anfang überwiegend de:-Benutzer drin stehen ist es doch egal. Die Sprache kann man mit einer Vorlagenlösung regeln. --Carl 20:41, 17. Feb. 2008 (CET)

Du hast die Frage nicht beantwortet, was das denn überhaupt bringen soll. --Markus Mueller 10:17, 18. Feb. 2008 (CET)

Mehr Teilnehmer kommen und bessere Anwendungsmöglichkeiten. Allerdings weiß ich nicht, ob sich im internationalen Bereich genug Leute persönlich treffen. Auf en: arbeitet alles von Neuseeland über Australien, Canada und USA mit. --Carl 12:29, 18. Feb. 2008 (CET)

Was für bessere Anwendungsmöglichkeiten? --Markus Mueller 12:56, 18. Feb. 2008 (CET)

Bürgen auf anderen Kanälen

Was spricht gegen eine Kontrolle durch mündliche Mitteilung der Daten über das Telefon, Webcam oder Fax? Die Ausweis-Nummer kann doch prinzipiell nur derjenige wissen oder haben, dem der Au,sweis gehört und der unter seinem Hauptkonto den Hash-Wert editiert hat. --Carl 23:27, 12. Feb. 2008 (CET),

Ich kann den Bürgen konstant etwas falsches erzählen und kann mir auf diese Weise einen Zweitaccount zusätzlich bestätigen lassen. Der springende Punkt bei diesem Verfahren ist die zuverlässige Identitätsprüfung - entweder macht man die, oder man kann es auch gleich gaanz bleiben lassen. Im übrigen fragen wir so sensible Daten wie die Ausweisnummer gar nicht erst ab, nur den Namen und das Geburtsdatum. --Markus Mueller 12:33, 13. Feb. 2008 (CET)

Fester Salt bringt auch nix

Diese Verkomplizierung mit dem festen Salt hilft ja nur was gegen den blinden Brute Force auf alle Schlüssel zwecks Feststellung des Klarnamens und Geburtsdatums. Gegen den wichtigeren Angriff (ich habe Namen und Geburtsdatum und suche den Benutzernamen durch Abgleich) hilft er auch nicht, weil ich über den Toolserver die Daten eines Fremden ja eingeben kann und mit Hilfe des ausgespuckten Schlüssels (egal, wie er zustande gekommen sein mag) einen Vergleich anhand der Liste durchführen kann.

Insgesamt gesehen ist das m.E. zu viel Verkomplizierung für zuwenig Gewinn. Ich würde sagen, wir belassen es jetzt erstmal für den Testlauf bei dem ersten, einfacheren Verfahren. Wer Sorgen wegen der Angriffe hat, sollte nicht mitmachen. Falls sich herausstellt, dass das Bürgschaftssystem angenommen wird und nützlich ist, sollte man eine Möglichkeit einführen, dass Nutzer, die auf starke Anonymität angewiesen sind, einen "sicheren Schlüssel" bekommen. Ideen dafür gibt es ja genug. --Markus Mueller 14:00, 13. Feb. 2008 (CET)

Siehe auch Abschnitt „Zweifelhafte Anonymität“, wo ich dargelegt habe, dass nur ein nicht veröffentlichter, nur dem System bekannter gesHash halbwegs Anonymität bringt. --Franz (Fg68at) 10:32, 14. Feb. 2008 (CET)

Anonymität – Lösungsansatz mit GPG

Spannend, was sich hier gerade entwickelt ... und ich hätte da eine Idee zum Anonymitätsproblem. Zunächst einmal ist das ganze doch ein zweiteiliges Problem:

1. Zweck für die Community ist es, eine Aussage darüber zu treffen, ob ein Benutzer eindeutig einer realen Person zugeordnet werden kann.
2. Einige der Benutzer haben darüber hinaus den Anspruch, ihre Anonymität zu wahren und ihre Identität vor einem Brute-Force-Angriff gegen den PIS schützen zu wollen.

Daher folgender Vorschlag:

• Wer lediglich von 1. Gebrauch machen möchte, kann sich eine PIS nach dem aktuellen Verfahren erzeugen.
• Wer zusätzlich seine Privatsphäre schützen möchte, muss etwas mehr Aufwand investieren und braucht ein GPG-Schlüsselpaar. Der Hash für den PIS wird dann aus vier Komponenten erzeugt:
  1. Vorname
  2. Nachname
  3. Geburtsdatum (ddmmyyyy)
  4. Als Salt die mittels des GPG-Private-Key des Benutzers erzeugte GPG-Signatur für die Zeile welche die drei vorhergehenden Angaben enthält. (Alternativ für den daraus resultierenden PIS-Hash. Der Einfachheit halber habe ich jetzt nur die erste Zeile der Signatur verwendet.)

Der Bürge braucht dann die Personendaten mit Signatur und den GPG-Public-Key des Benutzers, um den so anonymisierten PIS zu prüfen.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Mehnert 14022008
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHtJooPs4R6Jq9a9MRAuHQAJ41cbh8UaViYaC/LxOw+AwUK53nUQCgl9Jo
GOH0LpfbbpupL5yryCMk6Nw=
=q+pB
-----END PGP SIGNATURE-----

Damit erhalte ich den String Michael Mehnert 14022008 iD8DBQFHtJooPs4R6Jq9a9MRAuHQAJ41cbh8UaViYaC/LxOw+AwUK53nUQCgl9Jo, der mir dann einen PIS-Hash liefert, der sich ohne Kenntnis meiner zugehörigen Signatur nicht mehr ganz so leicht Bruteforcen lässt, um hinter meine Identität zu kommen: 8f8841fd4ac2f9a1b9a6d55c813a8eb68346acea1f77e75a63e14d1ec372bb0b --xGCU NervousEnergy 21:01, 14. Feb. 2008 (CET)

Gegen die (weniger wichtige) Wörterbuchattacke hilft das genausogut wie alle anderen gesalzenen Hashes. Es hilft aber immer noch nichts gegen die (wichtigere) Benutzernamenattacke. Da in diesem Szenario dem Angreifer Name und Geburtsdatum von vorneherein zur Verfügung stehen, und der Public Key ebenfalls bekannt sein muss (sonst können die Bürgen nicht unabhängig voneinander die Identität feststellen), kann der Angreifer den String Michael Mehnert 14022008 iD8DBQFHtJooPs4R6Jq9a9MRAuHQAJ41cbh8UaViYaC/LxOw+AwUK53nUQCgl9Jo selbst konstruieren und den PIS zu einer Person erstellen, um herauszufinden, unter welchem Benutzernamen er hier mitarbeitet. Gegen diesen Angriff helfen grundsätzlich keine Daten, die entweder öffentlich bekannt oder geheim aber konstant sind, sondern nur Daten, die fest mit der Person verbunden sind und nicht jedem bekannt sind (wie etwa der von Achim vorgeschlagenen Geburtsort). --Markus Mueller 12:21, 15. Feb. 2008 (CET)

Verstehe ich nicht. Arbeitgeber wissen den Geburtsort doch. Wie siehts mit dem Geburtsort der Mutter aus? Sargoth^¿!± 12:36, 15. Feb. 2008 (CET)

Das haben wir oben schon abgefrühstückt: Arbeitgeber wissen eben leider den Geburtsort, deswegen haben wir den auch nicht genommen. Geburtsort/-name der Mutter (habe ich auch schon vorgeschlagen) ist zu schwer mit Hilfe von eigenen Dokumenten nachzuweisen. --Markus Mueller 14:41, 15. Feb. 2008 (CET)

Ok. Auf dem Perso stehen noch zwei Daten, die allerdings temporär sind: ausstellende Behörde und gegenwärtige Anschrift. Soweit ich weiß, kann man heutzutage noch seinen entwerteten Perso behalten, sodass zumindest Info 1 weiterhin nachweisbar bleibt.Sargoth^¿!± 14:45, 15. Feb. 2008 (CET)

Deaktivierte Bestätigungen von noch nicht verbürgten BenutzerInnen

Ich habe einen Vorschlag, wie die Zahl verbürgter BenutzerInnen zumindest mittelfristig deutlich schneller steigen kann als bisher. Mein Vorschlag sieht vor, dass auch noch nicht als Vollbürge eingetragene BenutzerInnen andere Teilnehmende auf spezielle Weise bestätigen können. Diese Bestätigung wird allerdings gesondert aufgelistet und ist provisorisch oder deaktiviert, so dass sie noch nicht wirklich zählt. Relativ rasch könnte man auf diese Weise zahlreiche noch deaktivierte Bestätigungen sammeln. Wenn dann jemand Vollbürge wird, werden dessen Bestätigungen bei allen Betroffenen aktiviert, das heißt in die Liste offizieller Bestätigungen verschoben.

Die Vorteile sind klar: Besonders in der zähen Anfangsphase können auch momentan zur Inaktivität verdammte BenutzerInnen bereits provisorische Bestätigungen aussprechen wie auch sammeln und das System ins Rollen bringen. Weil diese erst dann gültig werden, wenn der Bestätigende VollbürgIn geworden ist, wird die Sicherheit des Systems nicht beeinträchtigt. Was denkt ihr? Nils Simon T/\LK? 10:28, 25. Feb. 2008 (CET)

Huch? Was ist denn jetzt los?

Verlassen die Ratten ein sinkendes Schiff? Jetzt hat man sich mit Mühe diesen PIS erstellt und schon springen die Ersten ab. Kann mir mal einer sagen, was los ist? :-) --Schlesinger ^schreib! 11:21, 15. Mär. 2008 (CET)

Wer will schon freiwillig PIS-Bürger sein? -- Martin Vogel 12:26, 15. Mär. 2008 (CET)

Das erinnert mich an Pissville, eigentlich Peaceville, den Schauplatz von Dashiell Hammetts Roman Rote Ernte. Die Stadt ist 'ne Hochburg von knallhart rivalisierenden Gangsterbanden. :-) --Schlesinger ^schreib! 13:57, 15. Mär. 2008 (CET)

Vorschlag: beenden und ggf. archivieren

Hallo allerseits, nachdem diese Variante des Bürgschaftsprojektes nie richtig angelaufen ist (vermutlich war es einfach zu restriktiv und kompliziert), schlage ich vor, sie jetzt zu beenden und zu archivieren (oder zu löschen). Mir ist beides recht. Meinungen und Vorschläge dazu? --Frank Schulenburg 12:30, 19. Mär. 2008 (CET)

Nö, kommt nicht in die Tüte :-) Aber mal im Ernst, gebt dem Pflänzchen noch etwas Zeit. Gerade jetzt ist doch die Stimmung wieder besser geworden nach dem Rücktritt von Markus Mueller. Schlage daher vor, bis zum Sommer zu warten. Macht bis dahin noch ein paar angekündigte Currywursttermine und gut ist. Gruß --Schlesinger ^schreib! 13:13, 19. Mär. 2008 (CET)

Das System an sich ist okay, weil es mit noch größerer Sicherheit wie das Taxman-System eine Sockenpuppe ausschließen kann. Es krankt jedoch an dem Punkt, daß er gar nie anlaufen kann. Richtig ins Rollen würde es nämlich erst dann kommen, wenn eine gewisse Anzahl an Vollbürgen erreicht wird. Dies ist jedoch nach dem derzeitigen Modus nicht zu machen. Die "ersten" Vollbürgen benötigen eine Kontrolle durch 8 Urbürgen (da es noch keine anderen Vollbürgen gibt). Es gibt jedoch nur 10 Urbürgen. Bis einer 8 davon getroffen hat, wird (zu)viel Zeit vergehen! Wir müssten uns eine Möglichkeit überlegen, die Zahl der Ur- oder Vollbürgen schneller wachsen zu lassen. Konkrete Vorschläge habe ich leider auch keine, angedacht war auf einem Stammtisch schonmal die "Gesichts- und Ausweiskontrolle" per Camchat. Ich persönlich hätte auch nichts dagegen, eine Ausweiskopie an Verein / Foundation / ... zu senden, wenn dies die Voraussetzung wäre, um bürgen zu dürfen. —YourEyesOnly ^schreibstdu 15:59, 19. Mär. 2008 (CET)

Zustimmung zu YEO. Acht Urbürgenbestätigungen bei 10 vorhandenen Urbürgen ist wirklich harter Tobak. Aber man beachte, was für ein Schub sich etwa bei einem Ereignis wie dem nächsten Treffen in Cornelius' Garten ergeben würde!--Berlin-Jurist 17:42, 19. Mär. 2008 (CET)

Frank, wir sehen uns doch in einer Woche. Und da werden mindestens vier Urbürgen anwesend sein. [ˈjoːnatan gʁoːs] 13:45, 20. Mär. 2008 (CET)

Hat es einen bestimmten Grund, dass man erst ab acht (nicht fünf und nicht zehn) Bürgen als bestätigt gilt, und wenn nein, spräche was dagegen, einfach mal die Hürde zu senken? --S^[1] 13:57, 20. Mär. 2008 (CET)

Man wird das Gefühl einfach nicht los, dass hier nix los ist. Vielleicht sollten wir das Ding hier doch vergessen. Eine weitere Seite, auf der man ignoriert wird braucht es wirklich nicht. Vielleicht sollte dieses Verfahren von engagierteren Benutzern übernommen werden. Erst anleiern und einen auf wer weiß wie anspruchsvoll, seriös und securitymäßig zu machen, dann aber die Lust daran zu verlieren ist nicht das Gelbe vom Ei. Gruß --Schlesinger ^schreib! 14:54, 28. Mär. 2008 (CET)

Morgen haben wir überregionalen Stammtisch in Göttingen, wo vier Urbürgen zusammenkommen werden, unter anderem auch der Namensgeber dieser Seite. Ich denke, dort können einige Personen verbürgt werden. Grüße, —DerHexer (Disk., Bew.) 15:13, 28. Mär. 2008 (CET)

Haalloo! Ist da jemand? - Von den kahlen Betonwänden hallt es unheimlich zurück. Kein lebendes Wesen weit und breit. Ich fühle mich so alleine. Das Bier ist alle, ebenso wie die Hoffnung. Göttingen, da muss der ultimative GAU stattgefunden haben. Das hat wohl keiner überlebt. Nun, der Letzte macht das Licht aus und die Tür zu. Wen beißen die Hunde? Klarer Fall, ich will nicht der Letzte sein und geh' lieber jetzt. Tschüß! --Schlesinger ^schreib! 19:10, 5. Apr. 2008 (CEST)

Qualifizierte Signatur

Wäre es nicht eine Alternative, ein Scan des Ausweises versehen mit der eigenen elektronischen Signatur einem Urbürgen oder der Geschäftsstelle zuzuschicken? Ist natürlich nicht so originell, wie das Treffen an einer Wurstbude, aber vielleicht der zeitgemäße Weg, der ggfls. auch Anreisekosten erspart...--Kresspahl 08:41, 1. Jul. 2008 (CEST)

:Keine schlechte Idee, wobei der Versand per Post erfolgen sollte. Gleiches sollte auch für Bürgen gelten. Schließlich braucht man auch deren Bestätigung. Viele Grüße --Marbot 14:52, 1. Jul. 2008 (CEST)

Wie verschickst Du ein signiertes Digitalisat per Post? Mein Variante dürfte alle die Benutzer ansprechen, die ohnehin über eine gültige Signaturkarte verfügen. Lesen kann man so etwas entsprechender Software, die gibt es aber für jeden umsonst zum download, zB [2]. Wenn ich als Anwalt damit abgesichert und legitimiert im elektronischen Rechtsverkehr tätig sein kann, dann müsste das doch auch in der WP möglich sein.--Kresspahl 16:26, 1. Jul. 2008 (CEST)

Deine Nachricht oben erhält leider keinen Hinweis darauf, daß Du dieses Verfahren gemeint haben könntest. Warum sonst hätte ich mich mit meinem Vorschlag lächerlich gemacht? Ich hoffe, daß im Rechtsverkehr präziser getextet wird. Viele Grüße --Marbot 18:09, 1. Jul. 2008 (CEST)

Es kommt nicht auf die Länge an...

...zumindest ist Länger nicht automatisch besser. Hier meine Idee zu später Stunde wie man Anonymität trotz Bürgschaft gewährleisten kann.

Der bekannte Hash-Wert wird weiterhin verwendet, allerdings werden nur die ersten 16 Bit veröffentlicht. Für diejenigen die über 10-1=1 nicht lachen können: Das entspricht 65.536 möglichen Werten, verglichen mit ~3400 Wikipedianern im de-Wiki Sichter sind. Damit hätten wir folgende Eigenschaften:

1. Kollisionen werden gelegentlich auftreten. Falls der verbürgte X und der neu zu verbürgende Y identische 16-Bit Werte haben, dann müssen die Bürgen für Y mit denen für X Kontakt aufnehmen und die komplette Hash abgleichen. Natürlich auf einem nicht-öffentlichen Medium. Wie viele Extrawürste da gebraten werden müsste man mal ausrechnen, sooo viele sollten es aber nicht sein.
2. Aus einer 16-Bit Hash kann man privaten Daten nicht sicher ableiten. Bei je 100 Vor- und Nachnamen hat man 10.000 Namen, außerdem 365 Tage im Jahr. Allein für ein Jahr gibt es also 3.650.000 mögliche Namen+Tag Kombinationen. Selbst wenn ich das Geburtsjahr einer Person kenne bleiben mir also 3,65Mio/65536=55 Möglichkeiten wie dieser Hash zustande gekommen ist.
3. Glaubhafte Bestreitbarkeit gegenüber dem Arbeitgeber und anderen. Wenn die rund ~3000 Sichter des de-Wiki sich eine von ~60.000 Hashes schnappen, dann ist die Chance für jeden Menschen 1 zu 20, dass eine für ihn passende Hash hier in der Wikipedia auftaucht. Auch Angela Merkel hätte eine 1/20 Chance, dass eine zu ihrem Namen+Geburtstag passende 16-Bit Hash im System steht.

Soviel zu später Stunde. Wenn ich morgen wieder wach bin schau ich mir meine Idee auch noch mal an ;-) --Regani 02:44, 3. Jul. 2008 (CEST)

Also jetzt noch mal in wachem Zustand:

• Um die Kollisionsüberprüfung wie in Punkt 1 durchführen zu können müssen sich die Bürgen zumindest die Hashes der von ihnen verbürgten speichern.
• Bei Punkt 1 könnte ein böswilliger Bürge eine Sockenpuppe Y erstellen deren Name angeblich(!) eine Hashkollision mit einer verbürgten Person X produziert. Der böse Bürge könnte mit dieser Begründung einen Bürgen von X nach den Daten von X fragen (angeblich um die Kollision aufzuklären) und so gezielt an Informationen einer Person kommen. Lässt sich dadurch beheben indem immer nur die Daten des neu zu verbürgenden weiter gegeben werden, nie die Daten einer bereits verbürgten Person. Bzw wenn beide noch nicht verbürgt sind werden die Daten desjenigen weiter gegeben der seine Hash zuletzt veröffentlicht hat, also in unserer Liste weiter unten steht. So kann ein böser Bürge nur die Hashes derjenigen abgreifen die zufällig mit einer von ihm verbürgten Person übereinstimmen.
• Kollisionshäufigkeit. Hier kann der Pinguindompteur folgendermaßen experimentieren:

for i in `seq 1 1234`; do echo $RANDOM; done | sort | uniq -d | wc -l

Das generiert 1234 Zufallszahlen (nur 15 Bit, trotzdem gut) und zählt dann wie oft eine Zahl mehrfach vorkam. Für diese Werte kommen bei mir ca. 20 Kollisionen raus, also gäbe es in 1,6% der Fälle ein Kollision. Zu bedenken ist, dass tatsächlich 16 Bit verwendet werden und wir von 1234 verbürgten Nutzern noch weit entfernt sind.

• Selbst wenn wir das zehnfache, also 12340 verbürgte Nutzer erreichen sollten ergibt obiges Experiment Kollisionen in ~15% der Fälle, mit 16 Bit aber nur ~8%. Der Aufwand dürfte noch vertretbar sein.
• Um glaubhafte Bestreitbarkeit auch bei wenigen Teilnehmern (so wie jetzt) zu erreichen könnte man mit 12 Bit anfangen. Wenn mehr Leute mitmachen kann man dann die 4 weiteren Bit bei den bestehenden Nutzern nachtragen. Da die Bürgen sich die Hash der von ihnen verbürgten eh speichern müssen können sie auch kontrollieren, dass die richtigen 4 Bit nachgetragen werden.

Viel Spaß beim Nachprüfen. --Regani 14:55, 3. Jul. 2008 (CEST)

Kollisionen

Dieses Kapitel kann man streichen. Es ist dort fälschlicherweise von Geburtstagsparadox die Rede, dies gibt es hier aber nicht. Das Paradox hat nämlihc in der Kryptologie aus einem anderen Grund eine Bedeutung. Habe ich z.B. eine Zeichenkette (Dokument A) und mache darüber einen Hash, dann ist es enorm schwer eine zweite Zeichenkette (Dokument B) zu finden mit demselben Hash. (Diesen Fall haben wir ja hier.) Jetzt zum Paradoxon: Es ist dagegen einiges einfacher zuerst einen Hash anzunehmen und daraus zwei verschiedene Zeichenketten zu bilden, die beide diesen Hash haben.

Voilà: Das Problem stellt sich also, dass wenn ich ein Hash habe und daraus ein Dokument A erzeugen kann, welches zum Beispiel einen Vertrag über Euro 20.- darstellt und ein Dokument B, welches ein Vetrag über 20 Mio. Euro darstellt, ich nur noch Vetrag A jemanden zum elektronisch signieren geben muss und er gleichzeitig auch Vetrag B unterzeichnet. - So eine Problematik kommt hier nicht vor, da jeder ja bereits einen Namen und Geburtstagsdatum hat und somit sollten die Hashs alle unterschiedlich sein. Sollte es trotzdem vorkommen, war es kein Geburtstagsparadoxon, sondern eben ein sehr sehr unwahrscheinlicher Zufall.

--micha Frage/Antwort 01:48, 8. Jul. 2008 (CEST)

Also nochmals anschaulich zum Geburtstagsparadox bei unserem PIS-System: D.h. einen Hash anzunehmen und daraus zwei Namen mit Geburtstagsdaten erzeugen: Bsp. "Ghdahuasz Gasdjas 9.4.0018" und "Bdastü Kksadoiiiajdio 27.12.123078" zu finden ist enorm einfacher als zu meinem Hash von "Micha Rieser 7.8.1975" noch einen zweiten Namen "Ghsdajaksdh Zuasdhasudih 9.1.980765" mit gleichem Hash zu finden. :-) ... Ps. Von anständigen Namen (!!) war ja nie die Rede, denn das ist ja wegen den beschränkten Möglichkeiten noch viel viel viel unwahrscheinlicher und schwieriger (wenn nicht sogar beweisbar unmöglich). Also: Kollisionen kommen eindeutig nicht vor. --micha Frage/Antwort 01:58, 8. Jul. 2008 (CEST)

Doch, Kollisionen kommen vor. Nämlich dann, wenn zwei Personen den selben Namen und den selben Geburtstag haben. Sehr unwahrscheinlich, aber eben nicht ausgeschlossen. Das ist dann wieder das Geburtstagsparadoxon: Eine Anzahl Personen sucht sich aus einer endlichen Menge (hier: Geburtstag x Geburtsjahr x Name; sonst: nur Geburtstag) zufällig einen Wert aus. Wie wahrscheinlich ist es, dass zwei Personen den gleichen Wert gewählt haben? --Regani 09:29, 8. Jul. 2008 (CEST)

Das ist kryptologisch aber kein Geburtstagsparadox: Es ist schlicht logisch, dass der gleiche Input (gleicher Name und gleiches Datum) natürlich den gleichen Hash liefert. - Aber auch dass zwei Personen den gleichen Namen und das gleiche Datum haben, würde ich in dieser kleinen Community einmal ausschliessen. Braucht also nicht besonders erwähnt zu werden, denn das fällt ja dann sowieso auf und man müsste es dann lösen. Aber wie gesagt, die Wahrscheinlichkeit geht auch hier gegen Null, da dieser Fall in der Gesellschaft äusserst selten vorkommt. Gleiche Namen bei gängigen Namen ist zwar wahrscheinlich. Gleiches Geburtstagsdatum (ohne Jahr) ebenfalls. Gleiches Geburtstagdatum mit Jahr schon seltener und gleicher Namen mit exakt gleichem Geburtstag dagegen extrem selten. Sollte dieser Fall trotzdem auftauchen, werden wir das ohnehin sofort merken. --micha Frage/Antwort 13:12, 8. Jul. 2008 (CEST)

Ps. um auch diesen extrem seltenen Fall ausschliessen zu können, müsste man nur noch die PIS-Nummer mit reinhashen. Ein "Peter Müller 1.1.1970" mit PIS-Nummer 47 hätte so einen anderer Hash wie "Peter Müller 1.1.1970" mit PIS-Nummer 48. ;-) --micha Frage/Antwort 13:26, 8. Jul. 2008 (CEST)

Und das liefert dann eindeutige Werte. Wie du bereits gesagt hast, dein zufälliger Wert könnte ja rein theoretisch immer noch Kollisionen verusachen :-). Eine PIS-Nummer ist aber fortlaufend und kommt so nur einmal vor. --micha Frage/Antwort 13:28, 8. Jul. 2008 (CEST)

Das Geburtstagsparadoxon schlägt zurück! Ich hab das grade mal durchgerechnet, mit je 100 Vor-/Nachnamen, 365 Tagen und 40 Jahren hat man 146 Mio mögliche Werte. Wenn man von 1000 Teilnehmern ausgeht ist mit 99,65% Wahrscheinlichkeit kein doppelter Wert dabei. Bei 10.000 Teilnehmern komme ich aber nur noch auf eine Wahrscheinlichkeit von 71%, eine zufällige Kollision wäre dann sogar relativ wahrscheinlich. Formel siehe Geburtstagsparadoxon, ausrechnen z.B. mit dem bc.

Die PIS-Nummer mit einzurechnen würde gehen, allerdings ließe sich das dann nicht mehr einfach per Hand überprüfen. Man müsste durchführen

for i from 1 to $MAXPIS {if hash($i + $pers_daten)==PISDATA[$i] then print "Collision for PIS# $i"}

Da müsste man einen Weg finden das zu automatisieren, so dass es unter Windows, Linux, MacOSX... läuft, idiotensicher ist und ohne Blackbox auskommt. Japaner würden das als sehr schwierig bezeichnen. --Regani 15:57, 8. Jul. 2008 (CEST)

Abänderung des Systems (Zahlen)

Ich schlage vor das System abzuändern. Es soll ja ein WoT (Web of Trust) und kein CoM (Construct of Mistrust) sein. Wenn ich nämlich das WoT von PGP oder auch das ausgefeiltere WoT von Thawte Free E-Mail Certificates vergleiche, dann ist dieses hier extrem hart und vor allem auf Misstrauen basiert. Dagegen ist der Benutzerkreis viel kleiner und überschaubarer als PGP und Thawte und bräuchte gar keine eine so extreme Kontrolle um trotzdem sicher zu sein. Deshalb zwei Dinge, die meiner Meinung nach dringendst geändert werden müssen: 1. Anzahl Bürgen um verbürgt oder Vollbürge zu sein. 2. Rolle der Urbürgen.

Zu 1: Die Gemeinschaftseite von TAXman hat gezeigt, dass drei Bürgen pro verbürgter Account reichen. Der Unterschied zu TAXmans Gemeinschaftsseite ist sowieso nur der, dass nicht nur bestätigt wird, dass hinter dem Account eine real exisiterende Person (und keine Sockenpuppe davon) steht. Sondern beim PIS wird nochmals bestätigt, dass die Identität dieser Person sogar der Community bekannt ist. Das ist der Vorteil! Drei würden deshalb genügen und würden das System so auch einfacher und schneller machen. Da von den drei Vollbürgen ja sogar die Identität bekannt ist, könnten sie bei Manipulationsversuchen sehr schnell belangt werden. Drei Bürgen hier sind also sicherer als drei Bürgen bei der Gemeinschaftsseite! Für einen Vollbürgen sollten ebenfalls fünf Bürgen reichen, dann ist da immer noch eine Schwelle gelegt und das macht das System nochmals sicherer als bei der Gemeinschaftseite, aber acht Bürgschaften wie heute ist Pain in the ass wie das salopp ein Amerikaner ausdrücken würde :-). Bsp: Für Betrügereien bräuchte es also schon fünf korrupte Vollbürgen, was sehr unwahrscheinlich ist, da man diese Vollbürgen auch von der Identität her kennt und das ebenfalls sehr schnell in einer kleinen Community wie diede auffallen würde.

Zu 2: Eben es ist ein WoT und kein CoM. Ein Vollbürge würde ich genau die gleiche Rolle geben wie einem Urbürgem. Urbürgen sind also nur die erste Generation Vollbürgen, die aus einem anderen Grund als Bürgschaften von vornerein als sicher und vertrauenswürdig gelten. Das heisst also, dass ein Account, der von fünf Vollbürgen verbürgt ist, ebenfalls die Vollbürgschaft erhält, ohne dass es noch einen oder mehrere Urbürgen dazu bräuchte. Erst dann ist es eben ein echtes WoT: Ein Web (= Netz, welches mehrere Knoten hat und sich immer weiter spinnt und nicht jeder Knoten nochmals wieder an der Basis befestigt werden muss) of Trust (das Vertrauen, das jedem Knoten im Netz gleichwertig zukommt).

Meinungen? --micha Frage/Antwort 13:12, 8. Jul. 2008 (CEST)

Ja, das klingt nicht schlecht. Weniger notwendige Bürgen für die Vollbürgenschaft wären wirklich sinnvoll und auch die Abschaffung der Klausel, dass auch später noch immer drei Urbürgen dabei sein müssen. --Thogo ^Büro_Sofa 13:37, 8. Jul. 2008 (CEST)

Ja, ich wäre auch dafür. Aber vielleicht noch einen Urbürgen als Pflicht um zum Vollbürgen erhoben zu werden? --buecherwuermlein 13:49, 8. Jul. 2008 (CEST)

Warum? Bei Thawte kann man mit nur drei(!) erfahrenen Notaren zum Notar werden. (So wurde ich nämlich Notar.) Und dort sind die Teilnehmer einiges zahlreicher und das Vertrauen in dieses System ist bereits überall sehr gross. Noch ein Urbürge haben zu wollen ist immer ein wenig Misstrauen ins System bzw. in die Funktionsweise eines WoT ganz generell. Das wäre übrigens das einzige "WoT" (wenn man es dann überhaupt so nennen dürfte), dass eine solche Restriktion einbaut. --micha Frage/Antwort 14:26, 8. Jul. 2008 (CEST)

Ja, ich wäre auch für Änderungen. Ja zu Vollbürgen (B) nehmen die gleiche Rolle ein wie Urbürgen (U). Ja dazu, daß man lediglich drei Bürgen (U und/oder B) braucht, um Verbürgter (V) zu werden. Um allerdings selbst Vollbürge (B) werden zu können, schlage ich vor, daß man sich von sechs anstatt von fünf Bürgen (U und/oder V) bestätigen läßt. So würden die Hürden linear ansteigend aufgebaut sein, was schlicht eleganter ist und sich leichter merken läßt. Zudem ist es wichtig, daß auch Urbürgen (U) und Vollbürgen (B) sich weiter verbürgen lassen, obwohl sie es eigentlich nicht mehr bräuchten. So kann Mißbrauch gar nicht erst entstehen. Viele Grüße --Marbot 15:57, 8. Jul. 2008 (CEST)

Fünf wären aber praktikabler zum loslegen, da du (und ich nach Ninas Verbürgung) z.B. nun bereits Vollbürge wären. Bei sechs müssen wir nochmals eine Verbürgungs-Runde einleiten und das ist für mich hier (Zürich) wieder einiges schwieriger. Ps. wegen der Zahl: Bei der Gemeinschaftsseite ist man auch als "Verbürgter" bereits "Vollbürge". Der Unterschied bräuchte eigentlich nicht zwingend gezogen werden. Deshalb erachte ich den Vorteil von fünf auf sechs nicht mehr als allzu riesig, aber wie gesagt, der Nachteil wäre wieder, dass das System so wieder schwerfälliger wird. --micha Frage/Antwort

Nochmals kurz: Um das System eigentlich leichtfüssig zu machen, wäre es das Ziel, möglichst schnell, möglichst viele Vollbürgen zu haben. Wenn es also nicht zwingend aus sicherheitstechnischen Überlegungen notwendig ist, dass die Vollbürgen viele Bürgschaften haben, würde ich darauf verzichten. In diesem Fall ist weniger mehr. --micha Frage/Antwort 16:09, 8. Jul. 2008 (CEST)

Ps. ich würde mal behaupten, es könnte mathematisch aufgezeigt werden, dass jeder zusätzliche Bürge um einen Vollbürgen zu schaffen, das System exponentiell verlangsamt. Bei einem Bürgen als Vollbürge hätten wir das schnellste Tempo. Bei drei Bürgen als Vollbürge, in etwa das Tempo bei der Gemeinschaftsseite. Bei acht Bürgen pro Vollbürge ist das System bereits tot. Kleines Beispiel: Wären es sechs, müssen Marbot und ich noch einen Bürgen auftreiben, es geht also wieder länger, weil noch keine Vollbürgen exisiteren. Sind es dagegen fünf, dann wäre ich Vollbürge und könnte, da ich per Thawte Marbots Identität bereits kenne, ihn gleich verbürgen und er hätte sofort sechs Bürgschaften. Es ist einfach leichtfüssiger, je weniger Bürgschaften für einen Vollbürgen gebraucht werden. --micha Frage/Antwort 16:33, 8. Jul. 2008 (CEST)