Quels navigateurs obtiennent des résultats, ce que change la session, ce que les scripts de Google inspectent dans le navigateur, et pourquoi une page de résultats reçue n’est pas forcément un relevé fiable.
Depuis l’été 2026, Google a modifié le contrôle qui tourne en tâche de fond sur ses pages de résultats. Entre le 20 et le 22 août, il y a ajouté quatre familles de tests : réglages déclarés par le navigateur, rendu du texte, précision du pointeur et carte graphique via WebGPU. Le test WebGPU a disparu le 5 octobre. Depuis juillet, une partie des requêtes reçoit en plus un module qui conserve un historique d’interactions dans le navigateur et le relit au passage suivant. Fin août, Google a aussi généralisé les liens de redirection /goto dans ses résultats.
Les essais de navigateurs depuis un VPS, sur IP native et sorties VPN, et l’analyse du code servi par Google décrivent jusqu’à quatre machines virtuelles (VM) sur une même page de résultats, trois parcours de contrôle distincts. Dans la comparaison contrôlée du même Chrome, le refus suit la valeur native de navigator.webdriver, indépendamment du réglage de lancement qui l’active habituellement. Le signal d’automatisation et l’état de la session influencent les parcours observés ; l’IP seule n’explique pas les écarts. Et une page de résultats obtenue ne garantit pas un relevé fiable.
L’expérience interactive SearchGuard — Episode IIPartie I · Les retours terrain
Partie I
Quelles configurations obtiennent des résultats ? Quel rôle joue la session ? Peut-on se fier au classement reçu ?
Les pages de résultats de Google sont plus qu’un service : elles reflètent ce que le monde cherche, minute après minute. Toute une industrie y mesure sa visibilité. Les protections décrites dans cette page décident qui a le droit de regarder.
Chaque rapport de positions, chaque indicateur de visibilité, chaque outil qui dit à une entreprise où elle en est repose sur la lecture des pages de résultats de Google. Le procès antitrust du DoJ contre Google a abouti en 2024 au constat d’un monopole sur la recherche généraliste : il n’existe pas de source de remplacement. Ce qui se passe sur ces pages, c’est le marché.
Depuis 2024, des entreprises d’IA puisent massivement dans les résultats de Google pour alimenter leurs propres réponses, sans l’accord de Google. Lors du procès antitrust américain, un dirigeant d’OpenAI a déclaré sous serment qu’OpenAI avait demandé l’accès à l’index de Google et s’était vu refuser. Depuis, de nombreux chercheurs indépendants, dont nous, ont montré que les réponses de ChatGPT se construisent en partie sur des résultats de Google. Les protections décrites dans cette page défendent aussi Google face à ses concurrents les plus récents.
La chronologie de la partie II montre la séquence : la fin des 100 résultats par page (septembre 2025), des liens de redirection sur chaque résultat (août 2026), quatre nouveaux contrôles du navigateur (août 2026) et un module qui garde des données d’un passage à l’autre (juillet 2026). Aucune annonce, aucun numéro de version. Chaque étape rend l’observation indépendante plus difficile et plus coûteuse.
Pendant que la pièce s’assombrit, les tribunaux et les régulateurs cherchent l’interrupteur. Dans l’affaire antitrust américaine, le tribunal a ordonné à Google de partager des données de recherche avec des concurrents qualifiés (septembre 2025). En Europe, le règlement sur les services numériques (DSA) donne aux chercheurs agréés un droit d’accès aux données des très grands moteurs de recherche. Ce que le code de Google éteint, la loi commence à rallumer.
Ce que les gens cherchent est produit par le public. Aujourd’hui, une seule entreprise décide qui peut l’observer.
Dans les essais contrôlés, le refus suit la valeur native de navigator.webdriver. À Chrome, machine et réseau constants, les résultats s’affichent lorsque cette propriété vaut false, même avec le réglage --enable-automation. Lorsqu’elle vaut true, le navigateur est refusé, même sans ce réglage. Le réglage de lancement et le signal exposé à la page peuvent donc être distingués expérimentalement.
| Configuration | Se déclare automatisé | Sortie réseau | Parcours observé |
|---|---|---|---|
| Client HTTP sans JavaScript | Sans objet | VPN comparée | Reste sur le challenge |
| Chrome lancé normalement, recherche tapée au clavier | Non | IP native | Résultats après challenge |
Même Chrome + le seul réglage --enable-automation | Oui | IP native | Refus |
| Chrome piloté par Playwright, avec interface | Oui | IP native et VPN | Refus |
| Chrome piloté par Playwright, headless | Oui | VPN comparée | Refus |
| Camoufox · profil neuf | Non | IP native et VPN | Résultats après challenge |
| Camoufox · session conservée | Non | VPN fixe, essais de session | Résultats directs |
La ligne de partage suit la déclaration d’automatisation. L’IP seule ne suffit pas à expliquer les différences : sur IP native comme sur VPN, Camoufox obtient des résultats là où Chrome piloté par Playwright est refusé, et le même Chrome lancé normalement passe sur l’IP native.
La comparaison croise deux facteurs : la présence de --enable-automation et la valeur native de navigator.webdriver. Les quatre combinaisons sont répétées dans deux blocs d’ordre randomisé, avec un profil neuf à chaque navigation. Deux témoins Chrome ordinaires encadrent la série et affichent tous deux les résultats.
--enable-automation | navigator.webdriver | Résultat |
|---|---|---|
| Absent | false | 2 / 2 résultats |
| Présent | false | 2 / 2 résultats |
| Absent | true | 2 / 2 refus |
| Présent | true | 2 / 2 refus |
Le getter JavaScript reste natif : la valeur est contrôlée par le navigateur, sans remplacer la propriété dans la page. La fonctionnalité Blink AutomationControlled est désactivée dans les quatre combinaisons ; une commande CDP règle le signal indépendamment du flag. Knitsail et la VM YouTube lisent cette propriété (voir les lectures observées). Le résultat soutient un rôle causal du signal natif dans cet environnement, sans révéler le score serveur ni établir une règle universelle.
Parcours du test avec le réglage seul, sans intervention sur la valeur native :
--enable-automationSur les profils neufs observés, Google sert une page de vérification avant de recharger la recherche avec les éléments produits par le contrôle. Les traces du test du réglage seul situent ce rechargement environ 0,2 seconde après la réponse. Le document principal conduit ensuite soit aux résultats, soit à /sorry et à une réponse 429. La classification utilise la navigation principale, la présence des résultats et les captures d’écran ; une requête de fond vers /sorry ne suffit pas à classer la navigation comme refusée.
Dans la matrice contrôlée, la présence du flag ne distingue pas les résultats ; la valeur native de webdriver les distingue dans tous nos essais. Les témoins acceptés et les adresses IPv4 et IPv6 constantes limitent l’explication par un changement de réseau.
Deux essais par combinaison, sur une machine, un réseau et une requête : ces effectifs ne donnent pas un taux de réussite généralisable. Un remplacement du getter par du JavaScript retournant false a également été refusé ; cette intervention n’est donc pas un contrôle neutre. Protocole et contrôles complémentaires : signal d’automatisation et réglages de Chrome.
À navigateur et sortie réseau fixes, nous avons comparé des copies d’un même profil, en conservant ou en supprimant le cookie NID. Le contraste est reproduit : la session conservée évite le challenge, sa suppression le réintroduit.
Repartir d’un profil vierge ou supprimer des cookies peut réintroduire un contrôle que la session conservée évitait.
Le retour du challenge n’est pas un échec : les résultats arrivent aussi après celui-ci. NID est associé ici à un effet de session ; SG_SS transporte un résultat du challenge. Ces observations ne font pas de NID un passe universel et ne mesurent pas la durée de validité de SG_SS.
Même requête, même IP, deux listes sans URL commune. Ce contraste nourrit une suspicion d’empoisonnement des résultats par Google : des pages plausibles seraient servies à un client automatisé avec un contenu volontairement altéré.
Le 18 octobre 2026, les deux recherches démarrent à 2 minutes d’intervalle. Les profils sont deux copies du même profil source ; seul NID diffère parmi les cookies transmis. La branche conservant NID reçoit directement les résultats ; l’autre passe par un challenge.
louvre.fr/Fin des résultats principaux
louvre.fr/en/Sur fond bleu : l’accueil du site officiel, en français à gauche, en anglais à droite. Ce sont deux URL distinctes.
0 URL cible commune entre les 6 et les 9 résultats. La seconde liste met en avant des ressources pédagogiques, la presse, l’école, la boutique et la billetterie.
Sur l’ensemble de la série du 18 octobre, l’accueil du Louvre arrive le plus souvent septième, plus rarement premier, et manque parfois parmi les résultats principaux. Dans les branches qui conservent NID, les pages où il est septième enregistrent un appel Validate, 8 à 10 secondes après la réception de la page. L’ordre affiché est déjà fixé à ce moment-là : sur toutes les pages, l’ordre reçu correspond à l’ordre final.
Partie II
L’évolution de la protection, ses composants et les échanges observés. Le code décrit des capacités ; les traces montrent lesquelles ont été exécutées dans nos sessions.
La protection s’enrichit sans changer de version majeure de BotGuard : page intermédiaire, contrôles en arrière-plan, reprise de requêtes, puis en 2026 de nouveaux tests du navigateur et un module qui garde des données d’un passage à l’autre. Les dates techniques sont celles des premières observations disponibles dans notre corpus, pas nécessairement celles du déploiement.
BotGuard est déjà en version 41. Ce numéro reste utilisé en octobre 2026, malgré la rotation des scripts et de leurs paramètres de chiffrement.
Le code des résultats traite le paramètre sg_ss et prévoit un renvoi vers /httpservice/retry/enablejs lorsque JavaScript est désactivé.
Google a confirmé l’exigence de JavaScript le 17 janvier 2025, en la présentant comme une protection contre les bots et le spam (TechCrunch).
Une page intermédiaire embarque knitsail, produit le cookie SG_SS et relance la navigation. Ce mécanisme est établi au plus tard en mai 2025.
Google cesse de prendre en charge num=100. La collecte des 100 premières positions peut désormais nécessiter environ dix pages de résultats au lieu d’une.
Arrêt constaté dans la nuit du 11 septembre 2025, rapporté le 15 septembre par Search Engine Land. Le 18 septembre, Google a déclaré ne pas prendre officiellement en charge ce paramètre.
Le canal /sgasync, associé au code BMW, livre ensemble le script, son hash et son programme. Il complète un parcours de protection déjà existant.
Le canal sg_ck=QyE sert au contrôle en tâche de fond, avec un programme distinct de celui de BMW.
Avec le mode sg_ck=ON4, le client peut calculer un token puis réessayer une requête avec X-Sg-Ss. Ce parcours est distinct de la page intermédiaire.
Les moteurs intègrent des fonctions manipulant sandbox, srcdoc et le chargement de scripts. Knitsail reçoit aussi ces fonctions.
Une partie des requêtes reçoit le programme du contrôle de fond augmenté d’un module d’environ 6 Ko. Ce module conserve un historique d’interactions dans le navigateur (localStorage) et le relit au passage suivant (structure et contenu). Les deux versions sont servies en même temps, pour une même adresse de requête.
Observé du 8 juillet au 17 octobre 2026. En juillet, 10,5 % des captures contiennent ce module, toutes entre le 8 et le 16 ; ensuite, environ 1 %. Les données ne sont relues que par l’exemplaire de programme qui les a écrites. Test A/B, échantillonnage ou ciblage côté serveur : notre corpus ne permet pas de trancher.
Le programme du contrôle QyE lit des réglages déclarés par le navigateur (plateforme, « Do Not Track »), mesure la hauteur d’un texte avec et sans césure, teste la précision du pointeur (souris ou écran tactile) et interroge la carte graphique via WebGPU. Le programme décodé grossit d’environ 13 % (+2,6 Ko) ; le moteur qui l’exécute ne grossit pas.
Apparition datée entre le 20 août à 12:06 et le 22 août à 20:58 UTC : notre corpus ne contient aucune capture entre ces deux moments, et les quatre tests arrivent ensemble. La taille du programme ne dit rien de son coût d’exécution ni de son efficacité contre les bots.
Google déploie des liens de redirection /goto dans ses pages de résultats. L’URL finale doit parfois être résolue séparément. Une requête HTTP ordinaire suffit encore dans les cas documentés.
Déploiement confirmé par Google à Search Engine Land le 26 août 2026, après plusieurs mois de tests selon le média.
Le canal /sgasync associe sg_ck=QyE au paramètre sg_fe=flights.
Le contrôle de fond cesse d’interroger la carte graphique via WebGPU. Les trois autres tests ajoutés en août restent en place. Le changement coïncide avec une nouvelle version du moteur JavaScript.
Retrait daté entre 06:53 et 14:07 UTC le 5 octobre 2026. Notre session en direct du 17 octobre le confirme : navigator.gpu n’est plus lu. Le programme perd environ 320 octets.
Les jalons orange concernent la collecte des résultats. Ils sont distincts des mécanismes BotGuard. « Confirmé par Google » désigne une confirmation rapportée dans la source liée ; « Première observation » renvoie à nos captures de code et de pages.
SearchGuard est le nom employé par Google pour sa protection de Search. BotGuard est un moteur d’attestation côté navigateur : sa machine virtuelle (VM) exécute un programme fourni par Google. Le moteur et le programme sont deux objets distincts, qui peuvent évoluer séparément.
/async/bgasy fournit l’adresse du script et le programme. La VM suit notamment les interactions avec les résultats. Aucun token de sortie n’a été repéré pendant ces sessions.
/sgasync livre ensemble le moteur et son programme. Ce contrôle inspecte le navigateur et envoie un token à Validate, sur les résultats classiques comme dans AI Mode.
Une VM dans un cadre adtrafficquality.google produit un token pour le circuit publicitaire pagead/sodar.
Le lecteur embarqué apporte sa propre VM et des échanges avec le service Waa/GenerateIT. Sa présence dépend du contenu de la page.
Jusqu’à quatre VM ont coexisté sur une page observée. Elles ne remplissent pas toutes le même rôle : la publicité et YouTube ont leurs propres circuits. La copie du moteur de la page d’accueil a été analysée séparément, sans trace de ses lectures dans ces sessions.
Les trois VM des résultats, de knitsail et de la publicité observées le 17 octobre, ainsi que la copie de la VM d’accueil du 18 octobre, déclarent la version 41. La version de la VM YouTube n’a pas été relevée. Le nom de la fonction d’entrée tourne : pour les 26 programmes capturés le 17 octobre, ses trois premières lettres correspondent aux trois premiers caractères du programme encodé.
| Élément | Observation |
|---|---|
| Version | Les scripts /js/bg/ et les VM incluses dans /sgasync étudiés déclarent la version 41. |
| Espaces de noms | window.botguard pour les résultats et la publicité ; window.knitsail, constructeur ks, pour knitsail. |
| Registres | Indices relevés jusqu’à 511 dans la VM publicitaire et 484 dans knitsail : compatibles avec un espace de 512 emplacements. Le rôle de chaque indice n’est pas stable entre scripts. |
| Obfuscation | Identifiants courts, dispatch par états, calculs bit à bit, chaînes reconstruites à l’exécution. Des lignes vides aléatoires sont ajoutées au code évalué ; une source map factice porte le nom closureDynamicButton. |
| Hash des scripts | Le nom des fichiers /js/bg/ et publicitaires vérifiés correspond au SHA-256 en base64url du contenu. Pour les réponses /sgasync étudiées, le champ de hash correspond exactement au script inclus. |
| Iframes et sandbox | Le code configure notamment sandbox, retire srcdoc et affecte une URL à l’iframe. Certaines autorisations y sont ajoutées, dont allow-same-origin et allow-scripts. |
Le contrôle peut intervenir avant les résultats, sur une page déjà affichée ou lors d’un appel supplémentaire. Ces trois parcours sont distincts : ils ne constituent pas une séquence obligatoire.
Si le parcours aboutit à un refus : une redirection vers /sorry peut conduire à un reCAPTCHA. Dans les captures étudiées, cette redirection efface SG_SS. Le serveur reste décisionnaire ; une page HTTP 200 peut aussi être un challenge.
La reprise avec X-Sg-Ss est réellement capturée. En revanche, ni une réponse vide de Validate ni la production d’un token ne révèlent le verdict interne du serveur.
Le client installe une couche autour de fetch et de XMLHttpRequest pour les requêtes de même origine. Une première couche met des réponses en attente dans __sg_lite_queue ; une seconde les traite quand elle est prête. Les valeurs ci-dessous décrivent le protocole observé ; aucune n’est un score de confiance.
| Nom | Sens établi par le code |
|---|---|
x-sg-e | Valeurs observées : 2,isrpe=1,hcs=1 dans le corpus initial et 1,isrpe=1,hcs=1 dans la reprise VPS du 18 octobre. Le client conserve le mode 1 quand l’appelant l’a demandé ; sinon il utilise 2. Il ajoute des indicateurs de capacités. |
isrpe | Dérivé de isrpeEnabled ou de window.sglc.isrpe. Il participe à la décision de recharger la page pour un contrôle synchrone ; le libellé interne exact de l’acronyme n’est pas publié. |
hcs | Dérivé de hasCaptchaSupport ou de window.sglc.hcs : capacité du client à prendre en charge le CAPTCHA. |
X-Sg-Cs | En-tête de réponse. Le client distingue les valeurs commençant par s (branche synchrone) et a (événement asynchrone). Un chemin de reprise teste exactement s et a. Le préfixe sfl reçoit un traitement particulier. |
X-Sg-Ss | Porte le token calculé lors de la reprise d’une requête. Il s’agit d’un en-tête, distinct du cookie SG_SS de la page intermédiaire. |
X-Sorry-Redirect | Sa présence, ou une URL de réponse contenant /sorry/index, déclenche le traitement du parcours CAPTCHA. |
Dans le chemin de reprise étudié, les codes internes 0, 1, 2 et 3 sélectionnent respectivement : calcul d’un token et nouvel essai ; événement sglacte ; attente d’un événement sglhcte_retry après sglhcte ; restitution de la réponse sans ce traitement. Ce sont des codes de branchement locaux, sans lien avec un niveau de risque.
Le code distingue le contrôle demandé par une requête (ON4) d’un chargement non synchrone (BMW). Les captures montrent aussi le canal de fond QyE. Les noms courts sont des identifiants opaques : leur rôle se déduit des appels et des observations ; nous n’interprétons pas leurs lettres.
Dans le client d’octobre examiné, la configuration est issue de bits du tableau x. Les noms ci-dessous sont locaux à cette copie et peuvent tourner avec l’obfuscation. Leur présence montre ce que le code sait faire, sans dire si ces branches sont activées.
| Interrupteur local | Effet de la branche |
|---|---|
Ob | Autorise le parcours de démarrage dans setup(). |
Qb | Choisit le démarrage synchrone ; l’autre branche attend une seconde puis un créneau inactif. |
Dd | Sur changement de visibilité, peut produire le résultat quand la page devient cachée. |
Bd | Court-circuite dans cette branche la récupération du résultat de la VM. |
Cd / vc | Le premier conditionne l’envoi ; le second choisit le chemin /sgvalid au lieu de Validate. |
bd / cd | Peuvent différer l’envoi jusqu’au rappel DOMContentLoaded, ou ajouter un délai de 1 000 ms. Présence de branches, sans preuve qu’elles aient été activées pendant les sessions. |
Lc / zd | Contrôlent deux chemins de télémétrie distincts : journal d’étapes et mesures de durée. |
Cette matrice résume les lectures et les listeners observés pendant l’instrumentation. « Non observé » ne signifie pas que le moteur en est incapable : le programme reçu et la session déterminent ce qui s’exécute.
| Signal | Résultats | Knitsail | Publicité | YouTube |
|---|---|---|---|---|
| Clics et contacts tactiles | Oui | Oui | Non observé | Oui |
| Souris, clavier, molette | Non observé | Oui, dont positions de certains événements souris | Non observé | Listeners ; positions souris non lues |
| Navigateur et écran | Très limité : window.scrollbars | Propriétés du navigateur et dimensions | Quelques propriétés selon le programme | Inspection étendue |
| Indices d’automatisation | Non observé | webdriver, window.chrome | Parfois window.chrome | webdriver, window.chrome |
| Inventaire des noms globaux | Oui | Oui | Non observé | Non observé |
| WebGL / GPU | Non observé | Non observé | Non observé | Nom du GPU |
| Visibilité de l’onglet | Oui | Non observé | Oui | Oui, et focus |
| Mesure du temps | Oui | Oui | Oui | Oui |
| Inspection du code et des propriétés | Son propre code | Fonctions et accesseurs du navigateur | Non observé | Propriétés du navigateur |
Knitsail et la VM YouTube inspectent l’environnement plus largement que les deux autres VM. Mais ces lectures ne révèlent ni les coefficients, ni les seuils, ni le modèle de décision de Google.
Depuis le 22 août 2026, le programme du contrôle de fond lit aussi des réglages déclarés par le navigateur (navigator.platform, navigator.doNotTrack, window.doNotTrack). Il crée des blocs de texte cachés, en police à chasse fixe, et compare leur hauteur avec et sans césure automatique (hyphens). Il demande au navigateur si le pointeur est précis ou grossier (any-pointer: fine et coarse) : souris ou écran tactile. Jusqu’au 5 octobre, il interrogeait aussi la carte graphique via WebGPU (requestAdapter, puis fabricant et architecture).
Ces lectures sont relevées en exécutant hors ligne les programmes récoltés, de novembre 2025 au 17 octobre 2026. Notre session en direct du 17 octobre confirme la lecture des réglages et le test du pointeur, ainsi que l’absence de WebGPU. Détail : contrôle de fond, novembre 2025 à octobre 2026.
La matrice contrôlée distingue le réglage de lancement du signal natif navigator.webdriver : dans tous nos essais, le résultat suit la valeur du signal. Elle ne permet pas d’attribuer le verdict serveur à une lecture particulière d’une VM (voir les essais d’accès).
La variante du contrôle de fond équipée du module localStorage conserve des enregistrements d’interactions et les relit lors d’une exécution suivante. Sur le programme du 18 août, une chaîne de 21 passages avec des clics distincts laisse exactement les 20 derniers enregistrements, dans leur ordre : le plus ancien est retiré. Il s’agit de vingt exécutions du programme, pas de vingt clics dans une page.
Les champs de coordonnées conservent le dernier clic observé. Un clic en (123, 234), suivi d’un déplacement en (500, 400), laisse (123, 234). Un déplacement seul ne renseigne pas ces champs.
Un bloc contient 32 compteurs d’un octet dans les cas testés. Une frappe active trois compteurs ; trois frappes les portent à 3. Les touches « a » et « b » produisent le même contenu : ce bloc décrit les événements observés, sans y distinguer ces caractères.
Les programmes de juillet à octobre partagent tous la même structure : enveloppe de 8 octets ; contenu décodé avec marqueur 01 be ef, bloc de 12 octets, enregistrements et compteur final. Chaque enregistrement comporte un horodatage sur 4 octets, un champ d’un octet observé à 1, une longueur sur 2 octets et une charge utile variable. Le rôle du bloc de 12 octets et du champ égal à 1 reste indéterminé.
Sans interaction, la charge utile mesure 114 octets : le total binaire vaut 24 + 121 × n octets pour n enregistrements, soit 145 pour un seul et 2 444 pour vingt. Les interactions allongent la charge utile ; cette formule ne s’applique donc pas à tous les scénarios. Les horodatages de tous nos exemplaires correspondent à la capture du programme à une seconde près, et non à la date de visite simulée.
Le recensement de 134 états montre dix suffixes numériques de clé en juillet et un encodage base64 avec remplissage en juillet–août. Les exemplaires de septembre–octobre utilisent une clé sans suffixe et du base64 URL-safe sans remplissage. Le changement est encadré par nos captures du 18 août et du 28 septembre ; sa date exacte de déploiement reste inconnue.
La structure est observée sur tous les programmes décodés ; les interventions sur les clics, les compteurs et la file à vingt passages concernent celui d’août. Ces résultats ne démontrent ni un identifiant personnel stable, ni un suivi intersites, ni l’usage de cet historique dans le score serveur. Détails du contrôle de fond et du stockage.
L’instrumentation peut elle-même modifier les propriétés inspectées. Les comparaisons de contrôle et les replays documentent certaines perturbations ; ils ne prouvent pas que l’observation soit invisible pour Google.
Le moteur sait exécuter des instructions ; le programme reçu précise le travail à effectuer. Un token est le résultat transporté vers Google. Il ne constitue pas, à lui seul, une autorisation d’accès.
Dans le parcours knitsail étudié, /sgasync transporte le script, son hash et le programme encodé.
Le client transforme les octets, décode l’UTF-8 et lit l’enveloppe JSON. Cette étape est distincte du chiffrement des tokens.
La VM exécute le programme, lit des signaux et produit une sortie. Les rôles varient selon le programme.
La sortie emprunte le transport du parcours : cookie, en-tête de requête ou appel à un service.
Le premier est un cookie de la page intermédiaire ; le second est un en-tête ajouté à une requête réessayée. Leurs noms proches ne les rendent pas interchangeables.
Les hash SHA-256 correspondent aux scripts vérifiés. Ils identifient le code reçu ; ils ne mesurent pas la confiance accordée au navigateur.
Le client lit la réponse comme un tableau d’octets, ajoute 97 à chaque octet modulo 256, puis décode le résultat en UTF-8 et le parse. Cette transformation de transport est distincte du chiffrement des tokens. Les réponses analysées ont une enveloppe de huit positions. Le programme reste un objet distinct du script de la VM.
| Position (base 0) | Contenu observé |
|---|---|
| 0 | bfkj : marqueur d’enveloppe. |
| 1 | Tableau de six positions ; le script JavaScript occupe la position 5, les cinq premières sont nulles. |
| 2 et 6 | null dans les réponses étudiées. |
| 3 | SHA-256 base64url du script. |
| 4 | Programme encodé, avec préfixe de fonction d’entrée. |
| 5 | knitsail : espace de noms. |
| 7 | Chaîne auxiliaire. Sa signification n’est pas établie par cette analyse. |
Les requêtes Validate du corpus initial du 17 octobre sont toutes des GET : le paramètre reqpld contient un tableau JSON. Leur réponse est [""]. Le code relie ses positions aux numéros de champs du message. Nous n’attribuons aux valeurs que les significations démontrées.
| Champ du message | Position et contenu |
|---|---|
| 1 | Position 0 : token texte. Corpus initial : 1 471 à 1 544 caractères (53 % des appels) ; pilote VPS : 1 417 à 1 441 (12 %) ; série contrôlée : 1 400 à 1 448 (35 %). Ces distributions ne prouvent ni acceptation ni invisibilité de l’instrumentation. |
| 2 | Position 1 : contexte ; le champ imbriqué 9 contient un sous-message dont le champ 1 reçoit ei. |
| 3 | Position 2 : nulle dans toutes les requêtes. Le code prévoit une représentation binaire alternative au token texte, dans le même groupe exclusif que le champ 1. |
| 4 | Position 3 : valeur 3 dans toutes les requêtes. Le code prévoit aussi 1 et 2 pour une autre source de résultat ; cela ne démontre pas trois niveaux de confiance. |
Identifiants courts, chaînes reconstruites, dispatch par états : le code masque sa structure. Les hash, noms d’entrée et paramètres changent, même lorsque le numéro de version reste 41.
Les moteurs combinent additions, rotations et XOR (ARX). Les réglages diffèrent entre VM. Une ressemblance avec une famille de chiffrements ne suffit pas à identifier précisément l’algorithme.
Le code contient une mise à jour de moyenne et de dispersion de type Welford, ainsi qu’un réservoir de taille bornée. Ces capacités ne démontrent pas quelles métriques le serveur utilise pour décider.
Dans les contrôles hors ligne, extraire le code avec son enveloppe d’origine rétablit les sorties. Reformater ensuite le code intérieur les modifie de nouveau.
Ce contraste est reproduit sur tous nos échantillons. Il soutient une sensibilité au texte source, sans localiser un mécanisme d’intégrité précis ni établir la détection des modifications côté serveur.
Le code combine additions, rotations et XOR (ARX), avec des rotations de 8 et 3 bits. Les moteurs étudiés utilisent 14, 15 ou 16 tours. Une constante peut être littérale ou passée en argument : l’analyse suit les appels pour éviter de confondre une limite de boucle voisine avec le nombre de tours. Une ressemblance de structure avec une famille de chiffrements n’établit pas l’identité de l’algorithme.
| Copie étudiée | Tours | Constante |
|---|---|---|
| Résultats, 17 octobre | 15 | 2905 |
| Publicité, 17 octobre | 15 | 2905 |
| knitsail, 17 octobre | 16 | 1088 |
| Accueil, 18 octobre | 15 | 1795 |
Les réglages diffèrent donc aussi entre VM servies au même moment. Les changements de hash et de constante documentent une rotation des scripts ; ils ne prouvent ni l’invalidation immédiate des anciens tokens ni la durée d’acceptation côté serveur. Les caractères initiaux ! et * et la structure binaire des tokens servent à comparer des familles de tokens ; ils ne renseignent pas sur le verdict.
Le moteur contient une mise à jour incrémentale de moyenne et de dispersion de type Welford, puis calcule sqrt(M2 / n) : un écart-type de population. Il contient aussi un réservoir de taille bornée. Ces routines décrivent des capacités du moteur ; leur présence ne démontre pas les métriques ni les seuils que le serveur emploie pour décider.
n = n + 1 delta = x - mean mean = mean + delta / n M2 = M2 + delta * (x - mean) standard_deviation = sqrt(M2 / n)
La VM des résultats installe quatre types de listener : mousedown, mouseup, touchstart, touchend. Knitsail ajoute notamment les mouvements de souris, le clavier et la molette. Aucun listener scroll n’a été observé dans ces sessions. Le code contient une liste de 101 noms de balises, ce qui ne prouve pas que 101 éléments soient systématiquement surveillés.
Knitsail et la VM YouTube lisent navigator.webdriver, testent l’attribut webdriver de la balise HTML et inspectent des propriétés de window.chrome. La VM des résultats et knitsail inventorient aussi les noms globaux de la page. Les noms recherchés dans cet inventaire ne sont pas établis. Aucun seuil chiffré séparant un humain d’un bot n’est démontré par ces observations.
Les 96 replays VM et les 48 cas synthétiques du contrôleur sont documentés dans le rapport expérimental. Les replays ne transmettent aucun token produit à Google. Les tests du contrôleur reproduisent des branches locales, sans mesurer la validité des tokens côté serveur.
Les conclusions ci-dessus réunissent les observations par sujet. Les corpus restent distincts dans les sources pour conserver leur traçabilité.
Configurations. Chrome 153.0.8010.52 (même binaire, SHA-256 identique), Playwright 1.51.0, Camoufox Firefox 135.0.1-beta.24 (paquet 0.4.11), client HTTP sans JavaScript. La matrice factorielle utilise Chrome avec interface, un viewport de 1280 × 720, une connexion CDP dans chaque cellule et un getter webdriver natif vérifié avant et après navigation. Les quatre combinaisons sont exécutées dans deux blocs randomisés, avec deux témoins ordinaires extérieurs. Les contrôles des réglages de Playwright comparent séparément le flag, la liste de 17 fonctions désactivées et les 29 autres options.
Terrain. Profils dédiés sans compte Google personnel, navigateur avec interface sous Xvfb. Pilote sur IP native du VPS et sorties VPN ; série de session sur une sortie américaine fixe, avec langue fr-FR, hl=fr et gl=fr. Le pays de sortie diffère donc du pays demandé, mais reste identique entre les branches comparées.
Corpus. Observation des VM : quatre sessions, trois profils et neuf pages de résultats. Pilote VPS : 37 essais enregistrés, dont trois arrêtés avant Google, plus une navigation en session ouverte. Contrôle NID : 21 navigations, dont trois profils sources et neuf paires. Comparaison des navigateurs et réglages : 37 navigations. Matrice factorielle webdriver : huit essais et deux témoins. Contrôle de fond : 444 captures récoltées, du 13 novembre 2025 au 17 octobre 2026 ; 441 exécutées hors ligne et 69 tracées pour les familles de tests, trois réponses Google Flights de format différent écartées. Stockage : six programmes décodés, 134 états recensés, une chaîne de 21 passages avec clics distincts sur le programme d’août. Autres contrôles hors ligne : 96 replays de quatre VM et 48 cas de contrôleur. Ces corpus ne s’additionnent pas en un taux de réussite.
Contrôles. La matrice webdriver conserve la requête, le binaire et les adresses IPv4 et IPv6 ; chaque navigation utilise un profil neuf. Le contrôle de session conserve la configuration et l’identité JavaScript observée, vérifie l’IP avant et après navigation et alterne l’ordre. Huit paires sur neuf ne diffèrent que par NID parmi les cookies transmis ; la dernière diffère aussi par __Secure-STRP. Les attentes sont mesurées depuis l’ouverture du contexte. Le stockage est étudié hors ligne avec le moteur et le programme récoltés, sans soumettre les tokens produits à Google.
Limites. Essais courts, états serveur non contrôlés, deux répétitions par cellule factorielle. Le signal est réglé par des commandes du navigateur dans un environnement où AutomationControlled est désactivé. Les profils neufs ne sont pas identiques bit à bit. Les replays ne testent pas l’acceptation des tokens en ligne ; la limite FIFO à vingt passages est établie sur le programme d’août. Le test de visibilité ne permet pas de comparer visible/caché. Les dates du contrôle de fond sont des dates de capture, encadrées par nos captures voisines ; le contexte des requêtes récoltées est inconnu. Cookies, tokens, HAR, profils et captures brutes restent privés.
Les scripts d’octobre sont les copies servies par Google, non déobfusquées. Leur en-tête indique une licence Apache-2.0, Copyright Google LLC.
