Congelar cadenas de agente de usuario

Ha habido noticias sobre Chrome congelando su cadena User-Agent (y todos los demás navegadores principales están a bordo). Eso significa que todavía tendrán una cadena de Agente de usuario (UA) (que aparece en los encabezados y está disponible en JavaScript como navigator.userAgent. Al congelarla, será menos útil con el tiempo para detectar el navegador/plataforma/versión, aunque el La razón citada para hacerlo tiene más que ver con la privacidad y detener las huellas digitales que con las preocupaciones de los desarrolladores.

En el mundo del front-end, el consejo general es: no deberías rastrear UA . El principal problema es que muchos sitios se equivocan y los cambios que realizan con esa información terminan perjudicando más de lo que ayudan. Y el consejo general para evitarlo es: en su lugar, debes realizar pruebas basadas en la realidad de lo que estás tratando de hacer .

¿Está intentando probar si un navegador admite una función en particular? Luego pruebe esa característica , en lugar de la idea abstracta de un navegador en particular que se supone que admite esa característica.

En JavaScript, a veces las funciones son muy fáciles de probar porque se prueba la presencia de sus API:

  if (navigator.geolocation) {    navigator.geolocation.getCurrentPosition(showPosition);  } else {    console.warn("Geolocation not supported");  }

En CSS, tenemos un mecanismo nativo a través de @supports:

@supports (display: grid) {  .main {    display: grid;  }}

Esto se expone en JavaScript a través de una API que devuelve una respuesta booleana:

CSS.supports("display: flex");

No todo en la plataforma web es tan fácil de probar, pero generalmente es posible sin realizar un rastreo de UA. Si se encuentra en una posición difícil, siempre vale la pena verificar si Modernizr tiene una prueba para ello, que es una especie de estándar de oro para las pruebas de funciones, ya que es probable que haya sido probado en batalla y haya manejado casos extremos en un de una manera que quizás no hayas previsto. Si realmente usa la biblioteca, obtendrá cortes lógicos claros:

if (Modernizr.requestanimationframe) {  // supported} else {  // not-supported}

¿Qué pasa si realmente necesita saber el tipo, la plataforma y la versión del navegador? Bueno, aparentemente esa información aún es posible obtenerla a través de algo nuevo llamado User-Agent Client Hints (UA-CH).

¿Quieres conocer la plataforma? Estableces un encabezado en la solicitud llamada Sec-CH-Platformy, en teoría, obtendrás esa información en la respuesta. Básicamente, debes solicitarlo, lo que aparentemente es suficiente para evitar las problemáticas cuestiones de privacidad de las huellas dactilares. Parece que Sec-CH-Mobiletambién hay encabezados para dispositivos móviles, lo cual es un poco curioso. ¿Quién decide qué es un dispositivo “móvil”? ¿Qué decisiones se espera que tomemos con eso?

Con frecuencia también es deseable conocer información sobre el navegador, la plataforma y la versión a nivel del servidor (enviar código diferente en diferentes situaciones), tanto como en el lado del cliente, pero sin el beneficio de poder realizar pruebas . Presumiblemente, las cadenas de UA congeladas serán útiles durante el tiempo suficiente para que las situaciones del lado del servidor puedan transferirse al uso de UA-CH.

Jon Arne Sæterås está nervioso :

Profesionalmente, he estado involucrado en el espacio web móvil y he visto su desarrollo durante más de 15 años y sé que muchos sitios web, grandes y pequeños, dependen de la detección de dispositivos basada en el User-Agentencabezado. Desde la perspectiva de Google, puede parecer fácil cambiar a la alternativa UA-CH, pero aquí es donde el equipo que impulsa este cambio no comprende el impacto:

La funcionalidad basada en la detección de dispositivos es crítica, está muy extendida y no solo en el código frontal. Enormes sistemas de software con código backend dependen de la detección de dispositivos, así como de pilas de infraestructura completas.

En mi base de código más importante, hacemos una pizca de detección de UA del lado del servidor. Usamos una gema Rails llamada Browser que expone información derivada de UA en una API agradable. Puedo escribir:

if browser.safari?end

También exponemos información de esa gema en el lado del cliente para que también pueda usarse allí. Solo hay un puñado de casos de uso tanto para el anverso como para el reverso, ninguno de los cuales parece particularmente difícil de manejar de otra manera.

En el pasado, ha sido un poco complicado transmitir información del front-end al servidor de tal manera que sea útil en la carga de la primera página (ya que la UA no sabe cosas como el tamaño de la ventana gráfica). Recuerdo un baile bastante elegante que hice donde cargué una página esqueleto que ejecuta un poquito de JavaScript que hacía cosas como medir el ancho de la ventana gráfica y el tamaño de la pantalla, luego establecía una cookie y actualizaba a la fuerza la página. Si la cookie estaba presente, el servidor tenía lo que necesitaba y no cargó la página principal en esas solicitudes.

Es algo complicado, pero luego el servidor tiene información sobre el ancho de la ventana gráfica en el lado del servidor, lo cual es útil para cosas como enviar activos de pantalla pequeña (por ejemplo, HTML diferente), que de otro modo sería imposible.

Menciono esto porque las cosas de UA-CH no deben confundirse con las sugerencias de cliente habituales . Se supone que debemos poder configurar nuestros servidores para enviar un Accept-CHencabezado y luego tener nuestro código del lado del cliente en la lista blanca para enviarlo de vuelta, como:

meta http-equiv="Accept-CH" content="DPR, Viewport-Width"

Eso significa que un servidor puede tener información del cliente sobre estas cosas en cargas de página posteriores . Es una buena API, pero Firefox y Safari no la admiten . Me pregunto si habrá un aumento si ambos navegadores muestran interés en UA-CH debido a esta cadena de UA congelada.