Descomprimiendo la nueva especificación «peligrosa» de integridad del entorno web de Google

Lea este artículo en 日本語, español.

A Google parece encantarle crear especificaciones que son terribles para la web abierta y parece que encuentran una manera de crear una nueva cada pocos meses. Esta vez, nos hemos topado con cierta controversia causada por una nueva especificación de integridad del entorno web en la que Google parece estar trabajando.

​En este momento, no pude encontrar ningún mensaje oficial de Google sobre esta especificación, por lo que puede ser solo el trabajo de algún ingeniero equivocado de la compañía que no cuenta con el respaldo de superiores, pero parece ser un trabajo que ha continuado. durante más de un año, y la especificación resultante es tan tóxica para la Web abierta que, en este punto, Google necesita al menos dar alguna explicación de cómo pudo llegar tan lejos.

¿Qué es la integridad del entorno web? Es simplemente peligroso.

La especificación en cuestión, que se describe en https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md, se llama Web Environment Integrity. La idea es tan simple como peligrosa. Proporcionaría a los sitios web una API que les indicaría si un tercero autorizado (llamado certificador) confía en el navegador y la plataforma en la que se está ejecutando actualmente. Los detalles son confusos, pero el objetivo parece ser evitar interacciones «falsas» con sitios web de todo tipo. Si bien esto parece una motivación noble, y los casos de uso enumerados parecen muy razonables, la solución propuesta es absolutamente terrible y ya ha sido equiparada con DRM para sitios web, con todo lo que implica.

​También es interesante observar que el primer caso de uso enumerado tiene que ver con garantizar que las interacciones con los anuncios sean genuinas. Si bien esto no es problemático en la superficie, ciertamente sugiere la idea de que Google está dispuesto a utilizar cualquier medio para reforzar su plataforma publicitaria, independientemente del daño potencial para los usuarios de la web.

​A pesar de que el texto menciona el increíble riesgo de excluir proveedores (léase, otros navegadores), solo hace un tibio intento de abordar el problema y termina sin ninguna solución real.

Entonces, ¿cuál es el problema?

Simplemente, si una entidad tiene el poder de decidir qué navegadores son confiables y cuáles no, no hay garantía de que confiará en un navegador determinado. Por defecto, no se confiará en ningún navegador nuevo hasta que haya demostrado de alguna manera que es digno de confianza, a discreción de los verificadores. Además, cualquier persona que se quede atascada ejecutando software heredado donde esta especificación no sea compatible eventualmente será excluido de la web.

​Para empeorar las cosas, el principal ejemplo dado de un certificador es Google Play en Android. Esto significa que Google decide qué navegador es confiable en su propia plataforma. No veo cómo se puede esperar que sean imparciales.

En Windows, probablemente ceden ante Microsoft a través de la Tienda Windows, y en Mac, ceden ante Apple. Por lo tanto, podemos esperar que al menos se confíe en Edge y Safari. Cualquier otro navegador quedará en manos de esas tres empresas.

Por supuesto, puedes notar una omisión flagrante en el párrafo anterior. ¿Qué pasa con Linux? Bueno, esa es la gran pregunta. ¿Linux quedará completamente excluido de la navegación web? ¿O Canonical se convertirá en el que decida al controlar los repositorios de paquetes de instantáneas? Quién sabe. Pero no pinta bien para Linux.

Esto por sí solo ya sería bastante malo, pero empeora. La especificación insinúa claramente que un objetivo es garantizar que personas reales interactúen con el sitio web. No aclara de ninguna manera cómo pretende hacerlo, por lo que nos quedan algunas preguntas importantes sobre cómo lo logrará.

¿Se utilizarán datos de comportamiento para ver si el usuario se comporta de forma humana? ¿Se presentarán estos datos a los certificantes? ¿Las herramientas de accesibilidad que dependen de la automatización de la entrada al navegador harán que éste deje de ser confiable? ¿Afectará a las extensiones? Actualmente, la especificación especifica una excepción para las modificaciones y extensiones del navegador, pero esto puede hacer que la automatización de las interacciones con un sitio web sea trivial. Por lo tanto, o la especificación es inútil o eventualmente se aplicarán restricciones allí también. De lo contrario, sería trivial para un atacante pasar por alto todo el asunto.

¿Podemos simplemente negarnos a implementarlo?

Desafortunadamente, esta vez no es tan sencillo. Cualquier navegador que opte por no implementar esto no será confiable y cualquier sitio web que opte por utilizar esta API podría, por lo tanto, rechazar a los usuarios de esos navegadores. Google también tiene formas de impulsar la adopción por parte de los propios sitios web.

En primer lugar, pueden hacer que todas sus propiedades dependan fácilmente del uso de estas funciones, y no poder utilizar los sitios web de Google ya es una sentencia de muerte para la mayoría de los navegadores.

Además, podrían intentar exigir que los sitios que utilizan Google Ads también utilicen esta API, lo cual tiene sentido ya que el primer objetivo es evitar clics falsos en anuncios. Eso aseguraría rápidamente que cualquier navegador que no admita la API esté condenado.

Hay esperanza.

Existe una abrumadora probabilidad de que la legislación de la UE no permita que unas pocas empresas tengan un enorme poder para decidir qué navegadores están permitidos y cuáles no. No hay duda de que los atestiguadores estarían bajo una enorme presión para ser lo más justos posible.

Desafortunadamente, los mecanismos legislativos y judiciales tienden a ser lentos y no se puede decir cuánto daño se causará mientras los gobiernos y los jueces estén examinando esto. Si se permite que esto avance, será un momento difícil para la web abierta y podría afectar significativamente a los proveedores más pequeños.

Se sabe desde hace mucho tiempo que el dominio de Google en el mercado de navegadores web les da el potencial de convertirse en una amenaza existencial para la web. Con cada mala idea que han aportado, como FLOC, TOPIC y Client Hints, se han acercado más a hacer realidad ese potencial.

Web Environment Integrity es más de lo mismo, pero también un paso por encima del resto en la amenaza que representa, especialmente porque podría usarse para alentar a Microsoft y Apple a cooperar con Google para restringir la competencia tanto en el espacio de los navegadores como en el espacio de los sistemas operativos. Es imperativo que se les llame la atención sobre esto y se les impida seguir adelante.

Si bien nuestra vigilancia nos permite detectar y rechazar todos estos intentos de socavar la Web, la única solución a largo plazo es lograr que Google esté en igualdad de condiciones. La legislación ayuda en ese sentido, pero también lo hace la reducción de su cuota de mercado.

De manera similar, nuestra voz se fortalece para cada usuario de Vivaldi, lo que nos permite ser más efectivos en estas discusiones. Esperamos que los usuarios de la web se den cuenta de ello y elijan su navegador en consecuencia.

​La lucha para que la Web permanezca abierta será larga y hay mucho en juego. Luchemos juntos.

Novedades sobre el WEI de Google a 03.11.2023

Recién salido de la prensa, nos enteramos de que Google no continúa con su API de integridad web.

Esto es enormemente positivo para la neutralidad de la Web abierta. Aunque, por supuesto, dado que Google está tan impulsado por sus intereses más que por el beneficio de la Web en general, queda por ver (y sospechamos firmemente que no tomará mucho tiempo) con qué eligen reemplazarlo. ¿Están, por ejemplo, simplemente preparando una especificación aparentemente menos desagradable que en realidad es igual de dañina para los usuarios (como lo hicieron con FLOC y Topics)? También parece muy sospechoso que coincida con su reciente anuncio de pasar del pago por clic al pago por impresión para los anuncios.

En general, Google no ha demostrado ser un custodio confiable de la web y no podemos permitir que esta aparente victoria nos lleve a dormirnos en los laureles. Como siempre, una gran diversidad de navegadores y motores de búsqueda será crucial para contrarrestar cualquier intento futuro de una sola parte de dictar el futuro de la web.

​Última edición a las 11.10 horas del 11.03.2023.


Source link

About Carlos Carraveo Jimenez

Check Also

Los patrones de diseño Swift importantes para el desarrollo de aplicaciones iOS

¡Hola, compañeros entusiastas de iOS! Si se está sumergiendo en el mundo del desarrollo de …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *