Perfiles de navegador entre plataformas: una identidad en cada host

El trabajo con perfiles entre plataformas solo es comparable cuando se conservan juntos la identidad objetivo, la revisión del perfil, los parámetros de inicio y el registro del host. BotBrowser usa el perfil como fuente de identidad; no hace que todos los hosts o sitios se comporten igual.

TL;DR

Compara registros fijos entre hosts, aísla una versión o parámetro cambiado y trata una diferencia como decisión de lanzamiento, no como garantía del perfil.

Contenido

• Una cadena User-Agent no es una identidad
• Familias de señales que un perfil debe mantener alineadas
• Hosts, objetivos y la matriz de soporte documentada
• Compara hosts e investiga las diferencias
• Perfiles entre plataformas y operación Per-Context
• Qué cubre BotBrowser y dónde termina
• Conclusión

Una cadena User-Agent no es una identidad

La identidad del navegador es más que una cabecera. Un sitio web puede leer el nombre de la plataforma, la marca y la versión del navegador, las fuentes instaladas, el comportamiento gráfico, el tamaño de pantalla, las listas de idiomas, la zona horaria y las capacidades multimedia, y puede comparar esos valores entre sí. Un navegador que declara un User-Agent de Windows mientras sus fuentes, su pantalla y su comportamiento gráfico proceden de un servidor Linux ofrece una imagen mezclada. Esa mezcla es un riesgo de privacidad para quienes dependen del perfil y un problema de soporte para el equipo que debe explicar por qué el mismo flujo de trabajo se comporta de forma distinta en dos máquinas. BotBrowser puede mantener coherentes los valores de identidad de un perfil seleccionado entre sistemas operativos anfitriones; no puede cambiar cómo un sitio o un servidor tratan esa identidad.

La necesidad es práctica. Un equipo puede usar a la vez servidores Linux para escalar, estaciones macOS para desarrollar, equipos Windows para flujos de escritorio e identidades de destino Android para validar tráfico móvil. El personal de soporte tiene que reproducir el caso de un cliente sin montar un laboratorio de hardware, y QA necesita una base estable antes de aprobar un lanzamiento. Si la identidad del navegador sigue al host, cada uno de esos grupos ve algo ligeramente distinto. Si sigue al perfil, pueden comparar resultados con confianza.

Las User-Agent Client Hints aclaran el punto. MDN describe la API de User-Agent Client Hints como una forma de exponer información del navegador y de la plataforma mediante cabeceras de solicitud y de respuesta y una interfaz de JavaScript, con un conjunto pequeño de valores por defecto y más detalle solo cuando un servidor lo pide. Esos valores deben coincidir con la cadena User-Agent, entre sí y con el resto del perfil. Cambiar la cadena y dejar los valores estructurados en los valores del host crea justo el tipo de incoherencia que una identidad coherente debe evitar.

Por eso el perfil debe ser la fuente de la identidad. Un perfil es un archivo que recoge los valores de toda la identidad, de modo que el sistema operativo del host deja de ser la respuesta por defecto a cada pregunta que se le hace al navegador. La documentación de perfiles entre plataformas de BotBrowser describe el modelo así: las superficies de identidad provienen de los datos del perfil, incluidos el User-Agent, la pantalla, las fuentes, la GPU y la pila de idiomas, y las diferencias del host se limitan para que el perfil siga siendo la fuente principal.

Un caso concreto muestra lo que eso significa. Supón un perfil de destino Windows que se ejecuta en un servidor Linux. El nombre de la plataforma, los valores estructurados de marca, el conjunto de fuentes, las métricas de pantalla y la descripción de la GPU deben describir un equipo de escritorio Windows, aunque la máquina real sea un servidor Linux. Además, el flujo de trabajo debe comportarse al llegar a una página como lo haría en un destino Windows real. Si una sola familia sigue reflejando el host Linux, la identidad solo se aplica en parte, y esa es la brecha que una comparación entre hosts debe revelar.

Familias de señales que un perfil debe mantener alineadas

Conviene pensar en familias de señales y no en propiedades sueltas. Para la plataforma de destino elegida, un perfil debe mantener estas familias alineadas entre sí:

• Plataforma y marca del navegador: la cadena User-Agent, los valores estructurados de Client Hints y la marca declarada en las cabeceras deben nombrar la misma plataforma y la misma versión del navegador.
• Pantalla y métricas del dispositivo: la resolución, la profundidad de color, la densidad de píxeles y la compatibilidad táctil deben corresponder a la clase de dispositivo del destino, sea una pantalla de escritorio o un teléfono Android.
• Fuentes y renderizado de texto: el conjunto de fuentes instaladas y la forma de maquetar el texto deben seguir la plataforma de destino, incluido el texto de Asia oriental cuando corresponda.
• Comportamiento gráfico: la descripción de la GPU y el comportamiento de renderizado de canvas y WebGL deben mantenerse dentro de la clase de dispositivo que describe el perfil.
• Idioma, configuración regional y hora: las listas de idiomas, el formato regional y la zona horaria deben coincidir entre sí y con la región que el flujo de trabajo pretende representar.
• Capacidades multimedia y de almacenamiento: los códecs, la clase de memoria y valores similares deben ser verosímiles para el dispositivo de destino.

Familia	Registro	Desajuste
Identidad	userAgent, platform, brands	el destino difiere entre campos
Pantalla	screen.width, screen.height, devicePixelRatio	describe otra clase de dispositivo
Región	languages, locale, timeZone	nombra regiones incompatibles

La lista es un mapa de qué comparar. Cada familia se puede revisar a nivel general, comprobando si la página se comporta como se espera y si los valores en un host representativo coinciden con la base que tu equipo aprobó. No hace falta leer cada valor de bajo nivel para notar que un perfil de destino Windows declara una plataforma Linux o que un perfil de destino Android sigue mostrando una pantalla de escritorio.

La guía de MDN sobre User-Agent Client Hints muestra por qué la primera familia exige cuidado. Se envía por defecto un conjunto pequeño de valores, como la marca del navegador, el indicador de móvil y el nombre de la plataforma. Los valores más detallados, como la versión de la plataforma, la arquitectura y el modelo del dispositivo, solo se devuelven cuando un servidor los solicita. Un perfil coherente debe responder de forma consistente tanto a los valores por defecto como a los solicitados, para que la respuesta que recibe un sitio no dependa de qué pregunta hizo primero.

Las fuentes merecen una mención aparte porque vienen directamente del host mientras el perfil no tome el control. El artículo sobre coherencia de fuentes explica por qué el comportamiento de las fuentes debe seguir la plataforma de destino, y la documentación de renderizado de fuentes CJK describe la coherencia tipográfica de Asia oriental para los casos en que el texto chino, japonés o coreano se muestra distinto entre hosts.

Hosts, objetivos y la matriz de soporte documentada

Dos términos ayudan a planificar con claridad. El host es la máquina y el sistema operativo que ejecutan el navegador. El objetivo es la plataforma que describe el perfil. En un modelo dirigido por el perfil ambos pueden diferir a propósito: un perfil de destino Windows puede ejecutarse en un portátil macOS durante el desarrollo y en un servidor Linux en producción.

Elegir un objetivo es una decisión de producto, no de host. Decide qué plataforma debe representar el flujo de trabajo, elige el perfil correspondiente y después escoge los hosts por coste y comodidad. La documentación enumera las combinaciones admitidas, y cada objetivo de perfil es compatible con cada clase de host.

Objetivo del perfil	Host Windows	Host macOS	Host Linux (ENT Tier1)
Perfil Windows	Soportado	Soportado	Soportado
Perfil macOS	Soportado	Soportado	Soportado
Perfil Android	Soportado	Soportado	Soportado

Los demás requisitos son una instalación de BotBrowser en cada host y un archivo de perfil en formato .enc o .json. Los hosts Linux y Ubuntu requieren ENT Tier1. La documentación de Android Emulation describe los perfiles de destino Android como una capacidad de la licencia PRO, y el artículo sobre pruebas de perfiles Android muestra cómo se ejecuta un perfil de destino Android desde un host de escritorio o de servidor.

Los escenarios documentados siguen rutas de entrega habituales. Un equipo puede desarrollar en macOS y desplegar en Linux guardando un único archivo de perfil en el control de versiones o en un almacén de secretos y desplegándolo sin cambios. Un trabajo de CI puede ejecutar el mismo perfil en runners Windows, macOS y Linux y comparar resultados clave. Una flota puede pasar entre hosts en la nube sin regenerar los perfiles de identidad. En todos los casos solo cambia la ruta del ejecutable en el comando de inicio, mientras el archivo de perfil y los parámetros de inicio siguen siendo los mismos.

Trata el archivo de perfil como un artefacto de lanzamiento con versiones. Guárdalo en el control de versiones o en un almacén de secretos, asigna un identificador a cada revisión y regístralo cada vez que un host lo ejecute. La documentación de gestión de perfiles cubre el ciclo de vida y el versionado de los perfiles. Cuando todos los hosts leen el mismo archivo desde el mismo lugar, una diferencia en los resultados apunta al host o a los parámetros de inicio, y no a una copia perdida del perfil.

Compara hosts e investiga las diferencias

Una afirmación de coherencia solo es útil cuando hay evidencia que la respalde. La evidencia sale de una comparación controlada y sencilla durante pruebas autorizadas: mantén fijas las entradas, cambia solo el host y registra lo que ocurre.

1. Fija las entradas. Anota en el registro de la prueba la versión de BotBrowser, el archivo de perfil y los parámetros de inicio.
2. Elige hosts representativos. Usa al menos un host Windows, uno macOS y uno Linux que se parezca a producción, incluida su configuración de pantalla y de gráficos.
3. Ejecuta un flujo de trabajo autorizado que represente el trabajo real, desde el inicio hasta el estado de página esperado.
4. Compara las familias de señales amplias y el comportamiento de la página con la base de la versión: valores de plataforma, de pantalla, de idioma y hora, fuentes y renderizado.
5. Guarda juntas las capturas, las notas y la decisión aprobada para poder comparar el siguiente lanzamiento con este.

Anota por host hostOs, botBrowserVersion, profileRevision, launchFlags, displayMode y result. Windows 11, macOS 15 y Ubuntu 24.04 pueden compartir una profileRevision; un launchFlags distinto exige una comparación separada.

Anota lo que ves con palabras sencillas. «El flujo llegó al estado de página esperado, las capturas coincidieron con la base y los valores de plataforma, pantalla e idioma concordaron con el perfil» es un resultado útil. «Parecía bien» no lo es. Si el flujo es sensible a las condiciones de arranque o de renderizado, ejecútalo más de una vez y conserva todos los resultados.

Cada rol lee la misma comparación por motivos distintos. QA quiere saber si un candidato a lanzamiento coincide con la base aprobada. Soporte quiere reproducir el caso de un cliente en los hosts disponibles. Quien revisa la privacidad quiere confirmar que la identidad que presenta un flujo de trabajo es la que describe el perfil y no un efecto secundario de la máquina. Un único registro compartido sirve a los tres, siempre que las entradas se anoten antes de la primera ejecución.

Los hosts Linux necesitan una comprobación de preparación explícita. La documentación de Headless Server Setup describe la base de Linux, y la guía del backend de renderizado en Linux explica cómo la elección del backend de renderizado afecta al comportamiento gráfico y al coste de despliegue. Trata la configuración de pantalla y de renderizado como un requisito previo del lanzamiento y no como un detalle que se descubre después del despliegue.

El mismo método sirve para un trabajo de CI. La documentación sugiere ejecutar el perfil en runners Windows, macOS y Linux y comparar resultados clave, como valores de plataforma, idiomas, valores de pantalla y resultados de renderizado. Mantén la comparación a ese nivel. Una familia amplia coincide con la base o no coincide, y una discrepancia es un motivo para investigar antes del lanzamiento. Para un tratamiento más amplio de los registros de aceptación, la responsabilidad del despliegue y el coste en ejecución, lee cómo evaluar la coherencia del navegador entre plataformas antes del despliegue.

Cuando dos hosts discrepan, la primera pregunta es qué cambió. La guía de resolución de problemas para resultados distintos entre hosts es verificar la misma versión de BotBrowser, el mismo archivo de perfil y los mismos parámetros de inicio. Esas tres entradas explican la mayoría de las diferencias y son baratas de comprobar.

• Deriva de versión: un host ejecuta otra versión de BotBrowser.
• Deriva de perfil: se usó otro archivo de perfil, o una copia más antigua del mismo.
• Deriva de parámetros: los parámetros de inicio difieren entre un equipo de desarrollo y un runner de CI.
• Backend de renderizado: pueden aparecer diferencias relacionadas con la GPU en modo headless, y la documentación remite a la guía de Headless Server Setup y al ajuste del modo GPU.
• Fuentes y renderizado de texto: el texto de Asia oriental puede diferir entre hosts y tiene su propia guía.
• Host no compatible: un host Linux sin ENT Tier1 queda fuera de la matriz de soporte documentada.

Trata cada elemento como una hipótesis, cambia una variable cada vez y repite el mismo flujo de trabajo. Una diferencia entre hosts nunca es evidencia de que la identidad sea coherente. Es el registro de una discrepancia que aún necesita un responsable. Del mismo modo, una coincidencia en un host no se traslada automáticamente a una nueva imagen de host, a un nuevo paquete de perfil o a una nueva versión del navegador, así que repite la comparación cuando cambie alguno de ellos.

Decide de antemano cuándo parar. Un estado de página inesperado, un resultado de renderizado que impide trabajar, un resultado que nadie puede reproducir o un host al que le falta un requisito documentado son motivos para pausar el despliegue y volver a la última base aprobada. Marca un resultado poco claro como no concluyente en lugar de darlo por válido, y asígnale un responsable y una fecha para la siguiente comprobación. La incertidumbre explícita es más útil que la falsa confianza cuando de la respuesta depende una decisión de producción.

Una persona de soporte puede aplicar el mismo orden de preguntas a un informe de cliente: versión, perfil, parámetros, backend de renderizado y, por último, host. Seguir siempre el mismo orden hace comparables los resultados y acorta las investigaciones.

La región merece una nota aparte. El perfil aporta la identidad de plataforma, mientras que la zona horaria, la configuración regional y los idiomas de un flujo regional se pueden fijar de forma explícita con parámetros de inicio para que coincidan entre sí y con el perfil. Guarda esos valores en el registro de la prueba junto con el resto de las entradas, de modo que una ejecución posterior parta de la misma base regional. Cómo se comportan las fechas, las horas y las zonas horarias entre entornos se explica en Formato de fechas y portabilidad de zonas horarias.

Perfiles entre plataformas y operación Per-Context

Los equipos que necesitan muchas identidades suelen preguntar si deben iniciar un navegador por identidad. La documentación de Per-Context Fingerprint describe una alternativa: asignar un paquete de huella independiente a cada contexto de navegador dentro de una misma instancia, lo que reduce la sobrecarga y mantiene las cuentas separadas. Per-Context Fingerprint es una capacidad ENT Tier3.

Las dos ideas resuelven partes distintas de un mismo problema. Los perfiles entre plataformas mantienen una identidad ligada al perfil y no al host. La operación Per-Context permite que una instancia del navegador contenga varias de esas identidades, cada una con su propio perfil, sus valores de idioma y hora y sus métricas de pantalla. Según la documentación, los workers creados dentro de un contexto heredan la identidad de ese contexto.

La documentación también indica que los parámetros que determinan la identidad deben fijarse antes de crear la primera página o worker de un contexto, porque esa primera página o worker fija la identidad del contexto. Planifica el orden de las operaciones en consecuencia y valida cada contexto con la misma comparación entre hosts que usas para un perfil individual. La capacidad depende del host, de la carga de trabajo y del plan, así que mídela en los hosts que pretendes operar.

Antes de la primera página, asocia la profileRevision y una etiqueta como retailer-de-desktop al contexto. Conserva junto a ella locale, timeZone y la etiqueta de ruta para comparar ese contexto en otro host.

La operación Per-Context no cambia el hábito de validar. Valida un conjunto representativo de contextos en cada clase de host, anota qué perfil usó cada uno y compara las mismas familias amplias. Si un contexto usa un perfil de destino Android en un host de escritorio, revísalo con las comprobaciones de Android y no con las de escritorio. Llevar los registros por contexto también facilita ver si una diferencia pertenece a una identidad o a todo el host.

Qué cubre BotBrowser y dónde termina

BotBrowser puede mantener el perfil elegido como fuente del User-Agent, la pantalla, las fuentes, la GPU y la pila de idiomas, de modo que un mismo archivo de perfil se ejecute en hosts Windows, macOS y Linux compatibles y tu equipo pueda comparar los resultados entre esos hosts con la misma versión y los mismos parámetros de inicio. Así, quien aprueba un lanzamiento dispone de una base compartida que revisar en lugar de un resultado por máquina. BotBrowser no puede garantizar resultados idénticos en todos los hosts ni sitios, no sustituye la validación en hosts representativos y no controla cómo un sitio web interpreta las señales del navegador. Los hosts Linux requieren además ENT Tier1.

Usa ese límite al redactar el plan de despliegue. Indica qué hosts y objetivos validaste, qué versión, perfil y parámetros usaste y qué resultados revisaste. Describe como no probado todo lo que quede fuera de ese conjunto. Un registro de aceptación breve y exacto es más útil para la siguiente persona que opere el sistema que una promesa amplia.

Revisa el plan cuando cambien las fuentes. La matriz de soporte, los requisitos de Per-Context y la guía de Client Hints las mantienen sus responsables, así que vuelve a comprobar las fuentes que aparecen abajo antes de actualizar afirmaciones sobre hosts compatibles o identidad en un documento de despliegue.

Conclusión

Mantén una revisión de perfil y un registro de inicio por cada host comparado. Una versión, conjunto de parámetros, ruta, configuración regional o modo de pantalla distinto cambia la entrada de comparación; regístralo antes de decidir un lanzamiento.

Fuentes

• Documentación de perfiles entre plataformas de BotBrowser
• MDN: User-Agent Client Hints API
• Documentación de Per-Context Fingerprint de BotBrowser