Browse Source

Article on Social COntrol in SSB and Git-SSB

started post on social control in ssb

added html to gitignore

finishes article on social control in ssb
master
Vincent Truchseß 1 year ago
parent
commit
10f3f4a1ff
2 changed files with 121 additions and 0 deletions
  1. +1
    -0
      .gitignore
  2. +120
    -0
      blag/soziale_kontrolle.adoc

+ 1
- 0
.gitignore View File

@@ -13,3 +13,4 @@ pom.xml.asc
/site/*
/input/*
/templates/custom
*.html

+ 120
- 0
blag/soziale_kontrolle.adoc View File

@@ -0,0 +1,120 @@
= Missbrauchsverhinderung durch Soziale Kontrolle
VI
:date: 2019-09-29T20:56:47+02:00

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 link:../posts/ssb.html[*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
link:https://viewer.scuttlebot.io/@+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=.ed25519[@Christian
Bundy]
link:https://viewer.scuttlebot.io/%25K72sSk9yIc7gAPcvt2CMR0N7rrTkp0V3UHa%2Fbpo5rSI%3D.sha256[hier]
angemerkt hat gibt es die Möglichkeit, Git-Repositories quasi mit Bordmitteln
abzusichern. Nachdem ich mir
link:https://github.com/warner/git-lockup[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.

// vim: spell spelllang=de textwidth=80

Loading…
Cancel
Save