Einleitung

Heute sprechen wir über eine Funktion, die zu einem integralen Bestandteil des Workflows jedes Anti-Detect-Browser-Nutzers geworden ist.

Paste Like Human Print (auch bekannt als human-like input oder abgekürzt HLI) ist eine Emulation der Texteingabe aus der Zwischenablage, die das Verhalten eines echten Nutzers nachahmt.

Es ist ein unverzichtbares Werkzeug, das viel Zeit spart und Routinehandlungen bei der Arbeit im Multi-Accounting-Bereich eliminiert. Sein Hauptziel ist es, das Risiko von Einschränkungen durch Anti-Fraud-Systeme beim Eingeben von Texten in Formularen auf Websites zu minimieren.

Jedes Produkt bezeichnet diese Funktion unterschiedlich:

• Human Typing Simulation
• Paste as human typing
• Human typing emulation
• Smart Paste

Linken Sphere war der erste Anti-Detect-Browser, der human-like input implementierte und Ende 2017 auf den Markt brachte. Damals zögerten die meisten Wettbewerber, eine ähnliche Funktion einzuführen, da sie behaupteten, dass sie bei der breiten Masse nicht stark nachgefragt sei. Die Praxis zeigte jedoch das Gegenteil: Innerhalb weniger Jahre wurde die Technologie in fast allen großen Produkten des Segments implementiert und wurde zum Branchenstandard.

Die Auswirkungen der Eingabemethode auf Ihren Erfolg

In der Praxis arbeiten wir oft mit vorab vorbereiteten Daten, zum Beispiel:

• Namen, Logins und E-Mail-Adressen bei der Registrierung von Konten
• Zahlungsdetails beim Erstellen von Werbekonten
• Einspruchstexte beim Entsperren von Werbekonten
• Kommentare und Nachrichten für SMM-Aktivitäten
• Und so weiter

Es ist kein Geheimnis, dass Anti-Fraud-Systeme seit langem das Nutzerverhalten verfolgen und analysieren. Die Texteingabe in Formularen bildet da keine Ausnahme. In der überwiegenden Mehrheit der Fälle spielt die Eingabemethode wirklich eine Rolle.

Wenn Sie einfach Text mit der bekannten Kombination Strg+V / Cmd+V einfügen, kann dies für das System verdächtig erscheinen im Vergleich zum manuellen Tippen. Infolgedessen könnten Ihr Konto und Ihre Aktionen einer verstärkten Überprüfung unterzogen werden.

Andererseits erscheint manuelles Tippen zwar am natürlichsten, ist jedoch bei der Arbeit mit großen Mengen von Konten nahezu unpraktisch. Erstens ist es einfach ermüdend. Zweitens kann Ihr einzigartiges Tippmuster verwendet werden, um Sitzungen miteinander zu verknüpfen. Ja, die Verknüpfung von Konten anhand des Tippstils ist keine Paranoia – es ist die Realität, in der wir leben. Später zeigen wir eine Methode, um solche Erkennungen visuell zu testen.

Daher bleibt die optimale Lösung Paste Like Human Print, das entwickelt wurde, um all die oben genannten Probleme zu beseitigen. Ist HLI eine Wunderwaffe? Das hängt ganz von der spezifischen technischen Implementierung ab. Deshalb haben wir unsere eigene Forschung zu den beliebtesten Anti-Detect-Browsern auf dem Markt durchgeführt.

Bevor wir uns den Ergebnissen zuwenden, lassen Sie uns die wichtigsten technischen Aspekte überprüfen, die helfen, besser zu verstehen, wie der Eingabemechanismus in Browsern funktioniert.

Welche Arten von Tastaturereignissen gibt es und wann werden sie verwendet?

Es gibt drei Haupt-Tastaturereignisse: keydown, keypress und keyup. In modernen Browsern (einschließlich Chrome) sind keydown und keyup relevant, während keypress als veraltet gilt (obwohl es beim Tippen noch ausgelöst wird).

• keydown – tritt auf, wenn eine Taste gedrückt wird, und wird für jede Taste ausgelöst (einschließlich Steuerungstasten wie Alt, Shift usw.). Es wird verwendet, um sofort auf Tastendrücke zu reagieren (z. B. für Tastenkombinationen oder Spiele). Wenn die Taste gedrückt gehalten wird (z. B. t), wird eine automatische Wiederholung ausgelöst: ein keydown beim ersten Drücken und wiederholte keydown-Ereignisse (mit event.repeat = true), bis die Taste losgelassen wird.
• keypress – (veraltet) wird ausgelöst, wenn eine Taste, die ein Zeichen erzeugt, gedrückt wird. Wurde historisch verwendet, um die Eingabe druckbarer Zeichen zu erkennen (Buchstaben, Ziffern usw.), während keydown/keyup physische Tastendrücke verfolgten. Es wird nicht für Tasten ausgelöst, die keine Zeichen erzeugen (wie Shift oder Pfeiltasten), und gilt jetzt als veraltet. Stattdessen sollte die Eigenschaft event.key mit keydown verwendet oder spezialisierte Eingabeereignisse genutzt werden (siehe unten).
• keyup – tritt auf, wenn eine Taste nach dem Drücken losgelassen wird. Es wird verwendet, um Aktionen zu behandeln, nachdem der Benutzer die Taste losgelassen hat – zum Beispiel, um eine Aktion auszuführen, sobald ein Zeichen eingegeben wurde, oder um zu erkennen, dass eine Taste nicht mehr gedrückt wird.

Veraltete Tastatureigenschaften: Was sind charCode, keyCode und which, und warum sollten sie vermieden werden?

charCode, keyCode und which sind Eigenschaften des Tastaturereignisobjekts aus älteren DOM-Versionen (Legacy). Sie stellten den Code der gedrückten Taste oder des Zeichens dar, sind jedoch jetzt veraltet und nicht mehr zur Verwendung empfohlen. Moderne Standards verwenden stattdessen die Eigenschaften event.key und event.code.

Hier ist eine kurze Beschreibung jeder veralteten Eigenschaft und warum sie abgeschafft wurde:

Eigentum\tBeschreibung (Legacy)\tStatus und Ersetzung \ event.keyCode\tNumerischer Tastencode (entspricht normalerweise dem ASCII-Code des Zeichens ohne Modifikatoren). Verwendet bei Tastendruck-/Tastendruckereignissen.\tAbgelehnt - veraltet. Variiert bei verschiedenen Browsern und Tastaturlayouts, insbesondere bei druckbaren Zeichen mit Shift/Alt. Sollte durch event.key oder event.code ersetzt werden. \ event.charCode\tNumerischer Unicode-Code des Zeichens, der nur bei Tastendruck erzeugt wird (für Tasten, die Text erzeugen).\tAbgelehnt - veraltet. Wurde verwendet, um das Zeichen während des Tastendrucks zu erhalten, jetzt ersetzt durch event.key, um das eingegebene Zeichen zu erhalten. \ event.which\tVereinheitlichte Eigenschaft, die je nach Ereignistyp den Tasten- oder Zeichencode zurückgibt: dupliziert im Wesentlichen keyCode für keydown/keyup und charCode für keypress. Wurde auch für Maustasten verwendet.\tAbgelehnt - veraltet. Nicht standardisiert (verschiedene Browser können unterschiedliche Werte zurückgeben). Für Tastatureingaben verwenden Sie stattdessen event.key und event.code (für die Maus - verwenden Sie event.button).

Modifikatoren (Shift, Ctrl, Alt, Meta): Wie funktionieren getModifierState() und die zugehörigen Eigenschaften?

Tastaturereignisse enthalten Eigenschaften, die den Zustand von Modifikatortasten anzeigen, sowie eine Methode, um sie zu überprüfen.

• Die Eigenschaften event.shiftKey, event.ctrlKey, event.altKey und event.metaKey sind true, wenn die entsprechende Modifikatortaste zum Zeitpunkt des Ereignisses gedrückt war. Zum Beispiel hat das keydown-Ereignis für die Taste "X" bei der Kombination Strg+X ctrlKey = true. Die Eigenschaft metaKey entspricht der Meta-Taste (unter Windows – ⊞ Windows-Taste, auf dem Mac – ⌘ Command). Diese booleschen Eigenschaften ermöglichen es, zu erkennen, ob Shift, Ctrl, Alt oder Meta zusammen mit einer anderen Taste gedrückt wurden.
• Die Methode event.getModifierState(key) gibt true oder false zurück, je nachdem, ob der angegebene Modifikator zum Zeitpunkt des Ereignisses aktiv ist. Der Parameter key ist ein String mit dem Namen der Modifikatortaste, wie "Shift", "Control", "Alt", "Meta" oder Sperrtasten wie "CapsLock" und "NumLock". Die Methode gibt true zurück, wenn der Modifikator derzeit gedrückt oder aktiviert ist (zum Beispiel, wenn CapsLock eingeschaltet ist). Dies ermöglicht die Überprüfung des Zustands von Tasten wie CapsLock, die nicht direkt in eigenständigen Ereigniseigenschaften reflektiert werden.

UI-Ereigniseigenschaften: Was bedeuten die Eigenschaften key, code, location, repeat, isComposing, inputType und data?

Das moderne KeyboardEvent-Objekt bietet eine Reihe von Eigenschaften mit Informationen über die gedrückte Taste. Zusätzlich werden während der Texteingabe InputEvent-Ereignisse generiert, die zusätzliche Eigenschaften bieten.

Hier sind die wichtigsten Attribute und ihre Bedeutungen:

Eigenschaft Wert (was sie repräsentiert) key Ein String, der den Tastenwert basierend auf dem Layout und dem Zustand der Modifikatoren darstellt. Für druckbare Zeichen ist es das tatsächliche Eingabezeichen (z. B. „a“ oder „A“ je nach Shift); für Sondertasten – ein vordefinierter Name wie „Enter“, „ArrowLeft“, „Backspace“ usw. code Ein String, der den physischen Ort der Taste auf der Tastatur beschreibt, unabhängig vom Layout. Z. B. „KeyA“ (Buchstabe A-Taste, auch wenn dort in einem anderen Layout ein anderes Zeichen liegt) oder „Digit1“ (Taste mit der Ziffer 1). location Numerischer Wert, der den Ort der Taste angibt: 0 – Standard, 1 – links, 2 – rechts, 3 – Numpad. Hilft zu unterscheiden, ob die Taste rechts oder links ist (z. B. Shift, Ctrl) oder vom Ziffernblock stammt. repeat Boolean – true, wenn das Ereignis durch das Gedrückthalten der Taste erzeugt wurde (automatische Wiederholung). isComposing Boolean – true, wenn das Zeichen im Rahmen einer Eingabekomposition (IME) eingegeben wird (z. B. bei Eingabe von Hieroglyphen). inputType Wird beim InputEvent verwendet. Gibt an, welche Aktion den Inhalt geändert hat: „insertText“, „deleteContentBackward“ usw. data Wird ebenfalls beim InputEvent verwendet. Enthält den eingegebenen Text – z. B. das Zeichen „a“, das der Benutzer eingegeben hat (nicht der Tastenname, sondern das tatsächliche Zeichen).

Wie funktionieren Tastaturereignisse in Eingabefeldern?

Wenn der Fokus sich in einem Eingabefeld befindet (z. B. input oder textarea), erzeugen Tastendrücke sowohl Tastaturereignisse als auch Texteingabeereignisse.

Die typische Abfolge sieht folgendermaßen aus:

• keydown – tritt auf, wenn eine beliebige Taste gedrückt wird. Das Ereignis wird auf dem fokussierten Element ausgelöst (also dem Eingabefeld selbst). Zu diesem Zeitpunkt hat der Browser das Zeichen noch nicht in das Feld eingefügt. Du kannst das Standardverhalten hier mit event.preventDefault() verhindern, um die Zeicheneingabe zu blockieren.
• beforeinput – danach (bei Tasten, die Zeichen erzeugen) sendet das Feld ein beforeinput-Ereignis, das die Absicht signalisiert, den Inhalt zu ändern. Unmittelbar danach wird das input-Ereignis ausgelöst, das anzeigt, dass der Inhalt aktualisiert wurde (z. B. wurde ein Buchstabe hinzugefügt). In diesen Ereignissen kannst du event.inputType und event.data auslesen, um zu erkennen, was genau passiert ist (Zeicheneingabe, Textlöschung, Einfügen über Zwischenablage usw.). Hinweis: In manchen älteren Fällen wurde statt beforeinput ein keypress-Ereignis ausgelöst, aber in modernen Chrome-Browsern wird beforeinput/input verwendet.
• keyup – schließlich, wenn die Taste losgelassen wird, tritt ein keyup-Ereignis auf demselben Element auf.

Die keydown/keyup-Tastaturereignisse steigen vom Eingabeelement durch den DOM-Baum auf (bis zu document und window), sodass sie sowohl am Eingabefeld selbst, an übergeordneten Elementen oder global abgefangen werden können. Wenn du speziell auf Texteingaben im Feld reagieren möchtest (einschließlich nicht-tastaturbasierter Eingaben wie Einfügen aus der Zwischenablage oder Spracheingabe), ist das input-Ereignis besser geeignet, da es bei jeder Änderung des Feldwerts ausgelöst wird. KeyboardEvent hingegen ist hilfreich für den Umgang mit direkter Tasteninteraktion – z. B. um Escape, Pfeiltasten, Funktionstasten oder Tastenkombinationen abzufangen. Für die Zeicheneingabe ist es nützlich, wenn du das eingegebene Zeichen vor der Anzeige im Feld verhindern oder ändern möchtest.

Wo kann man manuelle Eingabe und Einfügen wie ein Mensch testen?

Für ein vollständiges Bild wird das Testen in mehreren Phasen durchgeführt.

Keyboard_Event_Viewer[https://w3c.github.io/uievents/tools/key-event-viewer.html]

Dieser Prüfer liefert maximale Informationen zu Eingabeereignissen, einschließlich Legacy-Attributen, Modifikatoren und UI-Ereignissen.

1. Manueller Eingabetest

Verwenden Sie einen Anti-Detect-Browser, um Zeichen aus dem Testset einzeln manuell einzugeben. Vergleichen Sie dann die resultierenden Ereignisse mit denen der manuellen Eingabe in echtem Chrome auf demselben PC.

2. Test Einfügen wie ein Mensch

Verwenden Sie einen Anti-Detect-Browser, um dieselben Zeichen mit der Funktion Einfügen wie ein Mensch einzufügen. Vergleichen Sie die Ergebnisse mit der manuellen Eingabe in echtem Chrome auf demselben Gerät.

Erwartetes Verhalten: In beiden Fällen sollten die Eingabeereignisse den von echtem Chrome erzeugten Ereignissen während der manuellen Eingabe genau entsprechen.

TypingDNA[https://www.typingdna.com/demo-login.html]

Dieser Service konzentriert sich auf die Erkennung von Tippmustern, indem er die Intervalle zwischen den Tastenanschlägen analysiert, um einzigartige Schreibstile zu erkennen und Benutzer zu identifizieren.

1. Manueller Eingabetest

Verwenden Sie einen Anti-Detect-Browser, um ein Konto zu erstellen, indem Sie manuell eindeutige Daten eingeben (E-Mail, Passwort). Wiederholen Sie dann den Anmeldevorgang mehrmals mit denselben Daten – ebenfalls manuell.

2. Test Einfügen wie ein Mensch

Erstellen Sie ein Konto, indem Sie Daten mit der Funktion Einfügen wie ein Mensch einfügen. Melden Sie sich dann mehrmals an, wobei jedes Mal HLI zur Eingabe verwendet wird.

Verwenden Sie einen Anti-Detect-Browser, um ein Konto zu erstellen, indem Sie Daten mit der Funktion Einfügen wie ein Mensch einfügen. Melden Sie sich dann mehrere Male an, wobei jedes Mal HLI zur Eingabe verwendet wird.

Erwartetes Verhalten: Erfolgreiche Registrierung und Anmeldung, wobei der Zähler der Einschreibungen bei jeder wiederholten Anmeldung steigt. Ein Anstieg des Zählers zeigt eine Übereinstimmung des Tippmusters über die Sitzungen hinweg an.

Zusätzliche Details

• Testzeichen: tT@.
• Betriebssystem: Windows 11
• Einfügen wie ein Mensch wurde in allen Fällen über das Kontextmenü (Rechtsklick) ausgelöst, um Interferenzen mit Tastenkombinationen zu vermeiden.

Testergebnisse

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Verhalten von regulärem Chrome.

Beim Vergleichen von Einfügen wie ein Mensch mit echter manueller Eingabe in Chrome stimmen die Eingabeereignisse innerhalb des Testzeichensatzes vollständig überein. So sollte richtig implementiertes HLI funktionieren.

Ein detaillierter Vergleich des Verhaltens von HLI und regulärer Eingabe in Chrome ist im Screenshot zu sehen.

TypingDNA

Manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI ist die Registrierung und Anmeldung erfolgreich, und der Zähler der Einschreibungen steigt – was darauf hinweist, dass das System ein stabiles und wiederholbares Tippmuster innerhalb einer Sitzung erkennt.

Octo Browser v2.5.5

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Verhalten von Standard-Chrome.

HLI ist besser implementiert als in den meisten anderen Lösungen, aber nicht ohne Fehler.

Beim Vergleichen des HLI-Verhaltens mit echter manueller Eingabe in Chrome wurden folgende Besonderheiten festgestellt:

Beim Tippen von Großbuchstaben wie T und einigen Sonderzeichen wie @ wird die Shift-Taste verwendet, aber ihr Zustand wird nicht in den Modifikatoren (getModifierState, shift) widergespiegelt.

Ein detaillierter Vergleich des Verhaltens von HLI und regulärer Eingabe in Chrome ist im Screenshot zu sehen.

TypingDNA

Manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI steigt der Zähler der Einschreibungen entweder nicht oder es treten Fehler bei der Registrierung/anmeldung auf. Dies deutet darauf hin, dass jedes Mal ein neues Tippmuster gebildet wird, was von Antifraud-Systemen negativ wahrgenommen werden könnte.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Manuelle Eingabe: Bei Tasten wie Shift / Meta / Control (z. B. beim Tippen von Großbuchstaben T oder Zeichen wie @, die Shift erfordern) wird ein zusätzliches Tastenanschlagereignis mit Nullwerten für charCode / keyCode / which registriert.

Dies kann als Auslöser für Antifraud-Systeme dienen: Selbst bei manueller Dateneingabe weicht das Verhalten von Dolphin Anty vom Standard ab, was zu einer Erkennung des Anti-Detect-Browsers führen kann.

HLI in Dolphin Anty ist die schlechteste Implementierung auf dem Markt.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

Anstatt echtes Tippen zu emulieren, wird eine primitive Zeichen-für-Zeichen Einfügung verwendet. Der inputType-Wert ist in diesem Fall insertFromPaste, was sofort offenlegt, dass es sich um eine Zwischenablage-Einfügung handelt.

Sogar die Einfügung selbst, die über HLI durchgeführt wird, unterscheidet sich von einer Standard-Einfügung über das Kontextmenü (Rechtsklick), da keine beforeinput-Ereignisse vorhanden sind.

Ja, visuell mag es so erscheinen, als ob alles genauso funktioniert wie bei anderen Produkten. Eine detaillierte Analyse zeigt jedoch klare Unterschiede.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI erkennt die Seite überhaupt keine Eingabe, was zu erwarten ist: Es handelt sich um eine Einfügeoperation, keine echte Tipp-Emulation.

Undetectable v2.32.1

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Standardverhalten von Chrome.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

Bei den keydown- und keyup-Ereignissen sind die Legacy-Werte für keyCode und which immer 0, was inakzeptabel ist – ordnungsgemäße Eingabe erfordert gültige Schlüsselcodes.

Das code-Attribut von UI Events fehlt bei den keydown-, keyup- oder keypress-Ereignissen.

Beim Tippen von Großbuchstaben wie T und Sonderzeichen wie @ wird die Shift-Taste nicht ausgelöst – es fehlen die keydown-/keyup-Ereignisse, und somit werden keine entsprechenden Modifiers aktiviert.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI steigt der Enrollments-Zähler entweder nicht oder es treten Fehler bei der Registrierung/Anmeldung auf. Dies deutet darauf hin, dass jedes Mal ein neuer Tippmuster erzeugt wird, was von Anti-Betrugssystemen negativ wahrgenommen werden könnte.

Adspower v6.12.6.0

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Standardverhalten von Chrome.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

• Bei den keydown-, keyup- und keypress-Ereignissen sind die Legacy-Attribute charCode, keyCode und which immer 0 anstelle der erwarteten Werte.
• In den gleichen Ereignissen fehlen die UI Events-Attribute key und code.
• Modifiers (z. B. Shift und Meta) verhalten sich unnatürlich – das gleiche Aktivierungsmuster wird unabhängig vom Inhalt der Eingabe aufgezeichnet, obwohl sie in den meisten Fällen nicht ausgelöst werden sollten.
• Im Input UI Event ist das data-Attribut immer 'null'.
• Das beforeinput-Ereignis fehlt. Stattdessen wird das input-Ereignis zweimal ausgelöst, und nur das zweite enthält inputType = insertText.
• Die Ereignisreihenfolge ist gestört: Sie entspricht nicht der natürlichen Tippsequenz und bleibt unabhängig von der Eingabe falsch.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI wird keine Eingabe in das Formular eingegeben, und es erscheint eine Fehlermeldung: "Dieses Eingabefeld unterstützt keine Paste It".

0detect browser (ehemals AQUM) v3.7.40

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Standardverhalten von Chrome.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

• Bei den keydown- und keyup-Ereignissen sind die Legacy-Attribute charCode, keyCode und which immer 0 anstelle der erwarteten Werte.
• In den keydown-, keyup- und keypress-Ereignissen fehlen die UI Events-Attribute key und code.
• Beim Eingeben von Großbuchstaben wie T und Sonderzeichen wie @ wird die Shift-Taste nicht ausgelöst – es fehlen die keydown-/keyup-Ereignisse, und die Modifiers werden nicht aktiviert.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI wird in einigen Eingabefeldern keine Eingabe vorgenommen – es passiert überhaupt nichts. In anderen Feldern (wie der Google-Suchleiste) funktioniert die Eingabe jedoch korrekt.

GoLogin v3.3.83.79

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Standardverhalten von Chrome.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

• Bei den keydown- und keyup-Ereignissen sind die Legacy-Attribute charCode, keyCode und which immer 0 anstelle der richtigen Werte.
• In den keydown-, keyup- und keypress-Ereignissen fehlen die UI Events-Attribute key und code.
• Beim Tippen von Großbuchstaben wie T und Sonderzeichen wie @ wird die Shift-Taste nicht ausgelöst – es werden keine keydown-/keyup-Ereignisse generiert und Modifiers werden nicht aktiviert.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI steigt der Enrollments-Zähler entweder nicht oder es tritt ein Fehler während der Anmeldung/Registrierung auf. Dies deutet darauf hin, dass jedes Mal ein neuer Tippmuster erzeugt wird, was von Anti-Betrugssystemen negativ wahrgenommen werden könnte.

Vision v3.0.38

Keyboard Event Viewer

Das Verhalten während der manuellen Eingabe entspricht vollständig dem Standardverhalten von Chrome.

Die HLI-Implementierung ist im Wesentlichen identisch mit der Lösung von Dolphin Anty, mit ähnlichen Mängeln. In ihrem aktuellen Zustand ist sie eine der schlechtesten Implementierungen unter den getesteten Produkten.

Beim Vergleichen des HLI-Verhaltens mit der manuellen Eingabe in echtem Chrome wurden folgende Probleme festgestellt:

• Anstatt echte Tipp-Emulation zu verwenden, wird eine einfache Zeichen-für-Zeichen Einfügung vorgenommen. Der inputType-Wert in diesem Fall ist insertFromPaste, was deutlich auf das Einfügen aus der Zwischenablage hinweist.
• Sogar die Einfügung selbst, die über HLI erfolgt, unterscheidet sich von einer Standard-Einfügung über das Rechtsklick-Kontextmenü, da keine beforeinput-Ereignisse vorhanden sind.

Eine detaillierte Vergleichsanalyse des HLI- und Standard-Eingabeverhaltens in Chrome ist im Screenshot dargestellt.

TypingDNA

Die manuelle Eingabe funktioniert korrekt. Bei Verwendung von HLI erkennt die Seite überhaupt keine Eingabe – was zu erwarten ist, da es sich um eine Einfügeoperation und keine echte Tipp-Emulation handelt.

Bonus: Kontoverknüpfung durch individuellen Tippstil des Benutzers

Wir haben dies in der Einführung erwähnt, und jetzt zeigen wir es in der Praxis. Unten findest du einen einfachen Test, der beweist: Die Verknüpfung von Konten anhand des individuellen manuellen Tippverhaltens ist nicht nur möglich, sondern wird aktiv von Anti-Fraud-Systemen verwendet.

Und es funktioniert unabhängig von Sitzungen, Profilen oder sogar Geräten. Der Hauptidentifikator ist in diesem Fall – du selbst und dein einzigartiges Tippmuster.

Testverfahren

1. Erstelle die erste Sitzung/das erste Profil in deinem Anti-Detect-Browser

2. Gehe zur Testseite von TypingDNA[https://www.typingdna.com/demo-login.html]

3. Denke dir ein eindeutiges Login und Passwort aus und notiere sie dir (E-Mail-Bestätigung ist nicht erforderlich)

4. Registriere ein Konto, indem du die Daten manuell eingibst

5. Melde dich mehrmals mit denselben Zugangsdaten an (empfohlen 4–5 Mal), um den Enrollments-Zähler zu erhöhen und die Genauigkeit des Verhaltensmodells zu verbessern

6. Erstelle eine neue Sitzung/ein neues Profil (du kannst sogar ein anderes Gerät verwenden)

7. Gehe erneut zur Testseite von TypingDNA[https://www.typingdna.com/demo-login.html]

8. Melde dich erneut mit demselben Login und Passwort an – gib sie manuell ein, diesmal aber in einer neuen Sitzung oder auf einem neuen Gerät

Manual Input Test Results

As a result of logging in from a new device, the Enrollments counter increases. This indicates that the system successfully recognized your unique typing behavior and linked together two completely different sessions or devices.

This is one of the key threats that a well-implemented Paste Like Human Print is supposed to eliminate.

HLI-Testergebnisse in Linken Sphere

Bei der Verfeinerung der HLI-Funktion in Linken Sphere haben wir diesen Verhaltensfaktor berücksichtigt. Jede Sitzung in Linken Sphere erzeugt ihr eigenes einzigartiges Tippmuster.

Deshalb liefert ein ähnlicher Test mit HLI in Linken Sphere ein völlig anderes Ergebnis.

Erste Sitzung

Registrierung und Anmeldung sind erfolgreich, und der Zähler für Anmeldungen steigt.

Zweite (oder beliebige andere) Sitzung

Zwei Szenarien sind möglich:

• Entweder tritt ein Anmeldefehler auf (das neue Muster stimmt nicht mit dem vorherigen überein)
• Oder die Anmeldung ist erfolgreich, aber das System erhöht den Zähler für Anmeldungen nicht und fordert zur erneuten Eingabe der Zugangsdaten auf — um ein neues Muster zu erfassen.

Dies beweist, dass für jede LS-Sitzung ein einzigartiger Verhaltens-Fingerabdruck erzeugt wird, wie es bei einer korrekt implementierten Paste Like Human Print der Fall sein sollte. Dieser Ansatz verhindert effektiv das Verknüpfen von Konten über Sitzungen hinweg bei der Verwendung von HLI.

Sind Sie sicher, dass HLI in Ihrem Anti-Detect-Browser korrekt funktioniert? Oder ist es nur ein weiterer Risikofaktor, den Sie berücksichtigen sollten?

Testen Sie Ihren Anti-Detect-Browser selbst — und finden Sie heraus, ob er wirklich Schutz bietet oder tatsächlich zur Deanonymisierung beiträgt.

Fassen wir zusammen

Produkt (Version)\tEreignisse – manuell\tEreignisse – HLI\tTypingDNA – manuell\tTypingDNA – HLI Linken Sphere 2 v2.4.0\tAusgezeichnet\tAusgezeichnet\tAusgezeichnet\tAusgezeichnet Octo Browser v2.5.5\tAusgezeichnet\tGut\tAusgezeichnet\tSchlecht Dolphin Anty v2025.152.125.0\tSchlecht\tSchrecklich\tAusgezeichnet\tSchrecklich Undetectable v2.32.1\tAusgezeichnet\tSchlecht\tAusgezeichnet\tSchlecht Adspower v6.12.6.0\tAusgezeichnet\tSchrecklich\tAusgezeichnet\tSchrecklich Odeteсt browser (ex AQUM) v3.7.40\tAusgezeichnet\tSchlecht\tAusgezeichnet\tSchrecklich GoLogin v3.3.83.79\tAusgezeichnet\tSchlecht\tAusgezeichnet\tSchlecht Vision v3.0.38\tAusgezeichnet\tSchrecklich\tAusgezeichnet\tSchrecklich

Basierend auf den Ergebnissen des Vergleichstests ist klar, dass nicht jede Paste Like Human Print-Implementierung gleich zuverlässig oder sicher ist.

Linken Sphere ist der unangefochtene Spitzenreiter. Es ist das einzige Produkt, das sowohl bei manueller Eingabe als auch bei Verwendung von Paste Like Human Print korrektes Verhalten zeigte.

Sein Verhalten auf Ereignisebene entspricht vollständig dem realer manueller Eingaben in Chrome, und die Ergebnisse von TypingDNA bestätigen ein gut implementiertes System unabhängiger Eingabemuster pro Sitzung. HLI funktioniert nicht nur — es funktioniert richtig.

Neben der Einführung von Innovationen — von denen viele erstmals von uns in die Branche gebracht wurden — pflegen wir bestehende Funktionen aktiv und reagieren schnell auf neue Bedrohungen durch Anti-Fraud-Systeme.

Und vor allem — verlassen Sie sich nicht blind auf ein Produkt, nur weil es einmal funktioniert hat. Anti-Fraud-Systeme entwickeln sich ständig weiter, daher muss das Tool, das Sie für den Online-Zugang verwenden, nicht nur funktionieren — es muss einen Schritt voraus sein.