Der Fall, in dem FSE auf das FBI traf

• Der FSE-Betreiber verfolgte illegale Nutzer, die auf eine Fediverse-Instanz gelangt waren, und dokumentierte den Verlauf von BoardReader/SocialGist-Scraping bis hin zu einer Informationsanfrage des FBI anhand von Logs und E-Mails.
• Ausgangspunkt des Problems waren BoardReader-Suchergebnisse, die selbst Beiträge externer Server so darstellten, als seien sie FSE-Beiträge; dadurch seien sowohl illegale Nutzer zugeflossen als auch falsche Zuordnungen entstanden.
• BoardReader verbarg den User-Agent, nutzte Residential Proxies, Tor und Browser-Session-Replay und scrapte /api/v1/timelines/public?local=false; auch nach einer Sperre wurden die Anfragen fortgesetzt, was Serverlast und Kosten erhöhte.
• Das FBI schickte am 14. März 2023 eine Emergency Disclosure Request zu WitchKingOfAngmar, doch dieser Account war kein FSE-, sondern ein sneed.social-Nutzer, und auch der beigefügte Screenshot stammte nicht von FSE.
• Der Betreiber beobachtete, dass nach der Vergiftung des BoardReader-Index mit einer gefälschten Timeline bestimmte Formulierungen eine Flut von Facebook-Anfragen auslösten, und sah im Jahr 2024 durch die Berichterstattung über Torswats einen Teil des Kontexts zu den FBI-Interessen bestätigt.

---

Nachverfolgung, ausgelöst durch den Zufluss illegaler Nutzer

• Der FSE-Betreiber betrachtete Nutzer mit Bezug zu Pädophilie, die auf den Server gelangten, als existenzielle Bedrohung für FSE.
  • Das Hochladen illegaler Darstellungen von Kindesmissbrauch, das Interesse von Strafverfolgungsbehörden und die mögliche Beschlagnahmung von Geräten stellten unmittelbare Risiken dar.
  • Nach seiner Einschätzung verbreiteten manche Nutzer illegales Material auf mehreren Sites und prüften anschließend, welche Accounts nicht gesperrt wurden.
• Er versuchte abzuschrecken, indem er verfügbare Informationen wie IP, E-Mail und User-Agent veröffentlichte, doch der Effekt blieb begrenzt.
  • Viele luden Dateien hoch oder holten sie ab und verschwanden dann wieder; das Muster wirkte so, als suchten sie systematisch nach Orten, an denen sie nicht blockiert wurden.
• Bei der Suche nach dem Zuflussweg stellte sich heraus, dass der Referer-Header vieler Nutzer auf boardreader.com zeigte.

Die Methode der Nachverfolgung per Logs

• Dem Ganzen liegt die Annahme zugrunde, dass man beim Betrieb einer öffentlich erreichbaren Fedi-Instanz Bots, Scanner, Würmer und anomalen Traffic selbst analysieren können muss.
• Für die Log-Analyse wurden awk, tail -f, mawk -Winteractive, grep, sqlite3, R, sed, sort und psql verwendet.
  • awk wird als SQL-ähnliches Werkzeug für Text-Logs vorgestellt.
  • Zusätzlich kamen Netzwerk-Tools wie dig, whois, traceroute, tcpdump, iftop, Shodan und Tor-Exit-Listen zum Einsatz.
• Das Log-Format von Webservern wie nginx wurde angepasst, um beliebige Header, Antwortzeiten und Backend-Antwortzeiten mitzuloggen.
  • Die FSE-Logs wurden laut Aussage in ein annähernd tab-separiertes Format gebracht, damit sie sich leichter mit awk oder Tabellen-Tools verarbeiten ließen.
• Auch einfache Statistik wurde zur Erkennung von Anomalien genutzt.
  • Durch Berechnung von Mittelwert und Standardabweichung der Anfragezahlen wurden IPs, Endpunkte und Anfragemuster mit plötzlichen Ausreißern gefunden.
  • Zu bestimmten Zeitpunkten sei man so zu Einschätzungen wie „90 % der POST-Anfragen kommen von derselben Adresse“ gelangt.

Nachverfolgung von BoardReader/SocialGist

• boardreader.com war ursprünglich ein Forum-Suchwerkzeug; der FSE-Betreiber ist der Ansicht, dass die Site Fedi nicht richtig verstand und FSE deshalb wie ein einzelnes Forum behandelte.
  • Selbst öffentliche Beiträge anderer Instanzen seien so angezeigt worden, als wären sie Beiträge des Forums freespeechextremist.com.
  • SocialGist beschrieb sich als Anbieter von „accessible social data“, und laut Betreiber passten Blog-Angaben über einen Entwickler in Serbien zu den tatsächlichen IPs.
• Am 5. März 2023 gab es in den FSE-Logs keine expliziten Zugriffe von BoardReader, stattdessen wurde aber hochfrequentes Scraping von /api/v1/timelines/public?local=false entdeckt.
  • Der Browser gab sich als Chrome aus, war aber weit schneller als ein Mensch scrollen könnte.
  • Es gab A-Records von spider1.boardreader.com bis spider43, der tatsächliche Traffic kam jedoch laut Darstellung von 45.15.176.187, einer damals DediPath gehörenden IP.
• Nach einer IP-Sperre folgten viele Versuche von Residential-IP-Adressen aus den USA; der Betreiber schloss daraus, dass BoardReader Residential Proxies einkaufte, um der Erkennung zu entgehen.
• Am 8. März 2023 begann er mit awk, iptables und Ruby-Skripten, Anfragen mit bestimmten Tokens zu blockieren.
  • Danach tauchten Anfragen von einer serbischen ISP-IP auf, die auf devtools.boardreader.com verwiesen.
  • Diese Anfragen luden Ressourcen wie ein normaler Browser, holten sich einen Bearer-Token, führten JavaScript aus und nahmen dann mit diesem Token das Scraping wieder auf.
• Es wurden Antworten mit 429, 401, 403 und 500 getestet, doch der Scraper wiederholte die Anfragen nur noch häufiger und verursachte faktisch einen DoS.
  • Danach wurde 402 Payment Required zurückgegeben; währenddessen war der Zugriff auf die öffentliche TWKN-Timeline blockiert.

E-Mail-Wechsel mit SocialGist

• Der Betreiber fragte am 5. März 2023 bei [e-mail] nach Informationen zum Crawler an.
• Am 13. März 2023 kam von [e-mail] eine Antwort mit der Frage, was genau er wissen wolle.
  • Der Betreiber verlangte, dass nur lokale Beiträge geholt werden und dass ein User-Agent verwendet wird, der BoardReader eindeutig identifiziert.
  • Außerdem übermittelte er den gesamten ihm gehörenden IP-Adressbereich als Bereich, der vom Crawling ausgenommen werden solle, und informierte über den Zufluss von Nutzern aus dem Pädophilie-Umfeld.
• Dave erklärte, er werde das an das Engineering-Team weitergeben, doch der Betreiber meint, dass zur gleichen Zeit weiterhin ein Entwickler am Debugging des Scrapers arbeitete.
  • In den Logs fanden sich am 13. März 2023 Anfragen von 109.92.154.188, die auf devtools.boardreader.com verwiesen.
  • Der Betreiber schloss daraus, dass SocialGist zwar sagte, es zu stoppen, gleichzeitig aber weiter an Umgehungen arbeitete.

Die Emergency Disclosure Request des FBI

• Am 14. März 2023 erhielt der Betreiber von einer fbi.gov-Adresse eine E-Mail mit dem Betreff Emergency Disclosure Request.
  • Special Agent Peter Christenson verlangte Subscriber-Informationen zum Nutzer WitchKingOfAngmar.
  • Der Name des Anhangs lautete FSE Screen Shot.PNG.
• Nach Prüfung der Mail-Header, der Mailserver-Logs und der SPF-Informationen von fbi.gov kam er zu dem Schluss, dass die Mail tatsächlich vom FBI stammte.
• Der beigefügte Screenshot zeigte jedoch nicht FSE.
  • FSE wurde darin als „forum“ bezeichnet, und oben war „Forum • Blackrock Executiv...“ zu sehen.
  • Suchbegriffe wie „kill blackrock“ und „larry fink“ waren hervorgehoben.
  • Es war auch eine einfache Sentiment-Analyse enthalten.
  • Der Beitrag war 26 Tage vor der E-Mail erstellt worden, im Screenshot waren jedoch Zeitangaben wie „11 hours ago“ und „13 hours“ zu sehen.
• WitchKingOfAngmar war kein FSE-Nutzer, sondern ein Nutzer von sneed.social.
• Der Betreiber antwortete dem FBI, dass FSE keine Informationen zu diesem Nutzer habe und dass BoardReader zwar „Free Speech Extremist“ angeheftet habe, die Quelle des Beitrags aber nicht FSE sei.
  • Der FBI-Agent fragte daraufhin, wen er stattdessen kontaktieren solle, und der Betreiber verwies ihn auf die Prüfung des Ursprungsservers.

Der vermutete Ablauf von BoardReader über Facebook bis zum FBI

• Der Betreiber meint, dass FBI und BoardReader Unicode auf dieselbe Weise beschädigten und außerdem externe Server-Beiträge fälschlich als FSE-Beiträge zuschrieben.
  • Die ursprünglichen Unicode-Codepoints 1f9e2, 1f438, 1f44d seien in Kästchen mit Fragezeichen als Zeichen für ungültiges Unicode verwandelt worden.
• Aus diesen Indizien schloss er, dass das FBI BoardReader-Daten gesehen und daraufhin FSE kontaktiert habe.
• Auch am 15. März 2023 stellte BoardReader weiterhin Anfragen an FSE und erhielt nur 402-Antworten.
  • Der Betreiber veröffentlichte eine begrenzte öffentliche Erklärung und versetzte FSE in einen gesperrten Zustand.
  • Ohne Account waren weder TWKN noch die öffentliche Timeline sichtbar, und auch Registrierungen wurden geschlossen.
• Auch nach dem 16. März 2023 habe BoardReader weiterhin versucht, die Sperren mit Residential Proxies, Tor und pro Anfrage wechselnden User-Agents zu umgehen.

Gefälschte Timeline und Datenvergiftung

• Ab dem 24. März 2023 begann der Betreiber, aufgrund des fortgesetzten BoardReader-Scrapings und des anhaltenden Zuflusses aus dem Pädophilie-Umfeld eine gefälschte Timeline auszuliefern.
• Er schrieb ein kleines CGI-Skript, das JSON aus nicht existierenden Accounts und nicht existierenden Beiträgen generierte.
  • Zunächst waren die IDs zufällige 32-Bit-Zahlen; später wurde ein Teil des Anfragezeitpunkts eingemischt, damit sich die Inhalte innerhalb von BoardReader leichter verfolgen ließen.
  • Da nginx kein CGI unterstützt, wurden Anfragen an diesen Endpunkt an lighttpd weitergereicht.
  • Die Implementierung erfolgte nach eigener Aussage überwiegend in awk.
• In die Wortlisten der Fake-Posts wurden BoardReader-Suchbegriffe und Wortlisten mit Bezug zu CARNIVORE gemischt.
• Die gefälschten Beiträge wurden von BoardReader indexiert, und der Betreiber verglich zufällige IDs, die er in die BoardReader-Suche eingab, mit den Einträgen im Index und den FSE-Webserver-Logs.

Beobachtung einer Flut von Facebook-Anfragen

• Der Betreiber stellte anhand von Log-Histogrammen fest, dass Facebook massenhaft Anfragen an die URLs gefälschter Beiträge stellte.
  • Die Abschnitte mit vielen grünen/blauen 4 standen für 402-Antworten und stammten laut Darstellung fast ausschließlich von Facebook.
  • Die angefragten URLs entsprachen den gefälschten Beiträgen.
• Er geht davon aus, dass Facebook diese Beiträge unmittelbar nach ihrer Indexierung durch BoardReader abholte.
• Als die Wortliste der Fake-Posts auf nur noch „larry fink“ geändert wurde, stiegen die Facebook-Anfragen nach seiner Darstellung fast sofort stark an.
  • Nach dem Entfernen dieser Formulierung ging der Traffic zurück und stoppte.
  • Nach erneutem Einfügen setzte die Flut nach der Wartezeit auf die BoardReader-Indexierung wieder ein.
• Der Betreiber vermutete eine Kette aus awk CGI → lighttpd → nginx → BoardReader-Crawler → BoardReader-Index → Facebook → interne FBI-Suchoberfläche.
  • Welche Rolle Facebook in dieser Kette gegenüber dem FBI genau spielte, ob als Werkzeug oder als Datenspeicher, blieb laut ihm letztlich unklar.

Wie SocialGist gestoppt wurde

• Um Kosten durch überschrittene Bandbreite zu senken, wurden Antworten extrem verlangsamt und so justiert, dass sie erst kurz vor dem Timeout endeten.
  • Gelegentlich wurde das Ende des JSON absichtlich abgeschnitten, um Parsing-Fehler auszulösen.
  • Der Betreiber meint, BoardReader habe offenbar einen gewöhnlichen JSON-Parser verwendet und etwa eine Minute verbraucht, ohne brauchbare Daten zu erhalten.
• Danach fügte er in zufällig generierte Beiträge Daves Telefonnummer ein; am nächsten Tag antwortete Dave.
  • Dave sagte, er habe ein Jira-Ticket erstellt und werde bald Rückmeldung geben.
  • Nach einem kurzen Austausch stoppte das Scraping schnell, doch es dauerte etwa eine Woche, bis FSE aus dem BoardReader-Index verschwunden war.

Nachspiel, das sich durch die Torswats-Berichterstattung einordnen ließ

• Am 18. Januar 2024 berichtete Wired über die Festnahme von Alan Winston Filion aus Lancaster, Kalifornien.
  • Er wurde mit Torswats in Verbindung gebracht und soll laut Bericht Hunderte Falschmeldungen erzeugt haben, darunter Bombendrohungen und fingierte Geisellagen.
• Der Betreiber geht davon aus, dass WitchKingOfAngmar genau dieser Torswats war.
  • WitchKingOfAngmar wirke wie eine Anspielung auf „Lord of the Rings“.
  • Weil Torswats häufig sinnlose, bedrohlich klingende Tiraden gegen Larry Fink verfasst habe, glaubt er, dass das FBI deshalb an Drohungen mit Bezug zu Larry Fink interessiert gewesen sei.
• In diesem Nachspiel fügen sich für ihn die FBI-Anfrage, der Suchbegriff „larry fink“ und das Interesse an Bedrohungen gegen BlackRock-Führungskräfte teilweise zusammen.
• Offen bleiben jedoch weitere Fragen.
  • Was BoardReader heute eigentlich ist
  • Ob SocialGist BoardReader als plausiblen Vorwand benutzt
  • Welche Rolle Facebook in dieser Pipeline spielte
  • Ob Facebook dem FBI Werkzeuge bereitstellt oder eher als Datenspeicher genutzt wird

Rat an Fedi-Betreiber

• Der Betreiber sagt, wer Fedi-Daten haben wolle, solle statt Scraping lieber eine Fake-Instanz aufsetzen und an ein Relay hängen, weil das die Server weniger zerstöre.
  • Er hält auch diese Methode für unangemessen, meint aber, dass man damit zumindest Daten in Echtzeit erhalten könne, ohne Gegenstellen kaputtzumachen.
• Sichtbar würden nur laute, grobe Scraper; Akteure, die still ActivityPub-Software oder Relays modifizieren, um Daten zu sammeln, seien viel schwerer zu bemerken.
• Der Betreiber warnt, dass SocialGist nur deshalb nachverfolgbar gewesen sei, weil dort Fehler gemacht wurden, und dass sich schwer sagen lasse, wie viele Organisationen dasselbe tun, ohne solche Fehler zu begehen.

[GN⁺]

Hacker-News-Kommentare

• Der Link im Blogpost führt nur zu einer Liste von Instanzen, die sich für Deföderation entschieden haben.
  Der Grund, warum er nicht zur offiziellen Fediblock-Liste führt, ist, dass Fediblock vor einigen Jahren eingestellt wurde. Der Autor von Fediblock hat ausdrücklich klargestellt, dass die Liste in keiner Weise als endgültiges Urteil verwendet werden sollte und dass man die Kriterien der eingetragenen Instanzen sorgfältig mit den eigenen Maßstäben abgleichen müsse. Mein Bauchgefühl sagt mir, dass der Autor auf einen Fediblock-Eintrag verlinken wollte, ihn nicht finden konnte und ihn dann, ohne richtig nachzuprüfen, durch den ähnlichsten Link ersetzt hat.

  • Ich betreibe einen mittelgroßen Mastodon-Server; ein Nutzer von dort hat mir gegenüber das N-Wort benutzt, ich habe ihn beim Admin gemeldet, aber es passierte nichts, also habe ich blockiert.
    Das hat überhaupt nichts mit Fediblock oder irgendeinem gemeinschaftlichen Blockiermechanismus zu tun. Die Nutzer haben sich danebenbenommen, der Admin hat nichts unternommen, und ich habe einfach entschieden, dass ich nicht weiter mit ihnen reden möchte. Es ist lächerlich, wenn FSE darüber jammert, wegen irgendeiner Geheimgesellschaft blockiert zu werden. Auch ohne große Verschwörung können ganz normale Trolle andere Leute direkt so sehr nerven, dass mehrere Server die Verbindung kappen.
  • Fediblock wurde im September 2023 eingestellt, und in diesem Text gibt es jede Menge Zeitstempel, die zeigen, dass die Ereignisse davor stattgefunden haben.

• Mir gefiel, dass die Geschichte damit beginnt, dass man kein CAPTCHA einführen möchte, weil das echten Nutzern schadet, und sich die folgenden 80 % dann damit beschäftigen, wie lange offene Registrierungen und die öffentliche Timeline abgeschaltet waren und wie negativ sich das auf die Nutzer auswirkte.
  Trotzdem war es ein interessanter Text, und er hat mir sehr deutlich gemacht, dass ich es nicht könnte, selbst Community-Räume für andere online zu hosten.

• An diesem Text gefällt mir ziemlich viel: Eine Einzelperson betreibt Citizen Science, indem sie einen Teil der Informationssammel-/Überwachungsmaschinerie des FBI nachvollzieht; es gibt Fediverse-Drama-Schnipsel; und auch die Systemadministrations-Taktiken für Betreiber kleiner Server sind interessant.
  Die Person namens torswats wirkt wie ein ziemlicher Problemfall und wird am Ende verhaftet, was eine interessante Nebenhandlung ergibt. Der Autor wirkt ebenfalls ziemlich klug, und mir gefällt der Stil. Fünf Sterne, lesenswert.

  • Ein hervorragender Text mit genau der richtigen Menge technischer Details. Würde auch sehr gut als Vortrag auf einer Veranstaltung wie dem Chaos Communication Congress passen.
  • Man sollte auf die falschen Schlussfolgerungen achten, die der Autor zieht. Das FBI bat um Informationen zu einem Nutzer und schickte Screenshots mit Gewaltdrohungen, aber die Person von FSE kam sofort zu dem Schluss, dass es sich nur um harmloses Aufschneiden handle.
    Das gilt umso mehr, wenn man bedenkt, dass nur sechs Monate zuvor ein anderer CEO ermordet worden war. Gegen Ende des Textes stellt sich heraus, dass diese Person bereits zahllose Gewalttaten durch Stellvertreter begangen hatte. Es ist gut, dass die FSE-Person mit der Bundesbehörde kommuniziert hat, aber nach solchen Droh-Screenshots sofort anzunehmen, die Person könne unmöglich gewalttätig sein, zeigt eine gefährliche Voreingenommenheit.

• Da wird gesagt, Fediblock habe den falschen Eindruck erweckt, FSE habe etwas erlaubt, was es nie erlaubt habe, und dann wird auf eine Website verlinkt, deren Quellcode auf kiwifarms gehostet wird.
  Der Grund für die Blockierung ist, dass die meisten von uns nicht mit dem „Free Speech“-Lager interagieren wollen, und das ist im Grunde alles.

  • Das klingt wie eine Aussage, die logisch nicht an den Satz anschließt, auf den du antwortest. Was hat es mit Faktenprüfung zu tun, ob man jemanden blockiert oder nicht mag?

• Guter Text. Eine sehr kleine, ziemlich unwichtige und vielleicht auch falsche Korrektur:
  Das Wort „Negative“ im Screenshot der internen Suchmaschine wurde als Sentimentanalyse interpretiert; tatsächlich könnte es aber einfach ein „negatives“ Ergebnis im Sinne von: Dieser Beitrag passt nicht zur Suchintention, also ein Button zum Melden eines False Positives im internen System gewesen sein. In dieser Situation scheint Sentimentanalyse nicht besonders nützlich zu sein.

  • Da stimme ich nicht zu. Das „Negative“-Icon ist ein roter Menschenkopf. Wer würde so ein Icon für ein „False Positive“ wählen? Für mich ergibt „negative Stimmung“ mehr Sinn.

• Dass „Pädophile bei FSE aufgetaucht sind“, wirkt wie ein Problem des gesamten Fediverse. Zugegeben, bei Discord ist es genauso.

  • Im Grunde gilt das überall, wo man Fotos hochladen kann und es nicht mit dem Klarnamen verknüpft ist.
  • Bei Signal oder Telegram ist es dasselbe.

• Interessant, dass diese Sache wegen des Referer-Headers begonnen hat. Dass der Browser dem Server standardmäßig einen Teil meines Browserverlaufs mitteilt, wirkt wie ein Datenschutzproblem.
  Wenn ich mich richtig erinnere, hat Tor dieses Problem nicht.

  • Interessanterweise lässt sich das sowohl auf Nutzerseite als auch auf der Seite einstellen, die den Verweis sendet.
    Die meisten Browser, zumindest die relevanten, respektieren den vom verweisenden Site gesetzten Header referer-policy 1. Auch verbreitete Site-Frameworks wie Django haben Optionen, um das zu steuern 2. Da die meisten User Agents dem folgen, hätte die Indexierungsseite, wenn sie gewollt hätte, leicht verhindern können, dass dieser Header für die meisten Nutzer gesendet wird.

• Hätte es keine besseren technischen Methoden gegeben, Scraper abzuwehren? Etwa, IP-Adressen oder Domains am Eingangspunkt zu blockieren, statt die Requests zu verarbeiten. Vermutlich hätte man trotzdem noch für den Request-Traffic gezahlt.
  Gibt es nicht einen Markt für DDoS-Schutzdienste von Drittanbietern für API-Endpunkte, so etwas wie Cloudflare? Allerdings war das für „Free Speech Extremist“ wahrscheinlich keine passende Lösung, und es kostet auch etwas. Trotzdem hätte man in so einer Situation damit womöglich tatsächlich Geld sparen können.

  • „Also habe ich den Traffic der IPs, die gescrapt haben, auf dem Server verwerfen lassen. Problem gelöst! Daraufhin sah ich sofort massenhaft Versuche von anderen IPs. Es waren private US-Heimanschlüsse. Sie kauften Residential Proxies.“