Profundidad de pila de JavaScript: una señal de privacidad

Este artículo trata de la profundidad de pila, la medición que muestra cuánta recursión soporta un contexto de JavaScript antes de fallar. BotBrowser ofrece un ajuste de profundidad dentro de su límite de soporte; un envoltorio puede informar el resultado, pero no iguala contextos o versiones distintas.

Resumen rápido

Ejecuta el mismo fixture de recursión acotada en el contexto principal y en un Worker, y registra la compilación del navegador junto con el resultado. Un cambio entre ejecuciones es una diferencia de contexto o de versión hasta que se demuestre lo contrario.

Contenido de esta guía

• Qué representa la medición
• Por qué importan el contexto y la versión
• Límite de soporte de BotBrowser
• Cómo elegir un modo para una revisión
• Revisión reproducible de la aplicación
• Leer un conteo que cambió
• Límites y decisiones de privacidad

La recursión de JavaScript tiene un límite práctico. Cuando una función se llama continuamente, el navegador detiene las llamadas y comunica un desbordamiento de pila, normalmente como RangeError. El número de llamadas exitosas antes del error es un comportamiento observable. La plataforma web no define un valor único, por lo que puede cambiar entre implementaciones, versiones, sistemas operativos y contextos. BotBrowser puede ejecutar una comprobación de profundidad de pila en un contexto aislado y controlado con un mismo perfil; no puede hacer que la profundidad sea idéntica entre otras compilaciones, plataformas o motores JavaScript.

La diferencia importa para la privacidad porque una página puede ejecutar una prueba recursiva pequeña y guardar el resultado como una entrada de la huella del navegador. El número no es un nombre, una credencial ni una prueba de ubicación. Es una señal técnica de poca capacidad que puede aportar una separación modesta junto con otras observaciones. Tratarla como una señal evita convertir un detalle de compatibilidad en una afirmación de identidad.

La pregunta útil para un equipo no es cómo reunir un perfil mayor, sino cómo mantener predecible la aplicación cuando cambia el valor y cómo elegir una configuración coherente con el perfil revisado. Una aplicación con alternativa debe continuar cuando la prueba no está disponible, es incierta o difiere de otra sesión. Ninguna tarea visible debe depender de un número concreto.

Qué representa la medición

Cada llamada JavaScript añade un marco a la pila. El marco guarda información de retorno y estado, mientras el navegador gestiona la memoria y las comprobaciones de seguridad. La forma del marco importa: una función pequeña puede alcanzar otro número que una función con más parámetros o valores locales. La medición describe la prueba y el contexto donde se ejecutó. Comparar números solo sirve si la forma de la prueba y el estado de la página se mantienen estables.

El error final protege la página contra la recursión sin límite. Capturarlo permite terminar la comprobación, pero no mueve el límite. JavaScript no puede pedir una pila nativa mayor para un hilo existente ni reescribir la contabilidad de la pila. Un script puede no ejecutar la prueba, pero esa decisión no cambia lo que otra página observa en su contexto.

La reserva de pila del sistema operativo es un factor, no el único. Las implementaciones usan diseños de marcos, márgenes de seguridad, rutas de optimización y preparaciones de contexto diferentes. Una actualización puede cambiar cualquiera de esos detalles. Un equipo con mucha memoria libre aún puede producir otro resultado porque el límite es una política de ejecución, no una medición de memoria disponible.

La ventana principal y un worker no empiezan necesariamente con las mismas condiciones. Los workers dedicados y compartidos tienen su propia preparación, y WebAssembly sigue reglas propias. Una comparación debe registrar el contexto y la forma de la prueba. El resultado del hilo principal no es una promesa sobre un worker ni debe clasificar un dispositivo.

Por qué importan el contexto y la versión

Una página puede observar un valor estable durante una sesión, pero estabilidad no significa permanencia. Versiones del navegador, actualizaciones del sistema, ajustes de seguridad y cambios del código pueden alterar el número. Un cambio pequeño en la función recursiva también cuenta. Por eso un valor histórico es evidencia débil y el soporte debe registrar la versión y la revisión de la prueba.

La señal sirve mejor como comprobación de coherencia dentro de una prueba propia. El equipo puede comparar el resultado principal con el de un worker que la aplicación usa. Así la prueba responde si el perfil seleccionado funciona para esa aplicación. No debe identificar a un visitante, deducir su hardware ni decidir acceso usando el número.

La guía de huellas de MIME y códecs sirve como complemento cuando la revisión también prueba capacidades multimedia; mantenga esa observación separada del contador de recursión.

Un servicio respetuoso mantiene el resultado junto a la decisión que lo necesita. Si solo hace falta decidir si una función opcional de recursión profunda es segura, puede usar una política local y descartar el número. En un caso de soporte, guarde la revisión, la versión y la política elegida, no el número en un identificador de cuenta. Así es más fácil borrarlo y menos útil como etiqueta entre sesiones.

Para comparar de forma concreta, registre browserVersion, profileId, fixtureRevision, context y el RangeError capturado; esos campos explican el cambio sin guardar un identificador del visitante.

La misma frontera vale para los análisis. Un panel puede informar que se usó la ruta básica o reducida, sin ordenar a las personas por profundidad. Resultados agregados de finalización, cancelación y recuperación describen mejor la experiencia. El contenido y los controles necesarios deben seguir disponibles cuando falta la medición.

Límite de soporte de BotBrowser

BotBrowser ofrece --bot-stack-seed para elegir cómo se deriva el límite de recursión observable para un perfil. profile usa la profundidad asociada al perfil elegido. real conserva el resultado nativo del host. Una semilla entera solicita una variación determinista, de modo que el mismo perfil y semilla sirven como entrada repetible. Son opciones de configuración admitidas, no una promesa de un número fijo para cada aplicación.

La opción busca alinear la señal observable con el perfil revisado. Puede aplicar el comportamiento elegido al hilo principal, Web Workers y contextos WebAssembly que admite el producto. El equipo debe medir cada contexto de su aplicación porque las condiciones difieren. Un perfil no sustituye una prueba de compatibilidad, y un resultado no demuestra la identidad de una persona.

BotBrowser no cambia la reserva nativa del sistema ni elimina las restricciones generales de memoria. El comportamiento seleccionado se refiere al límite que observa la página, no al uso normal de la pila de la aplicación. El código habitual debe quedar lejos del límite, pero una aplicación con recursión profunda necesita sus propias pruebas de rendimiento, errores y recursos.

BotBrowser tampoco sabe si una página de terceros ejecuta una comprobación. Puede proporcionar el comportamiento configurado, pero no puede hacer que la página olvide el valor, decidir cómo lo guarda ni reemplazar su política de privacidad. La respuesta adecuada es minimizar la recopilación, explicar los diagnósticos opcionales y conservar una ruta básica.

Cómo elegir un modo para una revisión

Use profile para revisar una aplicación contra el comportamiento guardado para un perfil. Es útil al comprobar que las superficies relacionadas permanecen coherentes en una revisión de regresión. Registre juntos versión, perfil y revisión de la prueba para separar un cambio de configuración de un cambio de página.

Use real cuando la prueba debe describir el host que ejecuta el navegador. Sirve para depuración, capacidad o un informe que representa esa máquina. No vuelve portátil el resultado ni indica que el host represente todos los entornos admitidos.

Use una semilla entera cuando necesite una variación repetible sin escribir una profundidad manual. La semilla es una entrada de configuración, no un identificador que la página deba mostrar. Guárdela con el perfil y la versión en un registro controlado; no la ponga en cuentas, URL ni análisis. Semillas distintas pueden dar resultados distintos, así que compare solo entradas con los mismos datos declarados.

No elija un modo para forzar un número arbitrario. Un valor extremo o no documentado puede hacer que la señal contradiga otras superficies y ocultar un defecto. La pregunta segura es si perfil y versión producen un resultado razonable y repetible en los contextos propios. Si un trabajo necesita más espacio, valídelo por separado con el modo nativo y supervisión de recursos.

Revisión reproducible de la aplicación

Comience con un accesorio pequeño que ejecute una función recursiva acotada y capture el desbordamiento esperado. Registre solo el número necesario, el contexto y la versión. Ejecútelo primero en la ventana principal y después en cada worker que la aplicación utilice. No enumere propiedades ajenas ni envíe un inventario técnico al servidor.

Repita el accesorio con el mismo perfil y semilla tras iniciar el navegador de nuevo. Un resultado repetible indica una configuración coherente, pero no es una garantía de producción. Si cambia, revise la ruta del perfil, la versión, la preparación del worker y la revisión del accesorio. Un paquete de página distinto puede cambiar la forma de los marcos.

Revise el camino de fallo igual que el de éxito. Si la recursión no está disponible, aparece un error inesperado o el worker no inicia, la aplicación debe conservar el contenido necesario y mostrar una alternativa comprensible. Las mejoras opcionales pueden aplazarse, mientras navegación, controles de cuenta y estado accesible siguen utilizables. Esto importa más que el número.

En una revisión entre hosts, compare primero las entradas declaradas. El mismo nombre de perfil no basta si difieren versión, opciones, código o contexto. Mantenga un registro corto: identificador del perfil, modo, tipo de semilla, versión, contexto, política y resultado. No conserve una descripción de hardware solo porque apareció un valor técnico.

La visión general de huellas del navegador explica cómo se combinan señales pequeñas. La guía de propiedades Navigator separa una propiedad reportada de una identidad. Compare la guía de integridad de API del navegador cuando el accesorio se ejecuta en varios contextos. Son referencias de contexto, no un identificador independiente.

La fila de revisión debe indicar profile, real o una seed entera, y marcar page, Worker y WebAssembly como contextos medidos.

Leer un conteo que cambió

Qué cambió entre dos ejecuciones	Qué suele significar	Siguiente comprobación
Solo la versión del navegador	Cambió el diseño de marco o el margen	Repetir una vez en la versión anterior
Solo la función del accesorio	Cambió la forma del marco, no el navegador	Congelar la revisión del accesorio y comparar
Solo el contexto	Hilo principal y worker nunca compartieron límite	Comparar cada contexto con su propio historial
Todo, en una misma máquina	Un flag o una ruta de perfil no se aplicó	Imprimir la línea de comandos efectiva

Un conteo que cambia tiene cuatro explicaciones corrientes, y el conteo no las distingue. Dos ejecuciones que difieren en una sola de esas variables responden una pregunta; dos que difieren en varias no responden nada. Anote las cuatro entradas y cambie solo una.

Fije primero el accesorio. Guarde la función recursiva como archivo versionado e imprima su revisión junto al resultado, porque otro número de parámetros, otro cierre o un bloque try añadido cambian la forma del marco y por tanto la profundidad. Un accesorio que derivó es la causa más común de una «regresión» que en realidad es una edición de página.

Después fije la versión. Compare la cadena de compilación completa, no solo la versión mayor, porque el límite es una política de ejecución que se mueve con el endurecimiento de seguridad y la generación de código. Cuando solo se movió la versión, repetir una vez en la compilación anterior separa un cambio real del ruido entre ejecuciones, cosa que repetir la compilación nueva no consigue.

En tercer lugar, compare cada contexto consigo mismo. Un número del hilo principal y otro de un worker nunca debían coincidir, y un par de valores redondeados no dice nada sobre si alguno de los dos contextos es estable. Registre cada contexto por separado en dos ejecuciones de la misma compilación.

Si las tres entradas eran idénticas y el número aún se movió, imprima la línea de comandos efectiva antes de culpar al navegador. Un flag que aparece en el script de lanzamiento pero no en los argumentos del proceso, o una ruta de perfil que resolvió a otro archivo en un segundo shell, producen un cambio que parece una diferencia de navegador y no lo es.

Un registro corto hace esto comprobable después:

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

Dos archivos con esa forma, tomados con una versión de diferencia, bastan para decir cuál de las cuatro explicaciones aplica. Un número suelto copiado de la consola, no.

Límites y decisiones de privacidad

La profundidad tiene entropía limitada y es evidencia auxiliar. Cambia con la forma del código y el entorno, y no identifica por sí sola un navegador, dispositivo o persona. Guardarla sin límite puede costar más privacidad que valor. Prefiera una decisión temporal, un plazo claro y borrado al terminar el caso.

No use el número para autorización, prueba de fraude, ubicación o seguridad de cuenta. No indica si un visitante es confiable ni demuestra que dos sesiones pertenezcan a la misma persona. Autenticación, límites de velocidad y abuso necesitan evidencia propia del servidor.

No prometa comportamiento idéntico en todas las familias, sistemas, workers o runtimes WebAssembly. La documentación pública describe el alcance y las pruebas de compatibilidad establecen el soporte real. Si una versión cambia el resultado, actualice el registro e investigue el efecto visible antes de cambiar una política.

Una nota de soporte clara debe decir ambos lados: BotBrowser puede seleccionar comportamiento de perfil, nativo o semilla en contextos admitidos, pero no cambia la reserva del host, garantiza el resultado de la aplicación ni controla lo que registra una página de terceros. La acción práctica es probar el flujo propio, conservar la alternativa y guardar solo la evidencia necesaria.

Describe un cambio de resultado como observación de compatibilidad, no como categoría de identidad. Indica versión, modo, contexto y revisión comparados. Si la página completa la tarea, quizá no haga falta cambiar nada visible. Si una función opcional falla, cambia su política y recuperación, no la recopilación ni una etiqueta de visitante. Añade la alternativa visible, la acción que siguió disponible y el plazo de conservación, para que soporte pueda entender el caso y comprobar el resultado de la tarea.

El equipo de soporte puede separar evidencia de configuración y de aplicación. La primera enumera perfil, modo, semilla y versión. La segunda indica carga, finalización del trabajo y disponibilidad de la alternativa. Separarlas evita que un número técnico se convierta en un atributo oculto y permite repetir la investigación sin datos del cliente.

El accesorio también debe probar cancelación y navegación. Una operación recursiva innecesaria debe parar al salir de la vista, y un worker cerrado no debe programar más trabajo. Son pruebas de ciclo de vida que limitan el consumo y dejan que la página abandone lo opcional sin bloquear controles esenciales.

La accesibilidad pertenece a la misma revisión. Los mensajes sobre un worker no disponible deben llegar a la tecnología de asistencia, y la alternativa debe conservar teclado, texto legible y la acción principal. Una medición técnica no sustituye una experiencia accesible. Registrar política y resultado visible permite mejorarla sin guardar el número subyacente.

Antes de cambiar la política, compare causas ordinarias: versión, inicio del worker, función modificada, seguridad o host. El número no distingue esas causas. Una lista corta con accesorio nombrado y alternativa acotada es más fiable que muestrear sin fin. Cuando el flujo propio funciona, deje de recoger el valor y conserve solo la decisión de soporte.

Estas prácticas dan a la profundidad un papel estrecho y defendible. Ayuda a revisar la coherencia de un perfil en contextos propios, mientras el diseño de la aplicación cuida resiliencia, privacidad y accesibilidad. El límite es comprobable: configure con intención, mida solo lo necesario y mantenga completa la experiencia cuando cambie la señal.

El registro de la revisión debe tener una caducidad clara. Conserva el perfil, la versión, la revisión del accesorio, el contexto y el resultado visible mientras siga abierta la cuestión de compatibilidad. Elimina el número bruto cuando ya no sirva para decidir y anota la alternativa en la aceptación. Así la observación técnica queda ligada a una tarea temporal y no a una cuenta.

Mientras el caso está abierto, el registro puede conservar retentionDays, fallback, outcome, release y fixtureRevision; después debe eliminar el número bruto.

Fuentes públicas

• Documentación de profundidad de pila de BotBrowser
• Visión general de huellas de BotBrowser
• Referencia de indicadores CLI de BotBrowser
• MDN: error de recursión excesiva

Conclusión práctica

Elige el modo según la pregunta de revisión y no uses la cifra como autorización, prueba de fraude ni evidencia de ubicación. Cuando cambie un resultado, compara la versión del navegador, la ruta de arranque del Worker, la revisión del fixture y el host antes de modificar la política del perfil, y mantén operativa la ruta de reserva. Conserva la cifra bruta solo mientras la cuestión de compatibilidad siga abierta.