Profondeur de pile JavaScript : un signal de confidentialité

Cet article porte sur la profondeur de pile, la mesure qui montre combien de récursion un contexte JavaScript supporte avant d'échouer. BotBrowser propose un réglage de profondeur dans sa limite de support ; une surcouche peut rapporter le résultat, mais n'égalise pas des contextes ou des versions différents.

Résumé rapide

Exécutez le même fixture de récursion bornée dans le contexte principal et dans un Worker, et notez le build du navigateur avec le résultat. Un changement entre exécutions est une différence de contexte ou de version tant que le contraire n'est pas montré.

Sommaire de la guide

• Ce que mesure le résultat
• Pourquoi le contexte et la version comptent
• Limite de support de BotBrowser
• Choisir un mode d'examen
• Examen reproductible de l'application
• Lire un compte qui a bougé
• Limites et décisions de confidentialité

La récursion JavaScript a une limite pratique. Lorsqu'une fonction s'appelle sans cesse, le navigateur arrête les appels et signale un débordement de pile, souvent avec une RangeError. Le nombre d'appels réussis avant l'erreur est un comportement observable. La plateforme web ne définit pas une valeur unique, donc ce nombre varie selon les implémentations, les versions, les systèmes et les contextes. BotBrowser peut exécuter une vérification de profondeur de pile dans un contexte isolé et contrôlé avec un même profil ; il ne peut pas rendre la profondeur identique d'un build, d'une plateforme ou d'un moteur JavaScript à l'autre.

Cette différence concerne la confidentialité, car une page peut exécuter un petit test récursif et garder le résultat comme une entrée d'empreinte du navigateur. Le nombre n'est ni un nom, ni un identifiant de compte, ni une preuve de localisation. C'est un signal technique limité qui peut ajouter une séparation modeste avec d'autres observations. Le traiter comme un seul signal évite de transformer un détail de compatibilité en identité.

La question utile pour une équipe n'est pas de réunir un profil plus riche. Il faut garder un comportement prévisible quand la valeur change et choisir une configuration cohérente avec le profil examiné. Une application dotée d'un repli doit continuer si le test est indisponible, incertain ou différent d'une autre session. Aucune tâche utilisateur ne doit dépendre d'un nombre donné.

Ce que mesure le résultat

Chaque appel JavaScript ajoute un cadre à la pile d'appels. Le cadre contient les informations de retour et l'état d'exécution, tandis que le navigateur gère la mémoire et les contrôles de sécurité. La forme du cadre compte : une petite fonction récursive peut atteindre un autre nombre qu'une fonction avec davantage de paramètres ou de valeurs locales. Le résultat décrit donc le test et le contexte. La comparaison n'est valable que si la forme du test et l'état de la page restent stables.

L'erreur finale protège la page contre une récursion sans fin. La capturer permet de terminer le contrôle, mais ne déplace pas la limite. JavaScript ne peut pas demander une pile native plus grande pour un thread existant ni réécrire cette gestion. Un script peut choisir de ne pas tester, sans modifier ce qu'une autre page peut observer dans son contexte.

L'allocation de pile du système est un facteur parmi d'autres. Les implémentations utilisent des cadres, marges de sécurité, optimisations et initialisations de contexte différents. Une mise à jour peut changer ces détails. Une machine qui dispose de mémoire libre peut donner un autre résultat, car la limite est une politique d'exécution et non une mesure de mémoire disponible.

La fenêtre principale et un worker ne commencent pas forcément dans les mêmes conditions. Les workers dédiés et partagés ont leur propre préparation, et WebAssembly suit ses règles. Une comparaison doit noter le contexte et la forme du test. Le résultat du thread principal ne promet rien pour un worker et ne doit pas servir à classer un appareil.

Pourquoi le contexte et la version comptent

Une page peut observer une valeur stable pendant une session, mais cette stabilité n'est pas permanente. Les versions, mises à jour du système, protections et changements de code peuvent modifier le nombre. Une petite modification de la fonction récursive suffit aussi. Une valeur historique est donc une preuve faible, et le support doit noter la version et la révision du test.

Le signal convient surtout à un contrôle de cohérence dans un test appartenant à l'équipe. Elle peut comparer le résultat principal avec celui d'un worker que l'application utilise. Le test indique si le profil choisi convient à cette application. Il ne doit pas identifier un visiteur, déduire son matériel ni décider d'un accès à partir du nombre.

Le guide sur les empreintes MIME et codecs complète l'examen lorsque les capacités média sont aussi testées ; gardez cette observation séparée du nombre de récursion.

Un service respectueux garde le résultat près de la décision concernée. Si l'application doit seulement décider si une fonction récursive facultative est sûre, une politique locale suffit et le nombre brut peut être supprimé. Dans un cas de support, notez la révision, la version et la politique, au lieu d'ajouter le nombre à un identifiant de compte. Il devient ainsi plus facile à supprimer et moins utile comme étiquette entre sessions.

Pour une comparaison concrète, consignez browserVersion, profileId, fixtureRevision, context et le RangeError capturé ; ces champs expliquent l'écart sans conserver un identifiant de visiteur.

La même limite s'applique aux analyses. Un tableau peut indiquer qu'une fonction a pris le chemin de base ou réduit, sans trier les personnes par profondeur. Les résultats agrégés de réussite, d'annulation et de reprise décrivent mieux l'expérience. Le contenu et les contrôles essentiels restent disponibles lorsque la mesure manque.

Limite de support de BotBrowser

BotBrowser fournit --bot-stack-seed pour choisir l'origine de la limite de récursion JavaScript observable pour un profil. profile utilise la profondeur associée au profil. real garde le résultat natif de l'hôte. Une graine entière demande une variation déterministe, afin que le même profil et la même graine servent de donnée répétable. Ce sont des choix pris en charge, pas la promesse d'un nombre fixe pour chaque application.

Le réglage vise à aligner le signal visible dans le navigateur avec le profil examiné. Il peut appliquer le comportement choisi au thread principal, aux Web Workers et aux contextes WebAssembly pris en charge. L'équipe doit néanmoins mesurer chaque contexte utilisé par son application, car les conditions diffèrent. Un profil ne remplace pas un test de compatibilité et un résultat ne prouve pas une identité.

BotBrowser ne modifie pas l'allocation native du système et ne supprime pas les limites générales de mémoire. Le comportement sélectionné concerne la limite observable par la page, pas l'utilisation ordinaire de la pile de l'application. Le code courant doit rester loin de cette limite, mais une application qui récursive profondément doit effectuer ses propres tests de performance, d'erreur et de ressources.

BotBrowser ne sait pas non plus si une page tierce exécute un contrôle. Il peut fournir le comportement configuré, mais ne peut pas faire oublier la valeur à la page, choisir son stockage ou remplacer sa politique de confidentialité. La bonne réponse consiste à limiter la collecte, expliquer les diagnostics facultatifs et conserver un chemin de base.

Choisir un mode d'examen

Utilisez profile pour examiner une application avec le comportement de pile associé à un profil. C'est utile pour vérifier la cohérence des surfaces liées pendant une régression. Notez ensemble la version, le profil et la révision du test, afin de voir si une différence vient de la configuration ou de la page.

Utilisez real lorsque le test doit décrire l'hôte qui exécute le navigateur. Ce mode convient au débogage, au travail de capacité ou à un rapport représentant cette machine. Il ne rend pas le résultat portable et ne dit pas que l'hôte représente tous les environnements pris en charge.

Utilisez une graine entière pour une variation répétable sans écrire une profondeur manuelle. La graine est une entrée de configuration, pas un identifiant à afficher sur la page. Gardez-la avec le profil et la version dans un enregistrement contrôlé, sans la mettre dans un compte, une URL ou une analyse. Des graines différentes peuvent produire des résultats différents, donc comparez seulement les mêmes entrées déclarées.

Ne choisissez pas un mode pour forcer un nombre arbitraire. Une valeur extrême ou non documentée peut contredire d'autres surfaces du profil et cacher un défaut. La question prudente est de savoir si le profil et la version produisent un résultat plausible et répétable dans les contextes possédés par l'application. Si un travail récursif demande plus d'espace, vérifiez-le séparément en mode natif avec un suivi ordinaire des ressources.

Examen reproductible de l'application

Commencez avec un petit dispositif qui appelle une fonction récursive limitée et capture le débordement attendu. Notez seulement le nombre utile, le contexte et la version. Exécutez-le dans la fenêtre principale, puis dans chaque worker réellement utilisé. Le dispositif ne doit pas énumérer des propriétés sans rapport ni envoyer un inventaire technique au serveur.

Répétez le test avec le même profil et la même graine après un redémarrage propre. Un résultat reproductible indique une configuration chargée de façon cohérente, mais ne constitue pas une garantie de production. S'il change, vérifiez le chemin du profil, la version, le démarrage du worker et la révision du dispositif. Un paquet de page différent peut modifier la forme des cadres.

Examinez l'échec comme la réussite. Si la récursion est indisponible, si une erreur inattendue apparaît ou si un worker ne démarre pas, l'application doit garder le contenu nécessaire et montrer un repli compréhensible. Les améliorations facultatives peuvent attendre, tandis que la navigation, les contrôles de compte et l'état accessible restent utilisables. Ce comportement compte davantage que le nombre brut.

Pour un examen entre hôtes, comparez d'abord les entrées déclarées. Un nom de profil identique ne suffit pas si la version, les options, le code du dispositif ou le contexte diffèrent. Gardez un relevé court : identifiant du profil, mode, type de graine, version, contexte, politique et résultat. Ne conservez pas une description détaillée du matériel pour un seul nombre technique.

La vue d'ensemble des empreintes de navigateur explique la combinaison de petits signaux. Le guide des propriétés Navigator sépare une propriété rapportée d'une identité. Comparez le guide d'intégrité des API du navigateur lorsque le dispositif s'exécute dans plusieurs contextes. Ces liens donnent le contexte, sans transformer la profondeur en identifiant autonome.

La ligne de revue doit indiquer profile, real ou une seed entière, et marquer page, Worker et WebAssembly comme contextes mesurés.

Lire un compte qui a bougé

Ce qui a changé entre deux exécutions	Ce que cela signifie généralement	Vérification suivante
Seule la version du navigateur	La disposition des cadres ou la marge a bougé	Relancer une fois sur la version précédente
Seule la fonction du dispositif	La forme des cadres a changé, pas le navigateur	Figer la révision du dispositif puis comparer
Seul le contexte	Fil principal et worker n'ont jamais partagé de limite	Comparer chaque contexte à son propre historique
Tout, sur une même machine	Une option ou un chemin de profil n'a pas pris	Afficher la ligne de commande effective

Un compte qui bouge a quatre explications ordinaires, et le compte lui-même ne les distingue pas. Deux exécutions qui ne diffèrent que par une de ces variables répondent à une question ; deux qui diffèrent par plusieurs ne répondent à rien. Notez les quatre entrées, puis n'en changez qu'une.

Figez d'abord le dispositif. Enregistrez la fonction récursive comme fichier versionné et imprimez sa révision à côté du résultat, car un nombre de paramètres différent, une autre fermeture ou un bloc try ajouté changent la forme des cadres et donc la profondeur. Un dispositif qui a dérivé est la cause la plus fréquente d'une « régression » qui n'est en réalité qu'une modification de page.

Figez ensuite la version. Comparez la chaîne de compilation complète, pas seulement la version majeure, car la limite est une politique d'exécution qui suit le durcissement de sécurité et la génération de code. Quand seule la version a bougé, relancer une fois sur la compilation précédente sépare un vrai changement du bruit entre exécutions, ce que répéter la nouvelle compilation ne permet pas.

Troisièmement, comparez chaque contexte à lui-même. Un nombre du fil principal et un nombre de worker n'ont jamais été censés coïncider, et une paire de valeurs arrondies ne dit rien sur la stabilité de l'un ou l'autre. Enregistrez chaque contexte séparément sur deux exécutions de la même compilation.

Si les trois entrées étaient identiques et que le nombre a malgré tout bougé, affichez la ligne de commande effective avant d'accuser le navigateur. Une option présente dans le script de lancement mais absente des arguments du processus, ou un chemin de profil résolu vers un autre fichier dans un second shell, produisent un changement qui ressemble à une différence de navigateur sans en être une.

Un relevé court rend cela vérifiable plus tard :

release=142.0.7444.60
fixtureRevision=3
mode=profile
context=main   depth=10789  RangeError
context=worker depth=10761  RangeError

Deux fichiers de cette forme, pris à une version d'écart, suffisent à dire laquelle des quatre explications s'applique. Un nombre isolé copié depuis la console, non.

Limites et décisions de confidentialité

La profondeur a une entropie limitée et sert de preuve secondaire. Elle change selon la forme du code et l'exécution, et n'identifie pas seule un navigateur, un appareil ou une personne. La conserver indéfiniment peut coûter plus de confidentialité que sa valeur. Préférez une décision temporaire, une durée claire et la suppression à la fin du cas.

N'utilisez pas le nombre pour l'autorisation, la preuve de fraude, la localisation ou la sécurité d'un compte. Il ne dit pas si un visiteur est fiable et ne prouve pas que deux sessions appartiennent à la même personne. L'authentification, les limites de débit et la gestion des abus ont besoin de leurs propres preuves côté serveur.

Ne promettez pas un comportement identique dans toutes les familles de navigateurs, tous les systèmes, workers ou environnements WebAssembly. Les sources publiques définissent le périmètre, tandis que les tests de compatibilité établissent le support du produit. Si une version change le résultat, mettez le relevé à jour et étudiez l'effet visible avant de modifier une politique.

Une note de support claire doit dire les deux côtés : BotBrowser peut choisir un comportement de profil, natif ou semé pour les contextes pris en charge, mais ne modifie pas l'allocation de l'hôte, ne garantit pas un résultat applicatif et ne contrôle pas ce qu'une page tierce enregistre. L'action pratique est de tester le flux possédé, garder le repli et retenir seulement la preuve nécessaire.

Décrivez une variation du résultat comme une observation de compatibilité, et non comme une catégorie d'identité. Indiquez la version, le mode, le contexte et la révision comparés. Si la page termine la tâche, aucune modification visible n'est peut-être nécessaire. Si une fonction facultative devient instable, adaptez sa politique et sa reprise, pas la collecte ni une étiquette de visiteur. Notez aussi le repli visible, l'action restée possible et la durée de conservation afin que le support puisse comprendre le cas.

Le support peut séparer les preuves de configuration et celles de l'application. Les premières indiquent profil, mode, graine et version. Les secondes indiquent chargement, achèvement du travail et disponibilité du repli. Cette séparation évite qu'un nombre technique devienne un attribut de compte caché et permet un nouvel examen sans données client.

Le dispositif doit également vérifier l'annulation et la navigation. Une opération récursive devenue inutile doit s'arrêter lorsque la personne quitte la vue, et un worker fermé ne doit pas programmer de travail. Ce sont des tests de cycle de vie qui limitent les ressources et permettent d'abandonner l'option sans bloquer les contrôles nécessaires.

L'accessibilité fait partie du même examen. Un message signalant un worker indisponible doit atteindre les technologies d'assistance, et le repli doit garder le clavier, un texte lisible et l'action essentielle. Une mesure technique ne remplace pas une expérience accessible. Enregistrer la politique et le résultat visible permet d'améliorer l'état sans conserver le nombre sous-jacent.

Avant de changer une politique, comparez les causes ordinaires : version, lancement du worker, fonction modifiée, sécurité ou hôte. Le nombre ne les distingue pas. Une courte liste avec un dispositif nommé et un repli limité vaut mieux qu'un échantillonnage permanent. Une fois le flux correct, cessez de recueillir la valeur et gardez seulement la décision de support.

Ces pratiques donnent à la profondeur un rôle étroit et défendable. Elle aide à examiner la cohérence d'un profil dans les contextes possédés, tandis que l'application prend en charge résilience, confidentialité et accessibilité. La limite est testable : configurer délibérément, mesurer le nécessaire et garder l'expérience complète lorsque le signal change.

Le compte rendu doit avoir une durée de conservation claire. Gardez le profil, la version, la révision du scénario, le contexte et le résultat visible tant que la question de compatibilité reste ouverte. Supprimez le nombre brut lorsqu'il ne guide plus une décision et inscrivez le comportement de repli dans l'acceptation. L'observation reste ainsi liée à une tâche technique temporaire plutôt qu'à un compte.

Tant que le cas reste ouvert, le registre peut conserver retentionDays, fallback, outcome, release et fixtureRevision, puis supprimer le nombre brut.

Sources publiques

• Documentation BotBrowser sur la profondeur de pile
• Vue d'ensemble des empreintes BotBrowser
• Référence des options CLI BotBrowser
• MDN : erreur de récursion excessive

Conclusion pratique

Choisissez le mode selon la question de revue et n'utilisez pas le chiffre comme autorisation, preuve de fraude ou indice de localisation. Quand un résultat change, comparez la version du navigateur, le chemin de démarrage du Worker, la révision du fixture et l'hôte avant de modifier la politique du profil, et gardez le chemin de repli opérationnel. Ne conservez le chiffre brut que tant que la question de compatibilité reste ouverte.