Introduction

Aujourd’hui, nous allons parler d’une fonctionnalité qui est devenue une partie intégrante du flux de travail de tout utilisateur de navigateur anti-détection.

Paste Like Human Print (également connu sous le nom de saisie humaine simulée, ou abrégé HLI) est une émulation de la saisie de texte à partir du presse-papiers, imitant le comportement d’un véritable utilisateur.

C’est un outil indispensable qui fait gagner énormément de temps et élimine les actions répétitives lorsqu’on travaille dans le domaine du multi-compte. Son objectif principal est de réduire au minimum le risque de restrictions imposées par les systèmes anti-fraude lors de la saisie de texte dans des formulaires sur des sites web.

Chaque produit nomme cette fonctionnalité différemment :

• Simulation de saisie humaine
• Coller comme une saisie humaine
• Émulation de saisie humaine
• Collage intelligent

Linken Sphere a été le premier navigateur anti-détection à implémenter la saisie humaine simulée et à la proposer sur le marché dès la fin de l’année 2017. À l’époque, la plupart des concurrents ne se précipitaient pas pour introduire une fonctionnalité similaire, affirmant qu’elle n’était pas très demandée par le grand public. Cependant, la pratique a montré le contraire : en quelques années, la technologie a été intégrée dans presque tous les produits majeurs du segment, devenant un standard de l’industrie.

L'impact de la méthode de saisie sur votre succès

En pratique, nous travaillons souvent avec des données préremplies, par exemple :

• Noms, identifiants et adresses email lors de l’enregistrement de comptes
• Détails de paiement lors de la création de comptes publicitaires
• Textes d’appel lors du déblocage de comptes publicitaires
• Commentaires et messages pour les activités SMM
• Et ainsi de suite

Ce n’est un secret pour personne que les systèmes anti-fraude analysent le comportement des utilisateurs depuis longtemps. La saisie de texte dans des formulaires n’y échappe pas. Dans la grande majorité des cas, la méthode de saisie a vraiment de l’importance.

Si vous collez simplement du texte à l’aide de la combinaison classique Ctrl+V / Cmd+V, cela peut paraître suspect au système par rapport à une saisie manuelle. En conséquence, votre compte et vos actions peuvent être surveillés de plus près.

D’un autre côté, la saisie manuelle, bien que paraissant la plus naturelle, est presque impraticable lorsqu’on gère un grand volume de comptes. D’abord, c’est tout simplement épuisant. Ensuite, votre style de frappe unique peut être utilisé pour relier des sessions entre elles. Oui, associer des comptes par style de frappe n’est pas de la paranoïa — c’est la réalité. Un peu plus tard, nous vous montrerons une méthode pour tester visuellement ce type de détection.

Par conséquent, la solution optimale reste Paste Like Human Print, conçue pour éliminer tous les problèmes mentionnés ci-dessus. Le HLI est-il une solution miracle ? Tout dépend de l’implémentation technique spécifique. C’est pourquoi nous avons mené notre propre étude sur les navigateurs anti-détection les plus populaires du marché.

Avant d’entrer dans les résultats, examinons les aspects techniques clés qui permettent de mieux comprendre le fonctionnement du mécanisme de saisie dans les navigateurs.

Quels types d'événements clavier existent et quand sont-ils utilisés ?

Il existe trois principaux événements clavier : keydown, keypress et keyup. Dans les navigateurs modernes (y compris Chrome), keydown et keyup sont utilisés, tandis que keypress est considéré comme obsolète (bien qu’il se déclenche encore lors de la frappe).

• keydown – se produit lorsqu’une touche est enfoncée et se déclenche pour n’importe quelle touche (y compris les touches de contrôle comme Alt, Shift, etc.). Il est utilisé pour répondre immédiatement à une pression de touche (ex : raccourcis ou jeux). Si la touche est maintenue enfoncée (ex : t), cela déclenche un auto-repeat : un keydown initial suivi de keydown répétés (avec event.repeat = true) jusqu’à ce que la touche soit relâchée.
• keypress – (obsolète) se déclenche lorsqu’une touche produisant un caractère est enfoncée. Utilisé historiquement pour détecter l’entrée de caractères imprimables (lettres, chiffres, etc.), tandis que keydown/keyup suivaient les pressions physiques. Ne se déclenche pas pour les touches ne produisant pas de caractères (comme Shift ou les flèches). Désormais obsolète. Utilisez plutôt event.key avec keydown ou des événements d’entrée spécialisés (voir ci-dessous).
• keyup – se produit lorsqu’une touche est relâchée après avoir été enfoncée. Utilisé pour gérer les actions après que l’utilisateur a relâché la touche — par exemple, pour exécuter une action après qu’un caractère a été saisi ou pour détecter qu’une touche n’est plus enfoncée.

Attributs clavier obsolètes : que sont charCode, keyCode et which, et pourquoi faut-il les éviter ?

charCode, keyCode et which sont des propriétés de l’objet d’événement clavier issues d’anciennes versions du DOM (héritées). Elles représentaient le code de la touche ou du caractère pressé, mais sont maintenant obsolètes et déconseillées. Les standards modernes utilisent les propriétés event.key et event.code à la place.

Voici une brève description de chaque propriété héritée et les raisons de leur abandon :

Propriété Description (héritée) Statut et remplacement event.keyCode Code numérique de la touche (souvent équivalent au code ASCII du caractère sans modificateurs). Utilisé dans les événements keydown / keyup. Obsolète – dépassé. Varie selon les navigateurs et les dispositions clavier, surtout pour les caractères imprimables avec Shift/Alt. À remplacer par event.key ou event.code. event.charCode Code Unicode numérique du caractère, généré uniquement lors de l’événement keypress (pour les touches produisant du texte). Obsolète – dépassé. Était utilisé pour obtenir le caractère lors de keypress, désormais remplacé par event.key pour récupérer le caractère saisi. event.which Propriété unifiée renvoyant le code de la touche ou du caractère selon le type d’événement : dupliquait essentiellement keyCode pour keydown/keyup et charCode pour keypress. Était aussi utilisée pour les boutons de souris. Obsolète – dépassé. Non standardisée (différents navigateurs pouvaient renvoyer différentes valeurs). Pour la saisie clavier, utilisez event.key et event.code à la place (pour la souris – utilisez event.button).

Modificateurs (Shift, Ctrl, Alt, Meta) : Comment fonctionnent getModifierState() et les propriétés associées ?

Les événements clavier incluent des propriétés indiquant l'état des touches de modification, ainsi qu'une méthode pour les vérifier.

• Les propriétés event.shiftKey, event.ctrlKey, event.altKey et event.metaKey valent true si la touche de modification correspondante était enfoncée au moment de l'événement. Par exemple, avec la combinaison Ctrl+X, l'événement keydown pour la touche "X" aura ctrlKey = true. La propriété metaKey correspond à la touche Meta (sous Windows – touche Windows ⊞, sur Mac – touche Commande ⌘). Ces propriétés booléennes permettent de détecter si Shift, Ctrl, Alt ou Meta étaient maintenus enfoncés avec une autre touche.
• La méthode event.getModifierState(key) retourne true ou false selon que le modificateur spécifié est actif au moment de l'événement. Le paramètre key est une chaîne de caractères indiquant le nom de la touche de modification, comme "Shift", "Control", "Alt", "Meta", ou des touches de verrouillage comme "CapsLock" et "NumLock". La méthode retourne true si le modificateur est actuellement enfoncé ou activé (par exemple si CapsLock est activé). Cela permet de vérifier l'état des touches comme CapsLock, qui ne sont pas directement reflétées par les propriétés de l'événement.

Attributs des événements d'interface utilisateur : Que signifient les propriétés key, code, location, repeat, isComposing, inputType et data ?

L'objet moderne KeyboardEvent fournit une série de propriétés avec des informations sur la touche pressée. De plus, des événements InputEvent sont générés lors de la saisie de texte, offrant des propriétés supplémentaires.

Voici les principaux attributs et leurs significations :

Propriété\tValeur (ce qu'elle représente) key\tUne chaîne représentant la valeur de la touche selon la disposition du clavier et les modificateurs. Pour les caractères imprimables, c'est le caractère réel saisi (ex. : \"a\" ou \"A\" selon Shift) ; pour les touches spéciales – un nom prédéfini (ex. : \"Enter\", \"Escape\"). code\tUne chaîne indiquant le code physique de la touche sur le clavier. Elle ne dépend pas de la disposition actuelle ; elle reflète la position spécifique de la touche (ex. : appuyer sur \"Q\" donne toujours \"KeyQ\", quelle que soit la disposition). location\tUn nombre indiquant l'emplacement de la touche sur le clavier. Valeurs : 0 (Standard), 1 (Gauche), 2 (Droite), 3 (Pavé numérique). repeat\tBooléen : true si l'événement est déclenché de façon répétée pendant que la touche est maintenue enfoncée (répétition de touche). Pour keydown initial, false ; pour les événements suivants répétés, true. Pour keyup, toujours false. isComposing\tBooléen : true si l'événement se produit pendant une session de composition (IME), par exemple entre compositionstart et compositionend. inputType\t(propriété InputEvent) Une chaîne indiquant le type de modification effectuée sur le champ ou le contenu éditable. Exemples : \"insertText\", \"deleteContentBackward\", \"insertFromPaste\", etc. data\t(propriété InputEvent) Une chaîne avec les données textuelles insérées suite à l'événement d'entrée. Peut être vide si des caractères ont été supprimés ou null si non directement lié à une donnée textuelle.

Comment les événements clavier interagissent-ils avec les champs de saisie ?

Lorsque le focus est dans un champ de saisie (comme input ou textarea), les pressions de touches génèrent à la fois des événements clavier et des événements d'entrée de texte.

La séquence typique est la suivante :

• keydown – se produit lorsque n'importe quelle touche est enfoncée. L'événement est déclenché sur l'élément ayant le focus (le champ de saisie). À ce stade, le navigateur n’a pas encore inséré le caractère dans le champ. Vous pouvez annuler le comportement par défaut avec event.preventDefault() pour bloquer la saisie du caractère.
• beforeinput – ensuite (pour les touches produisant des caractères), le champ émet un événement beforeinput, signalant l’intention de modifier le contenu. Immédiatement après, l’événement input est déclenché, indiquant que le contenu a été mis à jour (ex. : une lettre a été ajoutée). Vous pouvez consulter event.inputType et event.data dans ces événements pour savoir ce qui s’est passé (saisie de caractère, suppression de texte, collage, etc.). Remarque : dans certains cas anciens, un événement keypress pouvait être émis à la place de beforeinput, mais dans les navigateurs Chrome modernes, beforeinput/input est utilisé.
• keyup – enfin, lorsque la touche est relâchée, un événement keyup se produit sur le même élément.

Les événements clavier keydown/keyup se propagent depuis l’élément input à travers l’arborescence DOM (jusqu’au document, puis à la fenêtre), ils peuvent donc être interceptés sur l’élément lui-même, ses parents ou globalement. Si vous souhaitez répondre spécifiquement à la saisie de texte dans le champ (y compris les saisies non issues du clavier comme le collage ou la saisie vocale), il vaut mieux utiliser l’événement input, qui se déclenche à chaque modification de la valeur du champ. KeyboardEvent est quant à lui utile pour gérer des interactions directes avec les touches — par exemple, intercepter Échap, les flèches, les touches de fonction, les combinaisons, etc. Pour la saisie de caractères, il est préférable de l’utiliser lorsque vous avez besoin d’empêcher ou de modifier le caractère tapé avant qu’il n’apparaisse dans le champ.

Où tester la saisie manuelle et le collage comme une frappe humaine ?

Pour une vue complète, les tests sont effectués en plusieurs étapes.

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

Ce vérificateur fournit un maximum d'informations sur les événements de saisie, y compris les attributs hérités, les modificateurs et les événements UI.

1. Test de saisie manuelle

En utilisant un navigateur anti-détection, saisissez manuellement les caractères de l’ensemble de test un par un. Comparez ensuite les événements obtenus avec ceux d’une saisie manuelle dans Chrome réel sur le même PC.

2. Test de collage comme une frappe humaine

En utilisant un navigateur anti-détection, collez les mêmes caractères à l’aide de la fonction « Coller comme une frappe humaine ». Comparez les résultats avec ceux d'une saisie manuelle dans Chrome réel sur le même appareil.

Comportement attendu : dans les deux cas, les événements de saisie doivent correspondre étroitement à ceux générés par Chrome réel lors d'une frappe manuelle.

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

Ce service se concentre sur la reconnaissance des schémas de frappe en analysant les intervalles entre les frappes pour détecter les styles uniques et identifier les utilisateurs.

1. Test de saisie manuelle

En utilisant un navigateur anti-détection, créez un compte en saisissant manuellement des données uniques (email, mot de passe). Répétez ensuite le processus de connexion plusieurs fois avec les mêmes données — également de manière manuelle.

2. Test de collage comme une frappe humaine

Créez un compte en collant les données via « Coller comme une frappe humaine ». Ensuite, connectez-vous plusieurs fois, en utilisant à chaque fois HLI pour la saisie.

En utilisant un navigateur anti-détection, créez un compte en collant les données via HLI. Ensuite, connectez-vous plusieurs fois, en utilisant à chaque fois HLI pour la saisie.

Comportement attendu : inscription et connexion réussies, avec un compteur d’enregistrements (Enrollments) qui augmente à chaque nouvelle connexion. Cela indique une correspondance du schéma de frappe entre les sessions.

Détails supplémentaires

• Ensemble de caractères testés : tT@.
• Système d’exploitation : Windows 11
• « Coller comme une frappe humaine » a été déclenché via le menu contextuel (clic droit) dans tous les cas pour éviter les interférences des raccourcis clavier

Résultats des tests

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

Le comportement lors de la saisie manuelle correspond parfaitement à celui de Chrome classique.

Lors de la comparaison entre HLI et la saisie manuelle réelle dans Chrome, les événements de saisie correspondent complètement pour l’ensemble de test. C’est exactement ainsi que HLI doit fonctionner correctement.

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est présentée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Avec HLI, l’inscription et la connexion réussissent, et le compteur d’enregistrements augmente — indiquant que le système détecte un schéma de frappe stable et répétable dans une même session.

Octo Browser v2.5.5

Keyboard Event Viewer

Le comportement lors de la saisie manuelle correspond parfaitement à Chrome standard.

HLI est mieux implémenté que dans la plupart des autres solutions, mais présente encore des défauts.

En comparant le comportement de HLI à la saisie manuelle réelle dans Chrome, les particularités suivantes ont été observées :

Lors de la saisie de caractères majuscules comme T et de caractères spéciaux comme @, la touche Shift est utilisée, mais son état n’est pas reflété dans les modificateurs (getModifierState, shift)

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est présentée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Avec HLI, le compteur d’enregistrements n’augmente pas ou des erreurs d’inscription/connexion surviennent. Cela indique qu’un nouveau schéma de frappe est formé à chaque fois, ce qui peut être mal perçu par les systèmes anti-fraude.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Saisie manuelle : lors de l’appui sur des touches comme Shift / Meta / Control (ex. lors de la saisie de T majuscule ou de @ nécessitant Shift), un événement de frappe supplémentaire est enregistré avec des valeurs nulles pour charCode / keyCode / which.

Cela peut servir de déclencheur pour les systèmes anti-fraude : même lors de la saisie manuelle, le comportement de Dolphin Anty dévie de la norme, ce qui peut conduire à la détection du navigateur anti-détection.

HLI dans Dolphin Anty est la pire implémentation sur le marché.

En comparant le comportement de HLI à la saisie manuelle réelle dans Chrome, les problèmes suivants ont été identifiés :

Au lieu d’émuler une saisie réelle, il utilise un collage caractère par caractère primitif. La valeur inputType est alors insertFromPaste, ce qui révèle immédiatement qu’il s’agit d’un collage depuis le presse-papiers

Même le collage effectué via HLI diffère d’un collage standard via le menu contextuel (clic droit), car aucun événement beforeinput n’est généré

Oui, visuellement, cela peut sembler fonctionner comme dans d'autres produits. Cependant, une analyse détaillée révèle des différences nettes.

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est présentée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l'utilisation de HLI, le site ne détecte aucune saisie, ce qui est attendu : il s'agit d'une opération de collage, et non d'une véritable émulation de frappe.

Undetectable v2.32.1

Visualiseur d'événements clavier

Le comportement lors de la saisie manuelle correspond totalement à celui de Chrome standard.

En comparant le comportement de HLI avec une saisie manuelle dans Chrome réel, les problèmes suivants ont été identifiés :

Dans les événements keydown et keyup, les valeurs Legacy pour keyCode et which sont toujours à 0, ce qui est inacceptable — une saisie correcte nécessite des codes de touche valides

L'attribut code des UI Events est absent des événements keydown, keyup et keypress

Lors de la saisie de caractères majuscules comme T et de caractères spéciaux comme @, la touche Shift ne se déclenche pas — aucun événement keydown / keyup n'est généré, donc aucun modificateur n’est activé

Une comparaison détaillée du comportement de HLI et de la saisie normale dans Chrome est illustrée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l'utilisation de HLI, le compteur d’enregistrements n’augmente pas ou bien des erreurs de connexion/enregistrement se produisent. Cela suggère qu’un nouveau modèle de frappe est généré à chaque fois, ce qui peut être perçu négativement par les systèmes anti-fraude.

Adspower v6.12.6.0

Visualiseur d'événements clavier

Le comportement lors de la saisie manuelle correspond totalement à celui de Chrome standard.

En comparant le comportement de HLI avec une saisie manuelle dans Chrome réel, les problèmes suivants ont été identifiés :

• Dans les événements keydown, keyup et keypress, les attributs Legacy charCode, keyCode et which sont toujours à 0 au lieu des valeurs attendues
• Dans les mêmes événements, les attributs key et code des UI Events sont absents
• Les modificateurs (par exemple, Shift et Meta) se comportent de façon non naturelle — le même schéma d'activation est enregistré indépendamment du contenu saisi, même s'ils ne devraient pas être déclenchés dans la plupart des cas
• Dans l'événement UI input, l'attribut data est toujours 'null'
• L’événement beforeinput est absent. À la place, l’événement input est déclenché deux fois, et seul le second contient inputType = insertText
• L'ordre des événements est cassé : il ne correspond pas à la séquence naturelle de frappe et reste incorrect, peu importe la saisie

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est illustrée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l’utilisation de HLI, les données ne sont pas saisies dans le formulaire, et une erreur s’affiche : « Ce champ de saisie ne prend pas en charge Paste It ».

0detect browser (anciennement AQUM) v3.7.40

Visualiseur d'événements clavier

Le comportement lors de la saisie manuelle correspond totalement à celui de Chrome standard.

En comparant le comportement de HLI avec une saisie manuelle dans Chrome réel, les problèmes suivants ont été identifiés :

• Dans les événements keydown et keyup, les attributs Legacy charCode, keyCode et which sont toujours à 0 au lieu des valeurs attendues
• Dans les événements keydown, keyup et keypress, les attributs key et code des UI Events sont absents
• Lors de la saisie de caractères majuscules comme T et de caractères spéciaux comme @, la touche Shift ne se déclenche pas — les événements keydown / keyup sont absents, et les modificateurs ne sont pas activés

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est illustrée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l’utilisation de HLI, les données ne sont pas saisies dans certains champs — rien ne se passe. Cependant, dans d'autres champs (comme la barre de recherche Google), la saisie fonctionne correctement.

GoLogin v3.3.83.79

Visualiseur d'événements clavier

Le comportement lors de la saisie manuelle correspond totalement à celui de Chrome standard.

En comparant le comportement de HLI avec une saisie manuelle dans Chrome réel, les problèmes suivants ont été identifiés :

• Dans les événements keydown et keyup, les attributs Legacy charCode, keyCode et which sont toujours à 0 au lieu des valeurs correctes
• Dans les événements keydown, keyup et keypress, les attributs key et code des UI Events sont absents
• Lors de la saisie de caractères majuscules comme T et de caractères spéciaux comme @, la touche Shift ne se déclenche pas — aucun événement keydown / keyup n’est généré, et les modificateurs ne sont pas activés

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est illustrée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l'utilisation de HLI, le compteur d’enregistrements n’augmente pas ou une erreur survient pendant la connexion/l'inscription. Cela indique qu’un nouveau modèle de frappe est généré à chaque fois, ce qui peut être mal perçu par les systèmes anti-fraude.

Vision v3.0.38

Visualiseur d'événements clavier

Le comportement lors de la saisie manuelle correspond totalement à celui de Chrome standard.

L’implémentation de HLI est pratiquement identique à celle de Dolphin Anty, avec des défauts similaires. En l'état actuel, c'est l'une des pires implémentations parmi les produits testés.

En comparant le comportement de HLI avec une saisie manuelle dans Chrome réel, les problèmes suivants ont été identifiés :

• Au lieu d’une véritable émulation de frappe, un simple collage caractère par caractère est utilisé. La valeur inputType est alors insertFromPaste, ce qui indique clairement un collage depuis le presse-papiers
• Même le collage effectué via HLI diffère d’un collage standard via clic droit, car les événements beforeinput sont absents

Une comparaison détaillée du comportement de HLI et de la saisie standard dans Chrome est illustrée dans la capture d'écran.

TypingDNA

La saisie manuelle fonctionne correctement. Lors de l’utilisation de HLI, le site ne détecte aucune saisie — ce qui est attendu, puisqu’il s’agit d’un collage et non d’une véritable émulation de frappe.

Bonus : Lier des comptes par le style de frappe unique de l’utilisateur

Nous l’avons mentionné dans l’introduction, et nous allons maintenant le démontrer en pratique. Voici un test simple qui prouve que le lien entre des comptes basé sur le comportement de frappe manuel unique est non seulement possible, mais effectivement utilisé par les systèmes anti-fraude.

Et cela fonctionne indépendamment des sessions, des profils, voire des appareils. L’identifiant principal, dans ce cas, c’est vous — et votre style de frappe unique.

Procédure de test

1. Créez une première session ou un profil dans votre navigateur antidetect

2. Rendez-vous sur la page de test TypingDNA[https://www.typingdna.com/demo-login.html]

3. Choisissez un identifiant et un mot de passe uniques, notez-les (aucune confirmation par e-mail requise)

4. Enregistrez un compte en saisissant les données manuellement

5. Connectez-vous plusieurs fois avec les mêmes identifiants (4–5 fois recommandées) pour augmenter le compteur Enrollments et améliorer la précision du modèle comportemental

6. Créez une nouvelle session ou un nouveau profil (vous pouvez même utiliser un autre appareil)

7. Rendez-vous à nouveau sur la page de test TypingDNA[https://www.typingdna.com/demo-login.html]

8. Connectez-vous à nouveau avec les mêmes identifiants — saisissez-les manuellement, mais cette fois dans une nouvelle session ou sur un nouvel appareil

Résultats du test de saisie manuelle

Après vous être connecté depuis un nouvel appareil, le compteur Enrollments augmente. Cela indique que le système a reconnu votre style de frappe unique et a lié deux sessions ou appareils complètement différents.

C’est l’une des principales menaces que l’émulation de frappe humaine bien implémentée est censée éliminer.

Résultats du test HLI dans Linken Sphere

Lors de l’affinement de la fonctionnalité HLI dans Linken Sphere, nous avons pris en compte ce facteur comportemental. Chaque session dans Linken Sphere génère son propre motif de frappe unique.

C’est pourquoi un test similaire utilisant HLI dans Linken Sphere produit un résultat complètement différent.

Première session

L’enregistrement et la connexion réussissent, et le compteur Enrollments augmente.

Deuxième (ou toute autre) session

Deux scénarios sont possibles :

• Soit une erreur de connexion se produit (le nouveau motif ne correspond pas à l’ancien)
• Soit la connexion réussit, mais le système n’augmente pas le compteur Enrollments et demande de ressaisir les identifiants — pour capturer un nouveau motif.

Cela prouve qu’un identifiant comportemental unique est généré pour chaque session de LS, comme cela devrait être dans une implémentation correcte de Paste Like Human Print. Cette approche empêche efficacement la liaison de comptes entre sessions lors de l’utilisation de HLI sur différentes sessions.

Êtes-vous sûr que HLI dans votre navigateur anti-detect fonctionne correctement ? Ou est-ce juste un autre facteur de risque que vous devez prendre en compte ?

Testez votre propre navigateur anti-detect — et découvrez s’il fournit réellement une protection ou s’il contribue à la dé-anonymisation.

Résumons

Produit (version) Événements – manuel Événements – HLI TypingDNA – manuel TypingDNA – HLI Linken Sphere 2 v2.4.0 Excellent Excellent Excellent Excellent Octo Browser v2.5.5 Excellent Bon Excellent Mauvais Dolphin Anty v2025.152.125.0 Mauvais Terrible Excellent Terrible Undetectable v2.32.1 Excellent Mauvais Excellent Mauvais Adspower v6.12.6.0 Excellent Terrible Excellent Terrible Odeteсt browser (ex AQUM) v3.7.40 Excellent Mauvais Excellent Terrible GoLogin v3.3.83.79 Excellent Mauvais Excellent Mauvais Vision v3.0.38 Excellent Terrible Excellent Terrible

Sur la base des résultats des tests comparatifs, il est clair que toutes les implémentations de Paste Like Human Print ne sont pas également fiables ou sûres.

Linken Sphere est le leader incontesté. C’est le seul produit qui a montré un comportement correct tant lors de la saisie manuelle que lors de l’utilisation de Paste Like Human Print.

Son comportement au niveau des événements correspond parfaitement à celui de la saisie manuelle réelle dans Chrome, et les résultats TypingDNA confirment un système bien implémenté de motifs de saisie indépendants par session. HLI ne fait pas simplement « fonctionner » — il fonctionne de la bonne manière.

En plus d’introduire des innovations — dont beaucoup que nous sommes les premiers à apporter à l’industrie — nous maintenons activement les fonctionnalités existantes et répondons rapidement aux menaces émergentes des systèmes anti-fraude.

Et surtout — ne vous fiez pas aveuglément à un produit simplement parce qu’il a fonctionné une fois. L’anti-fraude évolue constamment, donc l’outil que vous utilisez pour aller en ligne ne doit pas seulement fonctionner — il doit rester une étape en avance.