Missbrauchsverhinderung durch Soziale Kontrolle

Posted on Sep 29, 2019 by VI

Ganz schön Pathetischer titel, wa?

Keine Angst, dies wird kein Sozialkritisches Traktat über Gesellschaft, Macht und Moral sondern es geht hier um was relativ technisches.
Ich bin ja ein wenig im SSB -Netzwerk unterwegs. Dabei bin ich unter anderem auf Git-SSB gestoßen. Wie der Name vermuten lässt handelt es sich dabei um eine Software um Git-Repositories in SSB zu hosten. Nun hab ich nach langem Frickeln herausgefunden wo ich mit dem Hammer draufhauen muss, damit sich das auch installieren und benutzen lässt und wollte eigentlich einen Artikel darüber für meinem Tech-Blog schreiben. Dabei kamen mir ein Paar Fragen auf, die zu weiterem Nachdenken geführt haben und ich dachte mir, das Thema wäre halbwegs diskussionswürdig.
Ich will mich hier ganz wertfrei mit dem Thema der Sozialen Kontrolle im Bezug auf SSB (und Git-SSB im Speziellen) auseinandersetzen.

Note
Ich habe hier bewusst nicht auf Git-SSB verlinkt, da es nicht im web verfügbar ist. Stattdessen wird die Software komplett im SSB-Netzwerk entwickelt und gehostet.

Free Listening

In SSB gilt allgemein das Prinzip des Free listenings. Das Heißt, jede kann sagen was sie will aber niemand hat ein Recht darauf, gehört zu werden.
Um Spam, Hatespeech oder ähnliches zu vermeiden gibt es einen Blocking-Mechanismus. Blocke ich eine Entität, so höre ich auf, deren Feed zu replizieren. Gleichzeitig ist die Block-Message öffentlich, kann kommentiert werden etc. Gutmütige clients werden, sobald sie diese Nachricht sehen, meinen Feed auch nicht mehr an diese Entität ausliefern.
In Anbetracht der Kurzen Reichweite eines Friend-to-Friend Netzwerks nimmt man an, es gibt eine Art Herdenimmunität gegen Spam. Ob dies auch in Zukunft noch zutrifft wird sich erst zeigen.

Note
Der Einfachheit halber werde ich ab hier jegliches unerwünschtes Verhalten einfach als Spam bezeichnen.

Die Mechanismen

Insentivierung

Hier meine These:

  • Reichweite entsteht nur über soziale Kontakte

  • Der Großteil der Nutzer hat ein großes Interesse, nicht unter Spam zu leiden

Daraus kann man zum einen folgern, dass das Gro der Nutzer ein Interesse daran hat, Blockierungen von anderen Nutzern mit umzusetzen und sich selbst möglichst gutartig zu benehmen, um nicht ausgeschlossen zu werden.

Konsens

Damit entsteht so etwas wie ein lokaler Konsens, der sich aus dem Verhalten der für einen Sichtbaren Nutzer ergibt. Das Ausmaß der Sozialen Kontrolle ist also abhängig von den eigenen Vorlieben, die sich in der Auswahl der Kontakte manifestiert.

Der Fall Git-SSB

Die Probleme

Nun, im Fall von Git-SSB hat Spam deutlich tiefere Implikationen als in der Zwischenmenschlichen Kommunikation.
Dazu muss man wissen, dass im Prinzip jede Schreibrechte auf jedem Repository hat, dass sie sehen kann. Ein Repository wird schließlich aus allen Feeds zusammengesetzt, die der Betrachter sehen kann.
Hier ist es also möglich, dass ein Angreifer oder Troll Schadcode in ein fremdes Repository pusht. Dieser Angreifer kann zwar vom Eigentümer des Repositorys blockiert worden sein, jedoch nicht vom unbedarften User, der sich nur mal eben das Tool XY installieren will.

Lösungsversuche

Wie @Christian Bundy hier angemerkt hat gibt es die Möglichkeit, Git-Repositories quasi mit Bordmitteln abzusichern. Nachdem ich mir git-lockup einmal angeschaut habe fiel mir allerdings auf, dass das Projekt unmaintained zu sein scheint, zudem wirft dieser Ansatz bei mir nur weitere Fragen auf.

Was also in Zukunft tun?

Mir erscheint es als eine gute Lösung, ein Message-Format zu definieren, in dem der Eigentümer eines Repositorys legitime Contributer posten kann. Die Clients könnten dann beim Zusammensetzen nur diese Feeds akzeptieren.
Eine solche Funktionalität ist jedoch noch nicht implementiert.

Was Kann man jetzt tun?

Ich habe eine Zeit lang darüber nachgedacht und bin darauf gekommen, folgendes zu tun:

  • Zu meinem Proton-Repository gibt es einen Projekt-Thread. Dieser ist in meinem SSB-Profil verlinkt. Dort werden unter anderem die Nutzer, denen ich push-access auf das Repo gewähre gepostet.

  • Sollte jemand in mein Repo gepusht haben bekomme ich das spätestens beim versuch, selbst zu pushen mit. Dann kann ich den entsprechenden Nutzer blocken und force-pushen. Damit ist die Integrität meines Repos wider Hergestellt.

  • Wenn jemand mein Repo clonen oder pullen will, ist sie dazu angehalten sich vorher die Push-Aktivitäten des Repos anzuschauen und darauf zu achten, das der letzte Push von einem legitimen Nutzer stammt. Ist dies nicht der Fall bitte ich darum, mir Bescheid zu geben, die Person zu blocken und nach dem Checkout auf die letzte legitim gepushte Revision zu hard-resetten.

Konsequenzen

Genau wie Spam im Bezug auf Git-SSB eine größere Gefahr darstellt als im Bereich des Microbloggings, so sind auch die Konsequenzen eines Blockings größer. So kann es passieren, dass einem Spammer auch der Lesezugriff auf ein Repository deutlich erschwert wird.

Tags: metassb