Websites herunterladen, die Social9 nutzen

Über Social9

Eingebettete Skripte von Drittanbietern sind ein seltsames Forschungsgebiet im Web, denn der Code, der sie lädt, überdauert meist den Grund, aus dem er eingefügt wurde. Ein Publisher kopiert während einer Kampagne für Social-Media-Traffic ein Snippet in ein Template, die Kampagne endet, das Snippet bleibt im Theme. Wer einen Bestand von Installationen liest, liest daher zum Teil, was Website-Betreiber einmal über Reichweite geglaubt haben, konserviert im Markup, lange nachdem man von dieser Überzeugung abgerückt ist.

Social9 ist Code dieser Art, ein Loader, den ein Publisher in ein Theme einfügt und dann vergisst. Stand Oktober 2026 sehen wir Social9 auf 116 Websites. Die eigene Website des Anbieters verkauft heute etwas völlig anderes, nämlich eine Plattform, die mit KI Social-Media-Inhalte für Marketing-Teams erstellt und zeitlich plant. Eine Erkennung lässt sich hier deshalb besser als Hinweis auf die Seiten lesen, die das Skript enthalten, denn als Zeichen einer laufenden Kundenbeziehung.

Aufschlussreicher als die Gesamtzahl ist die Streuung der Releases dahinter. Über die beobachteten Installationen hinweg erfassen wir 17 verschiedene Versionsangaben, darunter Version 3.5.1. Ein Skript, das in so vielen Releases gleichzeitig im Umlauf ist, wird nicht zentral aktualisiert. Jede Website bleibt auf dem Build stehen, der aktuell war, als das Snippet ins Theme kopiert wurde, und niemand kehrt später zurück, um daran etwas zu ändern. Eine Fragmentierung dieses Ausmaßes ist das normale Schicksal von JavaScript, das per Kopieren und Einfügen eingebunden wird, und messbar ist sie hier nur, weil der Loader seinen Build angibt.

Genau diese Versionsstreuung kann Ihnen eine Einzelabfrage nicht liefern. Zu wissen, dass eine Domain einen bestimmten Build einsetzt, sagt etwas über diese Domain. Zu wissen, wie sich ein ganzer Bestand auf die Releases verteilt, zeigt dagegen, wie JavaScript von Drittanbietern in freier Wildbahn altert, und das ist wichtig, wenn Sie Risiken in der Lieferkette bewerten, die Ablösung eines Widgets planen oder einen Sicherheitshinweis verfassen, der angeben muss, wie viel der installierten Basis ein bestimmtes Problem noch erreichen würde.

Das Publikum für eine solche Liste teilt sich klar in zwei Lager. Auf der einen Seite stehen Anbieter, die um denselben Platz konkurrieren, also um den Platz für Engagement- und On-Page-Conversion-Widgets, die Publisher in ein Template einfügen. Sie suchen Website-Betreiber, die bereits ohne Bedenken ein externes Skript einsetzen. Wer das einmal getan hat, tut es mit hoher Wahrscheinlichkeit wieder, weshalb diese Gruppe besser konvertiert als eine kalte Liste von Content-Websites. Auf der anderen Seite stehen alle, die wissen wollen, was diese Skripte tatsächlich tun, von Datenschutzforschern, die verfolgen, wohin Besucherdaten wandern, bis zu Sicherheitsteams, die extern gehosteten Code inventarisieren, der auf Seiten ausgeführt wird, die sie nicht selbst verwalten.

Beide Gruppen brauchen dieselbe Grundlage, nämlich die vollständige Menge der Domains statt eines Urteils über eine einzelne. Eine Prüfung pro Domain bestätigt eine Hypothese, die Sie bereits haben. Erst der Download erlaubt es Ihnen, überhaupt eine zu bilden und sie mit dem nächsten Crawl erneut zu prüfen.

Eine Einschränkung sollte man klar benennen. Ein Skript, das verzögert geladen, über einen Tag-Manager eingebunden oder nach dem Auslaufen des Kontos in einem Template zurückgelassen wurde, wird anders erfasst als eines, das tatsächlich im Einsatz ist. Wir prüfen, ob der Loader zum Zeitpunkt des Crawls in der Seite vorhanden war. Ob er noch irgendjemandem etwas nützt, lässt sich am Markup nicht ablesen.