Wie LinkedIn Automatisierung erkennt: Erkenntnisse aus der Codeanalyse von 16 Erweiterungen, Cloud-Tests und LinkedIns Erkennungsmechanismen

Wir haben 16 Erweiterungen zur Automatisierung von Aktivitäten auf LinkedIn analysiert und untersucht, wie sie mit Sitzungen, Cookies, browserseitigen Aufrufen und Anbieterservern umgehen.

Außerdem haben wir sieben Cloud-Dienste mit jeweils zwei Konten getestet und die ihnen zugewiesenen Exit-IP-Adressen anhand einer unabhängigen Datenbank zur Bewertung der IP-Reputation und des Betrugsrisikos geprüft.

Im dritten Teil der Untersuchung analysierten wir LinkedIns eigenen Seitencode. Dieser Code umfasst einen Erweiterungsscanner mit 6.167 Zielen, einen sogenannten Spectroscopy-Scanner für das Document Object Model (DOM) und einen Gerätefingerabdruck aus 48 Merkmalen, der mit den Anfragen einer Sitzung übertragen werden kann.

Dieser Leitfaden zeigt, welche Signale das Kontorisiko erhöhen können, bei welchen Automatisierungsarchitekturen mehr dieser Signale sichtbar werden und wie Sie jede Erweiterung selbst in etwa fünf Minuten prüfen können.

Kurzfassung: 9 Punkte, die Sie vor jeder Installation kennen sollten

1. LinkedIn kann Chromium-basierte Browser auf bekannte Erweiterungen prüfen. Dies wird als Active Extension Detection (AED) bezeichnet. Im untersuchten Datensatz prüfte LinkedIns Code 4.934 Chrome-Erweiterungs-IDs; die Liste wuchs um etwa 12 Einträge pro Tag.
2. Cookie-Bridge-Tools schaffen eine der riskantesten Konfigurationen. Diese Erweiterungen lesen Ihr LinkedIn-Sitzungscookie li_at und laden es in die Cloud des Anbieters hoch. Der Anbieter kann anschließend von seiner eigenen Rechenzentrums-IP aus auf Ihr Konto zugreifen und Aktionen in Ihrem Namen ausführen. Wir fanden dieses Codemuster bei 9 weitverbreiteten Tools.
3. Cookies zu lesen ist nicht dasselbe wie Ihre Sitzung zu exportieren. Einige Tools lesen Cookies, halten die Sitzung jedoch lokal. Entscheidend ist, wohin der Cookie-Wert übertragen wird. Deshalb haben wir diesen Pfad für jedes Tool in diesem Leitfaden verfolgt.
4. Das Blockieren von LinkedIn-Telemetrie kann das Tool erkennbar machen, statt es zu verbergen. Einige Erweiterungen blockieren Tracking-Endpunkte von LinkedIn. Wenn ein Endpunkt weiterhin Daten übermittelt, kann LinkedIn erkennen, dass andere Telemetriepfade blockiert werden.
5. Ihr Gerätefingerabdruck kann mit den Anfragen Ihrer Sitzung übertragen werden. LinkedIn erfasst 48 Gerätesignale, darunter Grafik, Audio, Schriftarten, die lokale IP über Web Real-Time Communication (WebRTC) und Automatisierungsmerkmale. Dieser Fingerabdruck wird verschlüsselt und während der Sitzung an API-Anfragen angehängt.
6. Die Erkennung lässt sich am besten als Scoring-Modell verstehen. Das Vorhandensein von Erweiterungen, Codespuren, Netzwerkanomalien und das Kontoverhalten können jeweils Risikosignale hinzufügen. Konservative Tageslimits helfen, beheben jedoch keine riskante Architektur.
7. Manuelle Kontaktaufnahme schützt nicht vollständig vor Einschränkungen. Hohes Volumen, massenhaftes Öffnen von Profilen und zu viele Meldungen der Art „Ich kenne diese Person nicht“ können auch Nutzer betreffen, die LinkedIn manuell verwenden.
8. Cloud-Tools können eine sichtbare IP-Spur hinterlassen. In unserem Cloud-Test mit sieben Tools platzierten fünf der sechs serverseitig arbeitenden Tools unter den sieben getesteten Diensten Konten hinter Rechenzentrums- oder Proxy-IPs, die von einer unabhängigen Datenbank als hochriskant eingestuft wurden. Ein Anbieter gab beiden Testkonten dieselbe IP, und drei voneinander unabhängige Tools leiteten den Datenverkehr über denselben vorgelagerten Anbieter.
9. Kontosicherheit ist kein Nischenthema. In neun englischsprachigen Märkten beziehen sich monatlich etwa 12.050 Suchanfragen auf LinkedIn-Einschränkungen, Kontolimits, Identitätsprüfungen oder Sperren.

Warum Sie diesem Bericht vertrauen können

Dieser Leitfaden basiert auf drei Arten von Belegen: Produkthistorie, Erweiterungscode und Live-Cloud-Tests.

Die erste Quelle ist Alexander Erin, der Gründer von Linked Helper, der diese Rolle seit Oktober 2016 innehat.

Er schrieb die erste Version von Linked Helper, eine Chrome-Erweiterung. Auf ihrem Höhepunkt belegte sie im Chrome Web Store den ersten Platz für die Suchanfrage „LinkedIn“ und hatte rund 80.000 Nutzer. Er beobachtete außerdem, wie LinkedIns frühe Erkennungssysteme konkurrierende Erweiterungen beeinträchtigten. Im August 2019 hatte er drei Tage Zeit, Linked Helper gegen eine zweite Erkennungswelle abzusichern.

Danach entschied das Team, den Chrome Web Store zu verlassen und Linked Helper als eigenständige Desktopanwendung neu zu entwickeln.

Die zweite Belegquelle bildet der analysierte Code.

Für diesen Bericht luden wir die öffentlich verfügbaren Versionen der Erweiterungen von 16 konkurrierenden Tools herunter, bereiteten den minifizierten Code wieder lesbar auf und verfolgten, was sie mit Ihrer LinkedIn-Sitzung tun. Wir prüften den Code Datei für Datei und hielten Zeilenangaben fest, wenn sich das Verhalten verifizieren ließ.

Wir nutzten außerdem die BrowserGate-Untersuchung, in der LinkedIns JavaScript-Code aus der Produktionsumgebung analysiert wurde. Diese Arbeit dokumentierte Erkennungssysteme, die unser Experte bereits seit 2019 aus Sicht der Abwehrseite beschrieben hatte.

Die dritte Quelle ist ein Live-Test.

Code kann zeigen, was eine Erweiterung tun kann, jedoch nicht, welche IP-Adresse ein Cloud-Dienst zuweist, nachdem Ihre Sitzung dessen Server erreicht hat. Um diesen Teil zu prüfen, registrierten wir uns bei sieben Cloud-Tools mit jeweils zwei Konten aus demselben Land, Frankreich.

Für jedes Konto erfassten wir die Exit-IP-Adresse, ihre Reputation bei IPQualityScore (IPQS), den Gerätetyp, das von der Cloud angezeigte Betriebssystem (OS) und ob die zugehörige Erweiterung auf LinkedIns Scanliste erschien. IPQS ist eine unabhängige Datenbank zur Bewertung der IP-Reputation und des Betrugsrisikos und führt LinkedIn auf seiner Website als Kunden auf.

Am Ende dieses Leitfadens verfügen Sie über drei praktische Ergebnisse:

1. Eine Risikokarte der wichtigsten Automatisierungsarchitekturen
2. Eine Checkliste auf Codeebene zur Prüfung jeder Erweiterung
3. Vergleichswerte (benchmarks) für einen sichereren Betrieb, sofern solche Werte anwendbar sind

Warum Kontosicherheit das Hauptthema ist

Einschränkungen von LinkedIn-Konten bleiben für Vertriebsteams, Recruiter, Gründer, Agenturen und Growth-Teams ein wichtiges Thema. Jeden Monat suchen Menschen nach Antworten zu Einschränkungen, Identitätsprüfungen, Kontaktanfragelimits und plötzlichen Einschränkungen oder Sperren von Konten.

Die meisten Empfehlungen beschränken sich auf tägliche Aktivitätslimits und das Nachrichtenvolumen. Diese Faktoren sind wichtig, bilden jedoch nur einen Teil des Risikos ab. LinkedIn kann auch technische Signale beobachten, darunter Browsererweiterungen, Gerätefingerabdrücke, Cloud-Sitzungsumgebungen und die IP-Reputation.

Dieser Bericht konzentriert sich auf diese technische Ebene. Statt zu mutmaßen, was LinkedIn möglicherweise erkennt, untersuchen wir, wie Automatisierungstools aufgebaut sind, welche erkennbaren Signale sie erzeugen und wie sich die jeweilige Architektur auf das Kontorisiko auswirken kann.

1. Die Architekturen hinter dem Risiko der LinkedIn-Automatisierung

Marketingbezeichnungen wie „Cloud“, „AI“, „Chrome-Erweiterung“ und „sicher“ erklären das Kontorisiko nicht von selbst.

Die entscheidenden Fragen lauten:

1. Wie greift das Tool auf Ihr Konto zu?
2. Wo werden die Vorgänge ausgeführt?
3. Wohin fließen Ihre Daten?
4. Welche technischen Spuren hinterlässt das gesamte Setup?

Die meisten Tools zur Automatisierung von Aktivitäten auf LinkedIn lassen sich den folgenden Bausteinen zuordnen. Einige Tools verwenden ein Modell, andere kombinieren mehrere Modelle im selben Produkt.

Datenfluss der Dux-Soup-Chrome-Erweiterung. Rote Knoten zeigen, dass Ihre LinkedIn-Sitzung oder Ihre Daten in die Cloud eines Anbieters übertragen werden. Graue Knoten zeigen Daten, die in Ihrem Browser verbleiben.

1.1 Browsererweiterungen, die in Ihrem Browser ausgeführt werden

Eine Browsererweiterung kann mehrere Automatisierungsmuster kombinieren. Der Unterschied zwischen diesen Mustern ist wichtig, da einige Ihre Sitzung lokal halten, während andere Sitzungsdaten in die Cloud eines Anbieters übertragen.

a) Lokales Scraping über Ihre eigene Sitzung

Bei diesem Modell verbleibt Ihre LinkedIn-Sitzung auf Ihrem Computer. Die Erweiterung ruft LinkedIns interne API, bekannt als Voyager, direkt aus Ihrem Browser auf und verwendet dabei Ihre bestehende LinkedIn-Anmeldung.

Technisch kann dies wie fetch(..., {credentials: "same-origin"}) mit einem aus Ihrem JSESSIONID-Cookie abgeleiteten CSRF token-Header aussehen. Cross-Site-Request-Forgery-(CSRF-)Token helfen zu belegen, dass eine Anfrage zur aktuell angemeldeten Browsersitzung gehört.

Nur die extrahierten Ergebnisse, beispielsweise Profile oder E-Mail-Adressen, werden zum Anbieter hochgeladen. Ihr Sitzungstoken selbst wird nicht exportiert.

Zu den in unserer Prüfung verifizierten Beispielen gehören Octopus CRM, GetProspect, Findymail, Apollo sowie Dux-Soup in den Tarifen Turbo, Pro und Free. Octopus CRM hatte in dieser Gruppe die sauberste Implementierung, da es die Erweiterungsberechtigung cookies von Chrome nicht anforderte und lokale Voyager-Aufrufe wie fetch(voyager, {credentials:"same-origin", "CSRF-token": U()}) verwendete.

Der Vorteil: Ihre IP-Adresse, Browsersitzung und Ihr Gerätefingerabdruck bleiben konsistent. Ihr Sitzungstoken verlässt Ihren Browser nicht.

• Eine isolierte Voyager-Anfrage ohne den begleitenden Seitenverkehr kann ein unnatürliches Anfragemuster erzeugen, das wir in §2.7 behandeln.
• Die Erweiterung kann außerdem für LinkedIns Erweiterungsscanner sichtbar bleiben, die wir in §2.1 und §2.2 behandeln.

Hinzu kommt ein Wartungsrisiko.

Viele Erweiterungen beruhen auf fest codierten Annahmen über die Struktur von LinkedIns interner API sowie über Anfrageformate, Header und Parameter. Wenn LinkedIn diese Anforderungen ändert, kann eine veraltete Erweiterung fehlerhafte oder ungewöhnliche Anfragen senden, bis der Anbieter die Änderung erkennt, eine Korrektur veröffentlicht und die Nutzer das Update installieren.

b) Cookie-Bridge- oder Sitzungsupload-Erweiterungen

Bei diesem Modell verlässt Ihre LinkedIn-Sitzung Ihren Computer. Die Erweiterung liest den LinkedIn-Cookie-Speicher über Aufrufe wie chrome.cookies.getAll(...), wählt Werte wie li_at, JSESSIONID oder li_a aus und sendet diese Werte an den Server des Anbieters.

Anschließend kann die Cloud des Anbieters von ihrer eigenen IP-Adresse aus auf Ihr Konto zugreifen und Aktionen in Ihrem Namen ausführen. Unser Experte beschrieb eines dieser Tools so: „Die Erweiterung dient als Brücke, um das Cookie zu übertragen, und hat keinen anderen Zweck.“

Die folgende Tabelle zeigt unsere Erkenntnisse aus der Codeanalyse. Sie unterscheidet außerdem zwischen Tools, die Sitzungsdaten exportieren, und Tools, die die LinkedIn-Sitzung lokal halten und nur Ergebnisse senden.

Expandi: der interessanteste Fall im Datensatz

Expandi verdient über die Expandi-Connector-Erweiterung eine genauere Betrachtung, da es mehrere Techniken zeigt, die im Markt für LinkedIn-Automatisierung eingesetzt werden. Diese Techniken können einige Risiken verringern, zugleich jedoch Signale hinterlassen, die Erkennungssysteme beobachten können.

Wenn Sie verstehen, wie diese Techniken funktionieren und wo sie weiterhin erkennbare Spuren hinterlassen, erhalten Sie einen nützlichen Rahmen zur Bewertung aller anderen Automatisierungstools.

Datenfluss der Expandi-Connector-Chrome-Erweiterung, anhand der Codeprüfung rekonstruiert. Rote Knoten zeigen, dass Ihre LinkedIn-Sitzung oder Ihre Daten in die Cloud eines Anbieters übertragen werden. Graue Knoten zeigen Daten, die in Ihrem Browser verbleiben.

Technik 1: Ein Skript in den Seitenkontext von LinkedIn injizieren

Ein Content-Skript befindet sich normalerweise in einer isolierten Umgebung und kann nicht auf XMLHttpRequest der Seite zugreifen.

Um diese Einschränkung zu umgehen, injiziert Expandi einen echten <script src="chrome-extension://ohcplcf…/linkedin/injected.js">-Knoten in das aktive DOM (linkedin/content.js:2-7).

Dieser Knoten enthält eine literale chrome-extension://-URL innerhalb der Seite. LinkedIns Spectroscopy-Scanner (§2.2) kann das DOM passiv durchsuchen, nach dieser Teilzeichenfolge suchen, die 32 Zeichen lange Erweiterungs-ID extrahieren und sie melden.

Für diesen Erkennungspfad ist keine Zielliste erforderlich. Eine Aussage wie „Wir stehen nicht auf der AED-Liste“ klärt die Frage nicht, wenn die Erweiterung eine sichtbare chrome-extension://-Ressource injiziert. In diesem Fall wird die Bereitstellungsmethode selbst zur Spur.

Beleglage: Im Code gefunden. Die Injektion ist eindeutig, und der Spectroscopy-Mechanismus ist in der BrowserGate-Analyse des Codes aus der Produktionsumgebung dokumentiert.

Technik 2: XMLHttpRequest.prototype.send per Monkey-Patch verändern

Expandis injected.js:3-27 überschreibt die ursprüngliche send-Methode der Seite, sodass jede von Ihrem Browser abgerufene Antwort der Voyager-API in die Erweiterung kopiert werden kann. Der Patch wird im selben globalen Kontext wie LinkedIns eigener JavaScript-Code ausgeführt. Genau deshalb wird das Skript in die Seite injiziert.

Die veränderte send-Methode entspricht nicht mehr der ursprünglichen Browserimplementierung, und jedes Skript auf der Seite kann dies prüfen. Beispielsweise gibt Function.prototype.toString.call(XMLHttpRequest.prototype.send) den Quellcode des Wrappers statt "function send() { [native code] }" zurück; Expandi versucht nicht, toString zu maskieren.

Auch eine unveränderte Referenz aus einem neuen Same-Origin-<iframe> würde nicht mit der modifizierten send-Methode der Seite übereinstimmen. Dadurch entsteht ein erkennbarer Unterschied zwischen der ursprünglichen Browser-API und der aktuell auf der Seite vorhandenen send-Implementierung.

LinkedIn setzt bereits Prüfmechanismen dieser Klasse ein. Die in §2.6 behandelte interne Fingerprinting-Engine-Gruppe APFC/DNA umfasst direkte Anti-Bot-Prüfungen sowie eine Funktion namens signals, die widersprüchliche Browserangaben erkennen kann. LinkedIn lädt außerdem das externe HUMAN-/PerimeterX-Skript von li.protechts.net (§2.8a), das Manipulationen wie veränderte Prototypen und abweichendes toString-Verhalten erkennen soll.

Beleglage: Der Patch wurde im Code gefunden. Der Erkennungspfad ergibt sich aus der Funktionsweise des Patches.

Wir fanden auf diesem Pfad keine Blockierung der Telemetrie, sodass die Ergebnisse solcher Prüfungen weiterhin zurückgemeldet werden können. Wir behaupten nicht, beobachtet zu haben, wie LinkedIn einen bestimmten Expandi-Nutzer markiert. Wir beschränken uns daher auf die Aussage, dass diese Erkennung technisch möglich ist und der Patch deutlich genug sichtbar wäre.

Technik 3: Einen separaten Voyager-GraphQL-Aufruf für E-Mail-Daten senden

Expandis injected.js:34-44 sendet eine programmatische Anfrage GET /voyager/api/graphql mit withCredentials:true. Dabei wird aus Ihrem JSESSIONID ein CSRF-token gebildet (injected.js:30-31), um Kontaktinformationen oder E-Mail-Daten abzurufen, die bei einem normalen Profilaufruf standardmäßig nicht geladen werden.

LinkedIn kann dies als auffälliges Anfragemuster erkennen (§2.7). Es handelt sich um einen API-Aufruf ohne entsprechende Nutzeraktion, der nach dem Laden einer Profilseite ausgelöst wird, obwohl der Nutzer „Contact info“ nicht geöffnet hat.

Bei großem Umfang wird das Muster „Jedes aufgerufene Profil lädt zusätzlich seine E-Mail-Adresse“ zu einem charakteristischen Muster automatisierter Datenanreicherung. Es ist in serverseitigen Protokollen sichtbar, ohne dass der Browser mitwirken muss. Der Aufruf verwendet Ihre echte Sitzung und enthält den verschlüsselten Fingerprint-Header, doch das Verhaltensmuster ist das verräterische Merkmal.

Beleglage: Im Code gefunden. Der Aufruf ist eindeutig, und das auffällige Anfragemuster ist konstruktionsbedingt serverseitig beobachtbar.

Der schwerwiegendste Befund: Einige Erweiterungen erfassen mehr als LinkedIn-Daten

Die schwerwiegendste Variante ist die Erfassung des vollständigen Cookie-Speichers über jede Website hinweg, auf der Sie angemeldet sind, und nicht nur auf LinkedIn. Die Erweiterung expandi.ai von Konnector, einem anderen Anbieter als Expandi.io, gibt chrome.cookies.getAll({}) über alle Domains hinweg an ihre Web-App zurück.

Selbst der routinemäßig wirkende isInstalled-Handshake kann den vollständigen Cookie-Speicher offenlegen (KonnectorContent.js:10-28, background.js:19). Damit geht das Problem über das Risiko der LinkedIn-Automatisierung hinaus und betrifft die allgemeine Kontosicherheit.

Beispiel PhantomBuster

PhantomBuster gehört zu einer eigenen Kategorie. Es trägt Ihr li_at-Cookie mit einem Klick automatisch in seine Cloud-Einrichtungsseite ein (contentscript.js:5265-5266). Die Übertragung erfolgt zwar nicht unbemerkt, ist aber nach einem einzigen Klick möglich.

PhantomBuster kann außerdem Sitzungscookies für 15 Plattformen erfassen (background.js:5140-5230). Deshalb wird die Cookie-Wiedergabe in §1.2a der höchsten Risikokategorie zugeordnet.

c) DOM-Automatisierung innerhalb der LinkedIn-Seite

Einige Erweiterungen automatisieren LinkedIn, indem sie Schaltflächen für Sie anklicken und eigene Bedienfelder, Schaltflächen oder Steuerelemente in die LinkedIn-Seite injizieren.

Dadurch entstehen zwei Arten technisch erkennbarer Spuren. Jedes injizierte Element kann einen eindeutigen Selektor besitzen, nach dem ein Scanner suchen kann (§2.2), und jeder programmatische Klick trägt isTrusted:false. Über die normale Erweiterungs-API gilt, wie unser Experte erklärte: „Sie können es nicht vortäuschen – der Wert ist immer falsch“ (§2.5).

In der Praxis injizieren nur wenige Tools umfangreiche Elemente in die Seite. Tools, die dies tun, erzeugen jedoch Signale, die LinkedIn ohne Zielliste untersuchen kann, da der Scanner direkt prüfen kann, was sich innerhalb der Seite verändert hat (§2.2).

1.2 Cloud-Dienste, die auf Anbieterservern ausgeführt werden

Ein Cloud-Dienst benötigt Zugriff auf Ihr LinkedIn-Konto, bevor er etwas automatisieren kann. In der Praxis gibt es zwei wesentliche Einstiegspunkte.

a) Cookie-Wiedergabe über eine synchronisierte Sitzung

Dies ist die serverseitige Hälfte des Cookie-Bridge-Modells aus §1.1b. Es handelt sich um eine der riskantesten Konfigurationen, da Ihre Sitzung außerhalb Ihres eigenen Browsers wiederverwendet werden kann.

Das Risiko entsteht durch mehrere gleichzeitig auftretende Signale:

• Eine Sitzung kann parallel unter zwei IP-Adressen erscheinen. Unter Ihrer IP-Adresse, während Sie LinkedIn weiter nutzen, und unter der Rechenzentrums-IP des Anbieters, während die Cloud automatisierte Vorgänge ausführt. Unser Experte bezeichnete dies als „eindeutiges Indiz“.
• Cookie-Wiedergabe entspricht keiner normalen Anmeldung. Sie erzeugt keinen sichtbaren Eintrag auf LinkedIns Seite „active sessions“, sodass Sie sie in Ihren Kontoeinstellungen nicht sehen können.
• Der Cloud-Tarif von Dux-Soup liest die Cookies beim Verbinden automatisch aus und überträgt sie.
• Wenn die Cloud das Cookie in ihrem eigenen Browser wiedergibt, stimmt der Gerätefingerabdruck möglicherweise nicht mit dem bisher für Ihre Sitzung verwendeten Fingerabdruck überein (§2.6).
• Wenn die Cloud den Browser umgeht und die API direkt aufruft, kann sie ein unnatürliches Anfragemuster erzeugen (§2.7).

Sobald die Sitzung in die Cloud eines Anbieters übertragen wurde, können Sie die Umgebung, die in Ihrem Namen auf das LinkedIn-Konto zugreift, nicht mehr beobachten.

b) Neue Anmeldung aufseiten des Anbieters

Der zweite Pfad ist eine neue Anmeldung aus der Umgebung des Anbieters. Der Dienst startet einen Virtual Private Server (VPS) oder Browseremulator und meldet sich mit Ihrem Nutzernamen, Passwort, E-Mail-Code und Code für die Zwei-Faktor-Authentifizierung (2FA) an.

Einige Anbieter haben uns diesen Ansatz in nicht öffentlichen Gesprächen beschrieben. Ein Tool für Beiträge in sozialen Medien teilte uns mit, es melde sich über einen VPS mit einem Browser im Stil von Multilogin an und erledige anschließend alles Weitere über die API. Eine andere bekannte Plattform für die Akquise beschrieb „einen echten Browser für die seltenen Aktionen, den Rest über die API“.

(Wir nennen sie nicht, aber … PhantomBuster dokumentiert seine Cloud-Browser-Architektur anerkennenswerterweise öffentlich.)

Unser Experte bewertet diesen Pfad als weniger riskant als die Cookie-Wiedergabe. Eine neue Anmeldung von einem neuen Computer und Standort kann zumindest einem Vorgang ähneln, den eine echte Person durchführen könnte. Dennoch werden die IP-Adresse, die Geografie, die Zeitzone und der Fingerabdruck der Cloud mit Ihrem Konto verknüpft. Dies behandeln wir in §2.9 und §2.10.

Was die Cloud anschließend tut: nur API oder emulierter Browser

Nach der Anmeldung muss die Cloud die eigentlichen Vorgänge ausführen. Sie kann einen emulierten Browser verwenden, LinkedIns APIs direkt aufrufen oder beides kombinieren.

Unser Experte kennzeichnet die cloudseitige Ausführung als Einschätzung und nicht als direkt belegte Tatsache. Seine Bewertung ist eindeutig: „Ich denke, sie greifen alle direkt und intensiv auf die API zu. Ausnahmslos. Mit einer Wahrscheinlichkeit von 95 %.“

Er nennt drei Gründe für diese Einschätzung:

1. API-Aufrufe sind erheblich einfacher als das Parsen sich ständig ändernder LinkedIn-Seiten.
2. LinkedIn hat die API noch nicht ausreichend gehärtet, um Dienste zu stoppen, die ihre API-Nutzung öffentlich eingeräumt haben.
3. Funktionen für einen Echtzeit-Posteingang in den Dashboards dieser Tools erfordern in der Regel direkten API-Zugriff. Eine aktuelle Unterhaltung für eine bestimmte Person bei Bedarf abzurufen, lässt sich mit einem im Hintergrund scrapenden Browser nicht zuverlässig in diesem Takt leisten.

Das systemische Risiko besteht darin, dass Cloud-Dienste, die ausschließlich die API verwenden, von fest codierten Anfragen abhängen. LinkedIn muss die API lediglich um einen speziellen Header, nutzerspezifische Endpunktnamen oder eine ähnliche Änderung ergänzen, damit jeder fest codierte Client ausfällt oder ungewöhnlich erscheint.

Die BrowserGate-Analyse ergab, dass ein Teil dieser Infrastruktur bereits vorhanden ist. Ein verschlüsselter Fingerprint-Datenblock wird in die HTTP-Header jeder API-Anfrage eingefügt, die von einer echten Browsersitzung stammt (§2.6 und §2.7). Die Infrastruktur zur Unterscheidung von echtem Browserdatenverkehr und isolierten API-Clients scheint bereits bereitgestellt zu sein. Ob aus der Erfassung eine Durchsetzung wird, entscheidet LinkedIn.

Dieser Vorbehalt gilt für den gesamten Bericht: Von außen lässt sich nicht beweisen, welche Methode eine Cloud verwendet – auch ein API-Client kann eine Anmeldung imitieren. Wir berichten, was wir im Code sehen, und kennzeichnen cloudseitiges Verhalten als „sehr wahrscheinlich“.

Was wir bei der Registrierung gemessen haben (7 Tools, jeweils 2 Konten)

Die Codeanalyse endet an der Grenze der Erweiterung. Die Cloud selbst ist für den Nutzer eine Blackbox, auch wenn LinkedIn möglicherweise mehr erkennen kann.

Zwei Merkmale kann diese Blackbox jedoch nicht vollständig verbergen: die Ihrem Konto zugewiesene Exit-IP-Adresse und den angezeigten Gerätefingerabdruck. Um dies zu prüfen, registrierten wir uns bei sieben Cloud-Tools mit jeweils zwei Konten, alle aus demselben Land: Frankreich.

Anschließend prüften wir jede zugewiesene IP-Adresse bei IPQualityScore (IPQS). Zwei Konten pro Tool sind wichtig, da sich daran erkennen lässt, ob ein Anbieter Infrastruktur kundenübergreifend wiederverwendet.

Was ist IPQualityScore (IPQS)?

IPQS ist ein unabhängiger Dienst zur Betrugsprävention, der seit mehr als 10 Jahren am Markt ist. Er bewertet IP-Adressen anhand von Signalen aus seinem eigenen Netzwerk aus Honeypots, Fallen, Crawlern und Missbrauchsdatenquellen.

Für jede IP-Adresse gibt IPQS mehrere nützliche Felder zurück:

• fraud_score von 0 bis 100.
• Indikatoren für Proxy, Virtual Private Network (VPN) und Tor.
• Verbindungstyp, beispielsweise Rechenzentrum, Privatkundenanschluss oder Mobilfunk.
• Geolokalisierungsdaten.
• Hinweise auf kürzlich festgestellten Missbrauch.

Es gibt keinen offiziellen Grenzwert, der aus einer IP-Adresse ein abschließendes Sicherheitsurteil macht. Dennoch behandeln die eigenen Beispiele von IPQS Werte über 75 als hohes Risiko, und das Unternehmen gibt für die Erkennung von Proxys und VPNs eine Genauigkeit von etwa 99,95 % an.

Wir verwenden IPQS als unabhängigen Referenzpunkt dafür, was ein modernes Betrugsabwehrsystem erkennen könnte. Eine stark missbrauchte IP-Adresse, ein bekannter Proxy-Endpunkt oder eine von vielen unabhängigen Konten gemeinsam verwendete Rechenzentrumsadresse können Signale darstellen, die Risikosysteme üblicherweise auswerten.

Rechenzentrums-IPs sind nicht automatisch bösartig. Ihnen wird häufig weniger vertraut als Verbindungen über Privatkunden- oder Mobilfunkanschlüsse, da sie von Hosting-Anbietern und nicht über Anschlüsse von Privatkunden stammen. Im Kontext von LinkedIn können sie aufschlussreicher werden, wenn viele Konten über dieselbe Cloud-Infrastruktur erscheinen.

IPQS war auch deshalb nützlich, weil seine Geolokalisierungsdaten während unserer Tests häufig mit den Angaben übereinstimmten, die LinkedIn in den Sicherheitssitzungen des Kontos anzeigte. Einige Proxy-Anbieter warben mit Standorten, die nicht mit dem von IPQS oder LinkedIn ermittelten Land übereinstimmten. Dadurch entsteht ein weiterer Risikofaktor: eine geografische Abweichung zwischen dem angegebenen und dem beobachteten Verbindungsstandort.

IPQS ist nicht LinkedIns private Risiko-Engine. Der Wert ist weder ein Urteil über die Kontosicherheit noch eine rechtliche Bewertung. Er dient als unabhängiger Vergleichsmaßstab (benchmark) für die Qualität und Reputation der IP-Adressen, die Automatisierungstools Nutzerkonten zuweisen.

Ergebnisse des Cloud-Registrierungstests

Was die Tabelle zeigt

1. Skylead ist das deutlichste warnende Beispiel.

Beide Testkonten verwendeten exakt dieselbe Rechenzentrums-IP, 58.97.254.1, mit einem IPQS-Risikowert von 100. Zwei Konten über dieselbe Rechenzentrums-IP entsprechen einem Muster geclusterter Konten, das LinkedIns Logik für parallelen Zugriff auswerten kann (§2.9).

2. Die markierte Infrastruktur wurde gemeinsam genutzt – und nicht nur innerhalb einer Marke.

Dripify, Skylead und We Connect leiten ihren Datenverkehr alle über denselben vorgelagerten Anbieter, HostRoyale Technologies (ASN 203020). Wenn ein IP-Adressbereich des Anbieters aufseiten von LinkedIn weniger Vertrauen genießt, können mehrere Tools gleichzeitig betroffen sein.

3. HeyReach brachte ein zusätzliches Problem bei der Kontrolle über die Sitzung mit sich.

Seine IP-Adressen hatten IPQS-Risikowerte von 100, und seine Erweiterung blockierte die Abmeldung auf zwei Arten: durch Abfangen der Navigation über webNavigation (background.js:1-17) und durch eine declarativeNetRequest-Regel (rules.json:1-14). Dadurch kann verhindert werden, dass der Nutzer die Sitzung ungültig macht, nachdem er das vollständige Cookie-Array über api.heyreach.io/.../CreateLinkedInAccountFromCookies übergeben hat.

4. Meet Alfred bildete in diesem Test den unauffälligen Gegenpol.

Es war das einzige Tool, das beiden Konten unauffällige IP-Adressen mit IPQS-Risikowerten von 0 gab, und es täuschte einen mobilen User-Agent vor. Eine unauffällige IP-Adresse betrifft jedoch nur ein Signal. Das Tool speichert weiterhin Zugangsdaten in seiner Cloud und führt von einem anderen Computer aus Aktionen im Namen des Nutzers aus.

5. Niemand prüft die Ihnen zugewiesene IP-Adresse.

Keines der sieben Tools stellte eine Prüfung der Proxy-Qualität bereit. Ein Tool kann eine markierte Adresse zuweisen oder ein Nutzer einen ungeeigneten Proxy hinzufügen, ohne eine eindeutige Warnung zu erhalten. „Standortkontrolle“ bedeutet außerdem meist Kontrolle auf Länderebene und nicht auf Ebene von Bundesstaaten, vergleichbaren Verwaltungsregionen oder Städten (§2.9).

Wir können nicht sehen, was diese Server intern tun, und kennzeichnen den Ausführungsmodus als „sehr wahrscheinlich“. Bei der IP-Adresse, der gemeinsam genutzten Infrastruktur, dem Fingerabdruck und dem Status auf der Scanliste handelt es sich jedoch nicht um Schlussfolgerungen: Wir haben sie gemessen (siehe die obige IPQS-Erklärung).

1.3 Browserbasierte Tools, die einen vollständigen Browser steuern

Browserbasierte Automatisierung verwendet eine vollständige Browserumgebung statt lediglich einer leichtgewichtigen Erweiterung oder eines isolierten API-Clients. Diese Kategorie gliedert sich in zwei sehr unterschiedliche Modelle.

Cloudbasierte Browsertools

Ein cloudbasiertes Browsertool führt einen Browser wie Headless Chrome oder Puppeteer auf dem Server des Anbieters aus. PhantomBuster ist der einzige Anbieter in dieser Gruppe, der diese Architektur öffentlich einräumt.

Auch dieses Modell hat Schwächen.

Puppeteer ist erkennbar. Für die Erkennung automatisierter Browser hat sich eine eigene Anti-Bot-Branche entwickelt.

Das Hosting mehrerer Konten erzeugt außerdem ein Korrelationsrisiko, wenn viele „Nutzer“ den Grafikprozessor (GPU), den Audiostack und andere Fingerprint-Merkmale eines Servers teilen.

Eigenständige Desktoptools

Ein eigenständiges Desktoptool führt einen separaten Chromium-basierten Browser auf dem Computer des Nutzers aus. Linked Helper verwendet dieses Modell.

Dadurch hinterlässt das Tool weniger technisch erkennbare Spuren als eine Chrome-Erweiterung oder eine Cloud-Kontofarm. Es gibt keine Chrome-Web-Store-ID, die LinkedIns AED-Scanner (Active Extension Detection) prüfen könnte (§2.1), keinen in die LinkedIn-Seite injizierten Erweiterungscode (§2.2 und §2.3), und das Konto behält die lokale IP-Adresse und den Gerätefingerabdruck des Nutzers.

Hinzu kommt ein struktureller Vorteil. LinkedIn kann jede öffentliche Erweiterung aus dem Chrome Web Store in Ruhe analysieren und einen Detektor entwickeln, bevor dieser bereitgestellt wird. Bei einer eigenständigen Desktopanwendung müssen Erkennungstests in die Produktionsumgebung übernommen werden, wo sie beobachtet werden können.

Browserbasiert bedeutet nicht automatisch sicher. Das Modell reduziert lediglich einen Teil der technischen Exposition. Die Entscheidungen der Entwickler zu Fingerprinting, Navigation, Aktionszeitpunkten, Verzögerungen und Klicksimulation beeinflussen das Risiko weiterhin.

Ausführliches Beispiel: Dux-Soup verwendet mehrere Muster in einem Paket

Die meisten Tools passen in eine Zeile der Architekturübersicht. Dux-Soup unterscheidet sich, da config.getEdition() je nach Tarif eine andere Architektur bereitstellt.

Das macht Dux-Soup zu einem nützlichen Beispiel für diesen Leitfaden. An diesem einen Produkt lassen sich je nach Konfiguration lokales Scraping, Sitzungsupload, AED-Sichtbarkeit, Telemetrieblockierung und hohe Volumenlimits beobachten.

Datenfluss der Dux-Soup-Chrome-Erweiterung. Rote Knoten zeigen, dass Ihre LinkedIn-Sitzung oder Ihre Daten in die Cloud eines Anbieters übertragen werden. Graue Knoten zeigen Daten, die in Ihrem Browser verbleiben.

• Free, Pro und Turbo verwenden lokales Scraping (§1.1a). Voyager wird im Browser des Nutzers mit einem aus JSESSIONID abgeleiteten CSRF-token aufgerufen, sodass die Sitzung lokal bleibt. Risikostufe: mittel.
• Cloud verwendet einen Sitzungsupload (§1.1b und §1.2a). Der Service Worker führt chrome.cookies.getAll({domain:"linkedin"}) aus und sendet anschließend den vollständigen Cookie-Speicher, localStorage und navigator-Daten über PUT /api/{user}/sessions/{domain} an app.dux-soup.com. Danach steuert er das Konto über einen Socket.io-Kanal (sw.js:1, libs/socket-io/socket.io.js:1562). Dies war die umfangreichste Sitzungsnutzlast, die wir bei einem Tool gefunden haben.
• Die Erweiterung befindet sich nachweislich auf LinkedIns AED-Liste (§2.1). Die Erweiterungs-ID ppdakpfeaodfophjplfdedpcodkdkbal und die Prüfdatei fetchforwarder.js erscheinen in detection_db.json. Bei jedem Besuch kann LinkedIn chrome-extension://…/fetchforwarder.js abrufen; ein erfolgreicher Treffer kann anzeigen, dass die Erweiterung installiert ist, bevor der Nutzer etwas anklickt.
• Die Anti-Detect-Konfiguration erzeugt ein eigenes Signal (§2.8). declarativeNetRequest-Regeln blockieren li/track, sensorcollect, protechts und merchantpool (rules.json; UI-Schalter killtracking). Diese Regeln stehen in einer statischen JSON-Datei, die jeder lesen kann, und das dadurch entstehende Ausbleiben von Telemetriedaten kann zur Anomalie werden.
• Die Limits kombinieren konservative und aggressive Einstellungen (§6). maxinvites ist standardmäßig auf angemessene 20 pro Tag gesetzt. Dieselbe UI erhöht maxvisits auf 500 pro Tag und bietet einen „Turbo“-Scan von etwa 10 Seiten pro Minute, was weit über normalem menschlichem Surfverhalten liegt.

2. Technisch erkennbare Spuren: Was LinkedIn sehen, erfassen und vergleichen kann

Dies ist der technische Kern des Leitfadens. Über Jahre hinweg ließ sich ein großer Teil von LinkedIns Erkennungslogik nur anhand der Erfahrungen der Abwehrseite beschreiben. Die BrowserGate-Untersuchung änderte dies durch die Analyse von LinkedIns JavaScript-Code aus der Produktionsumgebung, darunter ein Modul mit etwa 2,7 MB.

Diese Analyse fand drei Systeme, die innerhalb von LinkedIns Seiten zusammenarbeiten:

1. Active Extension Detection (AED) prüft Ihren Browser aktiv auf installierte Erweiterungen (§2.1).
2. Spectroscopy durchsucht das DOM passiv nach Spuren von Erweiterungen (§2.2).
3. APFC/DNA erfasst einen Gerätefingerabdruck aus 48 Merkmalen (§2.6).

Diese Signale fließen in LinkedIns Telemetriepipeline einschließlich des Endpunkts li/track ein (§2.4). Der Erweiterungsscan wird in Chromium-basierten Browsern ausgeführt, darunter Chrome, Edge, Brave, Opera und Arc. BrowserGate fand im Code eine literale Prüfung mit userAgent.indexOf("Chrome").

Die Zielliste wuchs im untersuchten Zeitraum von 38 Erweiterungen im Jahr 2017 auf etwa 461 im Jahr 2024 und anschließend auf 4.934. Das entspricht zuletzt einem Wachstum von etwa 12 neuen Einträgen pro Tag und zeigt, dass die Liste gepflegt und nicht aufgegeben wurde.

4.934 bezeichnet eindeutige Chrome-Erweiterungs-IDs, während sich 6.167 auf die umfassendere Liste der Prüfziele aus ID und Datei bezieht.

Im Folgenden wird jeder Erkennungsvektor dargestellt: Mechanismus → was LinkedIns Server erreicht → welche Tools oder Konfigurationen dadurch erkannt werden können → wie Sie ihn selbst prüfen können.

2.1 Der Erweiterungsscanner (AED): Eine installierte Erweiterung kann sichtbar sein

LinkedIns Seitencode enthält ein fest codiertes Array aus Paaren im Format {extension id, file}. Dazu können Dateien wie Logos, popup.html, manifest.json oder jede andere Ressource gehören, die eine Erweiterung über web_accessible_resources zugänglich macht.

Die Seite führt unbemerkt fetch()-Aufrufe für Pfade wie chrome-extension://<id>/<file> aus. Ist die Anfrage erfolgreich, kann LinkedIn erkennen, dass die Erweiterung installiert ist.

Die konkrete Implementierung im Produktivcode ist relevant, weil der Scan möglichst unauffällig ablaufen soll:

• Er kann über Promise.allSettled als Bündel von etwa 6.200 parallelen Abrufen ausgeführt werden.
• Er kann mit einer konfigurierbaren Verzögerung staggerDetectionMs auch nacheinander scannen, wodurch er im Bereich „Network“ weniger auffällt.
• Er kann über requestIdleCallback auf Leerlaufzeiten des Browsers warten, sodass Sie keine Verzögerung bemerken.
• Fehler werden durch leere catch-Blöcke unterdrückt, sodass die Konsole leer bleibt.
• Ergebnisse werden als AedEvent {browserExtensionIds: [...]} übertragen.

Befindet sich die Erweiterung auf LinkedIns Liste, kann ihre Installation bei jedem Besuch erfasst werden, bevor der Nutzer etwas anklickt.

Sie können dies in etwa drei Minuten prüfen.

Öffnen Sie linkedin.com, rufen Sie DevTools auf, öffnen Sie anschließend „Sources“ und durchsuchen Sie alle geladenen Dateien nach der ID Ihrer Erweiterung. Die ID finden Sie unter chrome://extensions.

Öffnen Sie dann „Network“, filtern Sie nach li/track und laden Sie LinkedIn neu. Sie können beobachten, wie die gebündelten Telemetrie-POST-Anfragen die Seite verlassen. Für eine eingehendere Prüfung durchsuchen Sie LinkedIns JavaScript-Pakete nach AedEvent oder chrome-extension://.

2.2 Der Spectroscopy-Scanner für das DOM: keine Liste erforderlich

Ein zweites System durchsucht die aktive Seite selbst. Es durchläuft rekursiv das gesamte DOM, einschließlich Textknoten und Attributwerten, und sucht nach der Teilzeichenfolge chrome-extension://.

Wenn es diese Zeichenfolge findet, extrahiert es die 32 Zeichen lange Erweiterungs-ID und meldet ein SpectroscopyEvent.

Dies unterscheidet sich von AED, da keine Zielliste erforderlich ist. Eine neue Erweiterung kann weiterhin erkannt werden, wenn sie ein Element, einen Stil, ein Iframe oder ein Skript injiziert, das auf eigene chrome-extension://-Ressourcen verweist.

Zusammen decken AED und Spectroscopy zwei häufige Zustände von Erweiterungen ab.

• AED kann eine installierte, aber inaktive Erweiterung erkennen.
• Spectroscopy kann eine Erweiterung erkennen, die die LinkedIn-Seite aktiv verändert.

Dieser Scanner gilt für das DOM-Automatisierungsmodell aus §1.1c.

2.3 Seitenschnappschüsse aus einem Web Worker

Zu zufälligen Zeitpunkten kann ein Hintergrund-Worker einen strukturellen Schnappschuss der Seite erfassen. Der Schnappschuss enthält Tags ohne ihren Textinhalt sowie script-/style-Elemente mit Inhalt.

Der Schnappschuss wird verschlüsselt und zur serverseitigen Spurensuche gesendet. Sie können nicht erkennen, wonach LinkedIn sucht, da diese Suche nicht in Ihrem Browser stattfindet.

Wir kennen diesen Mechanismus aus unmittelbarer Erfahrung. Es handelt sich um den Algorithmus, der im August 2019 die erste Version der Chrome-Erweiterung von Linked Helper erkannte. Die kurzfristige Lösung bestand darin, die Erweiterungskopie jedes Nutzers strukturell einzigartig zu machen, wodurch Zeit gewonnen wurde. Diese Erfahrung war ein Grund dafür, dass Linked Helper den Chrome Web Store verließ und als eigenständige Desktopanwendung neu entwickelt wurde.

Wir stellen dies als historischen Sachverhalt dar. LinkedIn verfügte bereits lange vor den BrowserGate-Befunden über diese Art der Seitenstrukturerkennung.

2.4 Die Telemetriepipeline: li/track

Die oben beschriebenen Systeme laufen bei https://www.linkedin.com/li/track zusammen. Der Methodenname im Code lautet fireTrackingPayload.

Dieser Endpunkt empfängt Verhaltensereignisse wie Mausbewegungen, Klicks und Eingaben sowie Scannerergebnisse wie AedEvent und SpectroscopyEvent.

Die Datenübertragung ist auf hohe Zuverlässigkeit ausgelegt:

• Pro Anfrage werden bis zu 29 Ereignisse gebündelt.
• Fehlgeschlagene Anfragen werden bis zu 4-mal wiederholt.
• Die Nutzlast wird über compressToBase64 mit Lempel-Ziv-Komprimierung (LZ) komprimiert.

Benachbarte Endpunkte verarbeiten Fingerprint-Daten, darunter /platform-telemetry/li/apfcDf und /apfc/collect.

Merken Sie sich diese Namen, da sie in §2.8 erneut auftreten. Erweiterungen, die LinkedIn-Telemetrie blockieren möchten, müssen den vollständigen Satz blockieren. Ein ausgelassener Endpunkt kann die Blockierung selbst erkennbar machen.

2.5 isTrusted: das Klick-Flag, das ein Content-Skript normalerweise nicht ändern kann

Jedes DOM-Ereignis besitzt das schreibgeschützte Flag isTrusted. Ein echter menschlicher Klick gibt true zurück.

Ein von einem Content-Skript einer Erweiterung erzeugtes Ereignis gibt false zurück. Dazu gehören dispatchEvent, new MouseEvent und programmatische .click()-Aufrufe. Über die normale Erweiterungs-API gilt die eindeutige Aussage unseres Experten: „Sie können es nicht vortäuschen. Der Wert ist immer falsch.“

Ein präziser Vorbehalt, damit die Aussage einer Überprüfung standhält: Über die API chrome.debugger erzeugte Ereignisse können isTrusted:true zurückgeben. Chrome zeigt dann jedoch dauerhaft ein gelbes Banner mit dem Hinweis an, dass dieser Browser von einer Erweiterung debuggt wird. Diese Möglichkeit besteht, bleibt aber nicht verborgen.

Nach dem letzten gesicherten Kenntnisstand unseres Experten setzte LinkedIn dieses Merkmal noch nicht flächendeckend durch. Sein Kommentar lautete: „Es ist eine Frage der Zeit.“ LinkedIn benötigt dafür eine einzige if-Anweisung.

2.6 Der Fingerabdruck aus 48 Merkmalen (APFC): das technische Erkennungsprofil Ihres Computers

Was ist ein Browserfingerabdruck?

Ein Browserfingerabdruck ist eine technische Momentaufnahme Ihres Computers. Er kann umfassen, welcher Grafikprozessor (GPU) ein Testbild rendert, wie Ihr Audiostack ein Signal verarbeitet, welche Schriftarten installiert sind, sowie Bildschirm, CPU-Kerne, Arbeitsspeicher (RAM), Zeitzone und weitere Merkmale.

Jedes einzelne Merkmal ist für sich genommen wenig aussagekräftig. Zusammengenommen können die Merkmale nahezu einzigartig sein. Sie sind außerdem schwer überzeugend zu fälschen, da dafür die Eigenheiten eines anderen Computers reproduziert werden müssen und nicht nur eine Browserzeichenfolge geändert werden muss.

LinkedIns Fingerprinting-Engine aus der Produktionsumgebung mit dem internen Namen APFC/DNA erfasst 48 Merkmale. Die wichtigsten Gruppen sind:

• Hardware und Betriebssystem (OS): CPU-Kerne, RAM, 6 Bildschirmmetriken, Touch-Funktion, Akku und Plattform.
• Grafik, Audio und Schriftarten: Canvas-Hash, WebGL-Anbieter und -Renderer, 65 zusätzliche WebGL-Parameter, Reaktion von AudioContext-Oszillator und -Kompressor sowie installierte Schriftarten.
• Netzwerk: lokale IP-Adresse über WebRTC, Verbindungstyp, Downlink und Round-Trip Time (RTT).
• Umgebung: mit zwei Methoden gemessene Zeitzone, Sprache, Plugins, MIME-Typen, Kameras, Mikrofone und Lautsprecher über enumerateDevices sowie Speicherbesonderheiten.
• Direkte Anti-Bot-Signale: webdriver, Erkennung von Automatisierungsframeworks, Inkognitomodus und eine Funktion namens signals, die gefälschte Kombinationen aus OS, Browser, Auflösung oder Sprache markieren kann.

Ein Detail ist besonders erwähnenswert. Do Not Track wird erfasst, aber aus dem Hash ausgeschlossen. LinkedIn zeichnet die Einstellung also auf, sie beendet jedoch nicht den hier beschriebenen umfassenderen Fingerprinting-Ablauf.

Die Momentaufnahme wird mit RSA-Verschlüsselung über einen öffentlichen Schlüssel und apfcDfPK verschlüsselt, in globalThis.apfcDf gespeichert und anschließend als HTTP-Header an spätere API-Anfragen der Sitzung angehängt. BrowserGate verweist für dieses Verhalten auf SyncCollectionHandler und das Feature-Flag sync.apfc.headers.

Der Fingerabdruck wird somit nicht einmal gesendet und anschließend vergessen. Er kann mit den Aktionen Ihrer Sitzung übertragen werden.

Für Cloud-Automatisierung entstehen dadurch zwei wesentliche Probleme:

1. Ein Cloud-Dienst, der Ihren echten Fingerabdruck nie erfasst hat, kann ihn nicht reproduzieren. Unser Experte formulierte es so: „Um ihn zu fälschen, müsste man ihn zuerst erfassen.“
2. Einige Fingerprint-Daten zu erfassen genügt nicht. Sie müssten exakt auf dieselbe Weise wie bei LinkedIn erfasst werden („Wenn sie ein anderes Dreieck zeichnen, ist es ein anderer Hash“). Die Konsistenzprüfung signals existiert gerade deshalb, weil grobe Fälschungen bereits häufig genug sind, um sie zu erkennen.

2.7 Das Anfragemuster: Eine Aktion erzeugt viele Anfragen

Öffnen Sie ein beliebiges LinkedIn-Profil bei laufenden DevTools. Sie sehen dann, dass eine Gruppe von Anfragen gemeinsam ausgelöst wird. Ein normaler Seitenbesuch kann Markup, Voyager-Aufrufe, Telemetrie, Vorabrufe und weitere unterstützende Anfragen umfassen.

Ein ausschließlich API-basiertes Tool kann ein anderes Muster erzeugen. Auf die Profildaten wird zugegriffen, der begleitende Besuch der Profilseite findet jedoch nicht statt. Unser Experte beschrieb es so: „Auf das Profil wird zugegriffen, aber die Profilseite wird nie besucht und der übliche Seitenverkehr bleibt aus.“

Das ist eine Anomalie im Anfragemuster. Sie kann allein anhand serverseitiger Protokolle sichtbar sein.

LinkedIn verfügt außerdem über mehrere aktive Möglichkeiten: nutzerspezifische Umbenennung von Endpunkten, spezielle Header und Köderanfragen für neue Testkonten. Wie in §2.6 erwähnt, ist der spezielle Fingerprint-Header bereits in der Produktionsumgebung vorhanden.

Eine ausschließlich API-basierte Cloud muss sich zwischen zwei schwierigen Möglichkeiten entscheiden. Sie kann versuchen, diesen Header zu fälschen, ohne den zugehörigen Fingerabdruck korrekt zu erfassen, oder sie kann Anfragen ohne denselben browsergestützten Kontext senden. Beide Optionen können ein Muster hinterlassen.

2.8 Telemetrie blockieren: die Anti-Detect-Konfiguration, die sich selbst erkennbar machen kann

Einige Erweiterungen versuchen, sich zu verbergen, indem sie LinkedIns Erkennungs- und Telemetrieendpunkte über die API webRequest blockieren. Die Schwäche besteht darin, dass die Sperrliste vollständig sein muss.

Wenn die Erweiterung einen Endpunkt auslässt, kann dieser verbleibende Endpunkt melden, dass andere Telemetriepfade blockiert werden. Unser Experte bezeichnete dies als „eindeutiges Sperrsignal“.

Nach dem Code aus der Produktionsumgebung umfasst die aktuelle Liste, die eine solche Sperrlogik vollständig abdecken müsste:

• li/track
• /platform-telemetry/li/apfcDf
• /apfc/collect
• /sensorCollect
• das Iframe li.protechts.net
• das Skript merchantpool1.linkedin.com

Je länger diese Liste wird, desto leichter kann LinkedIn vor der nächsten Veröffentlichung der Erweiterung einen neuen Endpunkt hinzufügen.

Manifest V3 bringt ein wichtiges Detail mit sich. Blockierende webRequest-Listener sind für öffentliche Erweiterungen nicht mehr verfügbar, deklaratives Blockieren über declarativeNetRequest funktioniert jedoch weiterhin.

Für Prüfer vereinfacht dies die Untersuchung, da die Sperrliste nun in einer statischen JSON-Datei im Erweiterungspaket steht.

2.8a LinkedIns externer Anti-Bot-Stack

LinkedIn verlässt sich nicht ausschließlich auf eigenen JavaScript-Code. Die Plattform lädt außerdem externe Anti-Bot- und Scoring-Systeme.

Die BrowserGate-Analyse identifizierte drei wichtige Bestandteile:

• HUMAN Security, früher PerimeterX: ein verborgenes 0×0-Iframe von li.protechts.net, das mit left: -9999px und aria-hidden positioniert ist und dessen URL uc=scraping enthält. Zugehörige Cookies sind unter anderem _px3 und _pxvid.
• Merchant Pool: ein zweites Fingerprinting-Skript von merchantpool1.linkedin.com, das mit dem Sitzungscookie des Nutzers verknüpft ist.
• Google reCAPTCHA v3 Enterprise: unsichtbares Scoring beim Laden der Seite.

Diese Systeme werden über interne Feature-Flags wie pemberly.tracking.* aktiviert. Dadurch kann LinkedIn Erkennungsmechanismen an Nutzersegmenten testen und die Abdeckung erhöhen, ohne den für Nutzer sichtbaren Produktablauf zu ändern.

Dies ist die Bestätigung auf Codeebene für die frühere Warnung des Experten: „Nichts hindert sie daran, dies jederzeit zu implementieren.“

2.9 IP, Geolokalisierung und parallele Sitzungen

Ein Cookie, das gleichzeitig unter zwei IP-Adressen aktiv ist (§1.2a), gehört zu den deutlichsten Signalen auf Netzwerkebene.

Die IP-Geolokalisierung ist zuverlässig genug, um Risikosignale zu erzeugen. Auf Ebene von Bundesstaaten oder vergleichbaren Verwaltungsregionen erreicht sie eine Genauigkeit von etwa 80 %, und in rund zwei Dritteln der Fälle wird die Stadt richtig erkannt. Wird ein Nutzer gleichzeitig in zwei verschiedenen Bundesstaaten oder Regionen verortet, kann dies ein vergleichsweise eindeutiges Anomaliesignal erzeugen.

Die Proxy-Steuerung von Cloud-Diensten löst dieses Problem normalerweise nicht vollständig. Viele Tools lassen Nutzer lediglich ein Land, aber keine Region, keinen Bundesstaat und keine Stadt auswählen. Paralleles Arbeiten – beispielsweise wenn der Nutzer lokal surft, während die Cloud dasselbe Konto aus einer anderen Region nutzt – erzeugt dieselbe Art von Signal.

Unser Registrierungsbericht in §1.2 zeigte das praktische Problem. Bei der von der Cloud zugewiesenen IP-Adresse handelte es sich meist um eine Rechenzentrumsadresse, die von einer unabhängigen Datenbank bereits als hochriskant eingestuft worden war. Bei fünf der sechs serverseitig arbeitenden Tools unter den sieben getesteten Diensten lagen die IPQS-Risikowerte bei mindestens 94.

Auch die Infrastruktur wurde gemeinsam genutzt. Dripify, Skylead und We Connect leiten ihren Datenverkehr alle über HostRoyale Technologies, ASN 203020, und Skylead gab beiden Testkonten dieselbe IP-Adresse im selben /24.

Eine „dedizierte IP in Ihrem Land“ kann daher sicherer klingen, als sie ist. In unserem Test maßen wir häufig eine markierte Rechenzentrums-IP in gemeinsam genutzter Infrastruktur, und keines der getesteten Tools prüfte die Reputation der IP-Adresse vor ihrer Zuweisung.

2.10 Zeitzone und Gebietsschema

Zeitzone und Gebietsschema sind kleinere Signale, liefern jedoch zusätzlichen Kontext. Unser Experte formulierte es so: „Eine falsche Zeitzone ist ein weiterer Punkt.“

Der Fingerabdruck erfasst die Zeitzone zweimal mit zwei verschiedenen Methoden. Eine unvollständige Fälschung kann sich daher selbst verraten, wenn die Werte nicht übereinstimmen. Auch die Systemsprachen werden erfasst.

Eine vermeintlich aus den USA stammende Sitzung auf einem Computer mit UTC+5 und einem abweichenden Gebietsschema ist genau die Art von Unstimmigkeit, die signals markieren soll.

2.11 Die Verhaltensebene: Auch manuelle Nutzer können sie auslösen

Die vorherigen Abschnitte konzentrieren sich auf die Erkennung von Tools. Diese Ebene betrifft das Verhalten. Deshalb können auch Nutzer, die LinkedIn manuell verwenden, Einschränkungen erfahren.

Die wichtigsten Verhaltensrisiken sind leicht verständlich:

• Volumen: Frühere Beobachtungen aus dem Supportaufkommen unseres Experten zeigten, dass etwa 500 Kontaktanfragen pro Tag innerhalb von ungefähr zwei Wochen zu einer Einschränkung führen konnten. Eine Kontaktanfrage alle 5 Sekunden konnte eine Abmeldung auslösen. Die aktuelle Obergrenze ist niedriger, da LinkedIn für die meisten Konten ein Limit von etwa 100 Kontaktanfragen innerhalb eines fortlaufenden Siebentagezeitraums verwendet. Bei älteren Profilen mit hohem Social Selling Index (SSI) sind bis zu etwa 200, mit Sales Navigator etwa 250 möglich.
• Wie Profile geöffnet werden: Das massenhafte Einfügen von Profil-URLs kann wie ein Scraper-Muster aussehen. Der Zugriff über die Namenssuche ähnelt eher einem normalen Nutzerablauf. Das massenhafte Öffnen von URLs ist ein dokumentierter Auslöser für Einschränkungen, selbst wenn eine Person es manuell durchführt.
• Reaktionen der Empfänger: Die Annahmerate ist wichtig, ebenso Meldungen der Art „Ich kenne diese Person nicht“. Selbst bei einer Annahmerate von 80 % bleiben bei 400 Kontaktanfragen pro Tag täglich 80 Personen, die entscheiden, ob sie die Anfrage ignorieren, ablehnen oder melden.
• Paralleler Zugriff aus verschiedenen Ländern: Dies knüpft an §2.9 an. Wenn Sie das Konto lokal nutzen, während ein Cloud-Dienst aus einem anderen Land in Ihrem Namen darauf zugreift, können zusätzliche Risikosignale auf Netzwerkebene entstehen.

Architektur und Verhalten bilden getrennte Ebenen. Auch eine sauberere Konfiguration kann Risiken schaffen, wenn sich das Konto unrealistisch verhält. Umgekehrt kann auch manuelle Arbeit Einschränkungen auslösen, wenn Volumen oder Muster automatisiert wirken.

3. Es ist ein Scoring-Modell: Wie LinkedIn seine Maßnahmen schrittweise verschärft

Keines der Erkennungssignale aus §2 sollte als einzelner Ein-/Aus-Schalter betrachtet werden. Die Einordnung des Experten entspricht unseren Befunden aus Code, Cloud-Tests und Verhaltensmustern: „Alles funktioniert wie ein Scoring-Modell; jedes Signal erhöht den Risikowert und damit die Wahrscheinlichkeit einer Sperre.“

LinkedIn benötigt daher kein einzelnes perfektes Signal. Die Plattform kann viele kleinere Signale aus Ihrem Browser, dem Verhalten der Erweiterung, der IP-Adresse, dem Sitzungsverlauf und den Mustern Ihrer Kontaktaufnahme vergleichen.

Nutzer, die bereits von solchen Maßnahmen betroffen waren, kennen typischerweise diese Eskalationsstufen:

1. Warnung: LinkedIn kann eine Nachricht anzeigen, laut der „Sie möglicherweise Automatisierungstools verwenden“.
2. Vorübergehende Einschränkung: Das Konto kann eingeschränkt werden, bis Sie eine Identitätsprüfung wie eine SMS-Verifizierung oder das Hochladen eines Ausweises abschließen.
3. Dauerhafte Sperre: Wenn LinkedIn statt eines Namens „LinkedIn-Mitglied“ anzeigt, bedeutet dies normalerweise, dass das Konto nicht mehr existiert.

Das Risiko entsteht über mehrere Ebenen hinweg. Eine installierte Erweiterung kann ein Signal hinzufügen (§2.1), Codespuren können weitere beitragen (§2.2–§2.8), Netzwerkanomalien können den Risikowert zusätzlich erhöhen (§2.9–§2.10) und das Kontoverhalten kann ihn weiter steigern (§2.11).

Eine risikoärmere Architektur schützt nicht vor übermäßig riskantem Nutzungsverhalten. Wenn Sie zu viele Kontaktanfragen senden, Profile massenhaft über URLs öffnen oder zu viele Meldungen der Art „Ich kenne diese Person nicht“ auslösen, kann bereits das Verhalten ein Einschränkungsrisiko erzeugen.

Der umgekehrte Fall ist für die Auswahl eines Tools noch wichtiger. Vorsichtiges Verhalten behebt keine riskante Architektur. 15 Kontaktanfragen pro Tag beseitigen nicht die technischen Signale, die entstehen, wenn Ihr Sitzungscookie aus einem Rechenzentrum in einem anderen Land wiedergegeben wird.

4. Checkliste für die fünfminütige Codeprüfung

Sie müssen kein Sicherheitsforscher sein, um eine erste Prüfung einer Chrome-Erweiterung durchzuführen. Sie können die Erweiterung mit einem Viewer für Chrome-Erweiterungspakete (CRX) entpacken oder sie installieren und die lokalen Erweiterungsdateien untersuchen.

Unter macOS werden installierte Chrome-Erweiterungen üblicherweise unter ~/Library/Application Support/Google/Chrome/Default/Extensions/ gespeichert. Sobald Sie über die Dateien verfügen, suchen Sie nach den folgenden Mustern.

Dies ist dieselbe Prüflogik, auf der die Codeaussagen dieses Berichts beruhen. Bewerten Sie eine Berechtigung nicht isoliert. Verfolgen Sie, was mit dem Wert geschieht und wohin er übertragen wird.

Wenn Sie ein Prüfurteil formulieren, binden Sie die Aussage eng an die Belege. Wenn der Code zeigt, dass ein Cookie an eine Anbieter-Domain gesendet wird, sagen Sie dies direkt. Wenn serverseitiges Verhalten von außen nicht beobachtet werden kann, kennzeichnen Sie es als „sehr wahrscheinlich“ und erläutern Sie den Risikopfad.

Eine nützliche Vorlage für die Formulierung von Urteilen, die wir vom Experten übernommen haben, lautet: „Die Erweiterung dient als Brücke, um Cookies zu übertragen, und hat keinen anderen Zweck“ oder für Cloud-Dienste: „Der Dienst arbeitet sehr wahrscheinlich über direkte API-Aufrufe; die Risiken sind A, B und C.“

Konkrete Vorwürfe nur mit einer belegbaren Codestelle formulieren; alles andere als „sehr wahrscheinlich“ kennzeichnen.

5. Die zentrale Risikotabelle

Diese Tabelle überführt die Befunde in verständliche Sprache. Sie zeigt das Problem, was dadurch gefährdet wird und wo wir es gefunden oder gemessen haben.

Bei serverseitigem Verhalten kennzeichnen wir die Aussage als „sehr wahrscheinlich“, da sich die interne Ausführung eines Cloud-Servers von außen nicht vollständig belegen lässt. Als Tatsache geben wir nur an, was wir im Code gefunden oder bei der Registrierung direkt gemessen haben.

6. So automatisieren Sie sicherer

Diese Vergleichswerte (benchmarks) sind nur sinnvoll, wenn die Architektur bereits sauber ist. Wenn Ihr Tool einen Sitzungsupload, gemeinsam genutzte Cloud-Infrastruktur oder unkontrollierte Proxy-Konfigurationen verwendet, beseitigen Tageslimits allein das oben beschriebene technische Risiko nicht.

Führen Sie diese Prüfungen durch, bevor Sie Aktivitäten auf LinkedIn automatisieren:

• Beschränken Sie Kontaktanfragen auf etwa 15–20 pro Tag. Dies entspricht dem LinkedIn-Limit von etwa 100 Kontaktanfragen innerhalb eines fortlaufenden Siebentagezeitraums. Die ältere Empfehlung von „50–70 pro Tag“ stammt aus der Zeit vor dem Wochenlimit.
• Ziehen Sie gesendete, noch ausstehende Kontaktanfragen etwa alle 3 Wochen zurück. Eine große Anzahl ignorierter Kontaktanfragen kann zu einem eigenen negativen Signal werden.
• Beobachten Sie Ihre Annahmerate. Wenn die Annahmerate sinkt, liegt das Problem in der Regel an der Zielgruppenauswahl oder daran, dass die Nachricht nicht zur Zielgruppe passt – und nicht nur am Tageslimit.
• Bauen Sie bei neuen oder länger inaktiven Profilen zunächst normale Aktivität auf. Nutzen Sie ein neueres oder inaktives Konto etwa einen Monat lang normal und manuell und hinterlegen Sie ein echtes Foto sowie einen echten Arbeitgeber, bevor Sie Vorgänge automatisieren.
• Öffnen Sie Profile über die Namenssuche und nicht durch massenhaftes Einfügen von URLs. Wie in §2.11 erläutert, kann das massenhafte Öffnen von URLs auch bei manuellen Nutzern zu Einschränkungen führen.
• Verwenden Sie eine IP-Adresse pro Konto mit übereinstimmender Geografie. Bleiben Sie nach Möglichkeit in derselben Stadt beziehungsweise Region oder demselben Bundesstaat und stimmen Sie Zeitzone sowie Gebietsschema auf den üblichen Standort des Kontos ab (§2.9–§2.10).
• Führen Sie keine parallelen Sitzungen aus. Vermeiden Sie es, das Konto lokal zu verwenden, während ein Tool es in der Cloud nutzt. Vermeiden Sie außerdem die gleichzeitige Aktivität über zwei Geräte, zwei Regionen oder lokal und in der Cloud.

Ein risikoärmerer Ansatz kombiniert eine sauberere Architektur, einen gleichbleibenden Ausgangspunkt der Sitzung, realistisches Tempo und ein Verhalten, das der normalen Nutzung eines LinkedIn-Kontos entspricht.

7. Warum Linked Helper eine Desktoparchitektur verwendet

Transparenzhinweis

Dieser Bericht wird von Linked Helper veröffentlicht. Daher möchten wir unsere eigene Position offen darlegen. Unsere Architektur geht auf Erkenntnisse zurück, die wir gewonnen haben, als die erste Version von Linked Helper noch eine Chrome-Erweiterung war.

Diese Erfahrung zeigte uns etwas Wichtiges: Jede Erweiterung hinterlässt technisch erkennbare Spuren, die bei eigenständiger Desktopsoftware entfallen. Wir entschieden uns dagegen, eine Erweiterung fortlaufend an diese Signale anzupassen.

Im Folgenden zeigen wir, wie diese Entscheidung mit den in diesem Bericht behandelten Risiken zusammenhängt.

Keine Erweiterungsspuren

Linked Helper ist keine Browsererweiterung. Es gibt keine Chrome-Web-Store-ID, kein in Chrome installiertes Erweiterungspaket und keine Erweiterungsressource, die LinkedIns AED-Scanner prüfen könnte (§2.1).

Auch wird kein Code in LinkedIn-Seiten injiziert. Erweiterungsoberflächen, Content-Skripte, Schaltflächen und injizierte Bedienfelder können für Spectroscopy und die Analyse von Seitenschnappschüssen sichtbar werden (§2.2–§2.3).

Linked Helper hält Kampagnensteuerungen, Warteschlangen und Dashboards innerhalb der Desktopanwendung. Die LinkedIn-Seite wird nicht durch Bedienfelder oder Erweiterungsskripte von Linked Helper verändert.

Keine Übergabe der Sitzung an die Cloud

Ihre LinkedIn-Sitzung verbleibt auf Ihrem Computer. Linked Helper lädt weder li_at, li_a, Cookie-Speicher, Browserspeicher noch Sitzungspakete in die Cloud eines Anbieters hoch.

Dadurch entfallen mehrere zuvor im Bericht behandelte Risikomuster:

• Kein entfernter Browser führt Aktionen in Ihrem Namen aus
• Ihre Sitzung wird nicht in einer Cloud-Kontofarm ausgeführt
• Ihrem Konto wird keine gemeinsam genutzte Exit-IP aus der Infrastruktur eines Anbieters zugewiesen
• Keine verborgene Cloud-Wiedergabe Ihrer LinkedIn-Sitzung ist erforderlich

Linked Helper führt die Automatisierung von Aktivitäten auf LinkedIn auch nicht über eine separate API-Wiedergabeebene aus. Viele Cloud-Produkte sind darauf angewiesen, den LinkedIn-API-Datenverkehr zu reproduzieren. Dadurch kann ein Anfragemuster entstehen, das von einer normalen Browsersitzung abweicht.

Linked Helper arbeitet stattdessen mit seiner eigenen lokalen Browser-Engine. Die Aktionen finden in einer Browserumgebung auf Ihrem Computer statt und verwenden Ihre authentifizierte LinkedIn-Sitzung und Ihre IP-Adresse oder den von Ihnen zugewiesenen Proxy.

Eigene Identität für jedes Konto

Linked Helper trennt die Browseridentität nach Konten. Wenn mehrere LinkedIn-Konten über ein Browserprofil betrieben werden, können Korrelationssignale entstehen. Deshalb verwendet jede Linked Helper-Instanz separate Cookies, Speicher und Caches.

Jede Instanz kann außerdem eigene Merkmale des Browserfingerabdrucks erzeugen. Dadurch sinkt die Wahrscheinlichkeit, dass mehrere Konten so aussehen, als stammten sie aus exakt derselben Gerätekonfiguration.

Hinzu kommt ein Schutz vor dem falschen Konto. Wenn Sie versuchen, sich innerhalb einer bestehenden Instanz bei einem anderen LinkedIn-Konto anzumelden, meldet Linked Helper das aktuelle Konto ab, statt die Sitzungen unbemerkt zu vermischen.

Auch für Teams oder Nutzer, die mehrere Konten verwalten, ist die Proxy-Steuerung wichtig. Mit Linked Helper können Sie jeder Instanz einen Proxy zuweisen und so die mit jedem Konto verbundene Netzwerkidentität kontrollieren.

Dies unterscheidet sich von vielen Cloud-Tools, bei denen der Anbieter die Exit-IP-Adresse für Sie auswählt. Linked Helper umfasst außerdem eine integrierte Prüfung der IP-Reputation auf Grundlage von IPQualityScore-(IPQS-)Daten, sodass Sie die Proxy-Qualität vor der Ausführung von Kampagnen bewerten können.

Auch die Steuerung des Nutzerverhaltens bleibt wichtig

Die Architektur reduziert nur einen Teil der technischen Risikosignale. LinkedIn kann auch das Kontoverhalten bewerten. Deshalb bleibt das Verhalten des Kontos wichtig.

Linked Helper bietet Steuerungsmöglichkeiten, mit denen Sie offensichtlich maschinell wirkende Verhaltensmuster vermeiden können:

• Navigation innerhalb der Seite: Linked Helper kann über LinkedIns eigene Oberfläche suchen und klicken, statt Profile direkt über URLs aufzurufen.
• Tägliche Aktionslimits: Konservative Standardeinstellungen helfen, unrealistische Aktivitätsspitzen zu reduzieren.
• Fortlaufende 24-Stunden-Limits: Limits werden über fortlaufende Zeitfenster und nicht nur nach Kalendertagen gemessen.
• Variierende Verzögerungen: Die Zeit zwischen Aktionen variiert, statt immer dasselbe Intervall zu wiederholen.
• Variierende tägliche Aktionszahlen und Zeitpläne: Die Kampagnenaktivität kann sich von Tag zu Tag ändern, statt identische Zahlen zu wiederholen.
• Nachrichtenvarianten: Sie können zwischen mehreren Nachrichtenversionen wechseln, damit die Kontaktaufnahme nicht wie eine einzige wiederholte Vorlage wirkt.

Diese Steuerungen machen Automatisierung nicht risikofrei. Sie helfen Ihnen dabei, die Aktivitäten im Konto stärker an ein normales Nutzungsverhalten auf LinkedIn anzunähern.

Der ehrliche Vorbehalt

Kein Anbieter kann vollständige Sicherheit versprechen, auch Linked Helper nicht. Die in diesem Bericht beschriebene Verhaltensebene bewertet Menschen und Automatisierung gleichermaßen.

Unpassende Ansprache, übermäßiges Volumen, niedrige Annahmeraten, ungewöhnliche Kontoaktivitäten und ungenaue Zielgruppenauswahl können unabhängig von der verwendeten Software Risiken erzeugen. Eine sauberere Architektur reduziert einige technische Signale, macht übermäßig riskantes Nutzungsverhalten jedoch nicht sicher.

Die nützliche Frage lautet nicht „sicher oder unsicher“. Entscheidend ist, wie viele erkennbare Signale eine Architektur erzeugt, bevor Ihr Verhalten überhaupt berücksichtigt wird.

Linked Helper wurde so konzipiert, dass die Sitzung lokal bleibt, Signale durch Erweiterungen und Cloud-Sitzungsübergaben vermieden, Kontoidentitäten isoliert und realistischere Aktivitätsrhythmen unterstützt werden und Sie die IP-Konfiguration selbst kontrollieren können.

Hinweis zur Methodik

Die statische Analyse wurde an öffentlich verteilten Erweiterungspaketen durchgeführt. Bei der Cloud-Registrierungsprüfung wurden sieben Tools mit jeweils zwei Konten getestet.

Versionen ändern sich, und Anbieter veröffentlichen Updates. Die Klassifizierungen in diesem Bericht spiegeln den von uns gelesenen Code und die uns während der Tests zugewiesenen IP-Adressen wider. Datei- und Zeilenangaben, Exit-IP-Adressen, IP-Reputation und der Scanlistenstatus zugehöriger Erweiterungen sind verfügbar, sofern sie gemessen wurden.

Das interne Verhalten eines Servers wird im gesamten Bericht als „sehr wahrscheinlich“ gekennzeichnet, da wir nicht jede serverseitige Ausführungsmethode von außen belegen können. Als Tatsache geben wir nur an, was wir im Code zeigen oder direkt messen können.

Dieser Leitfaden bietet die übergreifende Orientierung. Die detaillierte Analyse jeder Marke liefert weitere Belege, und das Dux-Soup-Beispiel in §1 zeigt, wie ein Produkt in verschiedenen Tarifen mehrere Architekturmuster kombinieren kann. Linked Helper ist weder mit LinkedIn verbunden noch von LinkedIn empfohlen oder ein offizieller Partner von LinkedIn.