El próximo Manifest V3 para extensiones de Google Chrome cambiará el funcionamiento de los bloqueadores de anuncios en Chrome. ¿Es este el camino correcto para los bloqueadores de anuncios y Google?
Google Chrome es el navegador web multiplataforma más popular disponible en el mercado en este momento, reclamando el 62,7% del uso global del navegador hasta mayo de 2019, con Safari de Apple en segundo lugar con un 15,89% y Firefox de Mozilla con un 5,07%. Por su mayor parte, los cambios más pequeños que Google Chrome realiza en su plataforma acaban afectando a millones de usuarios en todo el mundo. Entonces, cuando Google anunció la próxima versión del manifiesto de extensiones en forma de Manifest V3 para Extensiones de Google Chrome, sabíamos que Se esperaban grandes cambios, especialmente cuando salió a la luz que Google estaba creando una API de bloqueo de contenido dentro de Chrome. sí mismo.
¿Qué es el Manifiesto V3?
Si eres un usuario activo de Chrome, sin duda utilizas algunas extensiones. Las extensiones son pequeños programas de software que personalizan la experiencia de navegación utilizando el
Desde a finales del año pasado, Google ha estado trabajando en "Manifest V3", un conjunto de cambios propuestos para la plataforma Chrome Extensions que pueden clasificarse como "cambios importantes". como el documento de discusión pública para Manifest V3 afirma, la versión del manifiesto de extensión es un mecanismo para restringir ciertas capacidades a una determinada clase de extensiones. Estas restricciones pueden adoptar la forma de una versión mínima o una versión máxima. Restringir a una versión mínima permite que las API o capacidades más nuevas solo estén disponibles para extensiones más nuevas. mientras que restringir a una versión máxima del manifiesto permite que las API o capacidades más antiguas se eliminen gradualmente obsoleto.
En términos más simples, una nueva versión del manifiesto permite a Chrome restringir las API y las funciones a esta nueva versión del manifiesto, en para obligar a los desarrolladores de extensiones a migrar de ciertas API más antiguas debido a su impacto negativo en el usuario experiencia. En teoría, la implementación de una extensión en Manifest V3 debería proporcionar garantías más sólidas desde las perspectivas de seguridad, privacidad y rendimiento.
Si bien hay una amplia gama de cambios descritos en Manifest V3, el cambio más controvertido se relaciona con la decisión de Google de limitar las capacidades de bloqueo presentes en el manifiesto existente. chrome.webSolicitud API (y centrar la API en la observación en lugar del bloqueo) y luego presentar estas capacidades de bloqueo a través de una nueva chrome.declarativeNetRequest API. Este cambio en particular ha enardeció a la comunidad ya que termina apuntando al mecanismo de bloqueo de anuncios de la famosa extensión de bloqueo de anuncios, Origen del uBloquey afecta directamente a sus más de 10 millones de usuarios.
Antes de abordar este tema, echemos un vistazo a cómo solicitud web API se compara con declarativaNetRequest API.
API de solicitud web y API de solicitud de red declarativa
El presente
La descripción oficial de Web Request describe la API de la siguiente manera:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Con Web Request, Chrome envía todo los datos en una solicitud de red a la extensión que los escucha. Luego, la extensión tiene la oportunidad de evaluar la solicitud e indicarle a Chrome qué hacer con la solicitud: permitirla, bloquearla o enviarla con algunas modificaciones.
Siga la secuencia de eventos para comprender qué sucede cuando las extensiones usan la API de solicitud web. Cuando un usuario con una extensión Web Request instalada hace clic en un enlace, Chrome informa a la extensión que se ha realizado una solicitud de datos antes de que la solicitud llegue al servidor. La extensión puede optar por modificar la solicitud en esta etapa. Luego, el servidor responde, pero la respuesta vuelve a pasar por la extensión, y la extensión puede dictar si es necesario modificar la respuesta. Luego, Chrome finalmente muestra la página y el usuario puede ver el resultado de su acción de hacer clic.
Mientras Chrome entrega todos los datos en una solicitud de red, las extensiones que utilizan la API de solicitud web tienen acceso para leer y modificar todo lo que hace un usuario en la web. Entonces, si bien los bloqueadores de contenido como uBlock Origin utilizan sabiamente el potencial de esta API, Google afirma que otras extensiones con intenciones maliciosas han abusado de las mismas para obtener acceso a la información personal de los usuarios información. Según Google, el 42% de las extensiones maliciosas han utilizado la API Web Request desde enero de 2018. Google también afirma que existen "costos de rendimiento significativos" relacionados con la API como versión de bloqueo. Para lograrlo se requiere un proceso persistente y a menudo de larga duración que es fundamentalmente incompatible con el término "perezoso". procesos.
Con Manifest V3, Google propone limitar esta API en su forma de bloqueo. Como alternativa, Google proporciona la API de solicitud neta declarativa.
El futuro
La descripción oficial de Declarative Net Request describe la API de la siguiente manera:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Con la solicitud de red declarativa, Chrome no necesita enviar toda la información sobre una solicitud a la extensión de escucha. En cambio, la extensión registra reglas con Chrome que le indican al navegador de antemano qué hacer si se ven ciertos tipos de solicitudes.
La extensión especifica sus reglas de antemano. Luego, el navegador (y no la extensión) compara la solicitud de los usuarios con esta regla, y el navegador también realiza la acción y posteriormente se representa la página. Google menciona que esto les permite garantizar la eficiencia ya que pueden ejercer control sobre el algoritmo que determina el resultado y pueden prevenir o desactivar reglas ineficientes. También presenta mejores garantías de privacidad para el usuario final ya que los detalles de la solicitud de red no están expuestos a la extensión. Dado que los procesos persistentes y de larga duración ya no son necesarios (dado que las reglas se registran de antemano), Google afirma que Este enfoque también aporta mejoras de rendimiento que harán que las extensiones sean significativamente más viables en entornos con recursos limitados. plataformas.
La solicitud de red declarativa estará disponible tanto para Manifest V2 (actual) como para Manifest V3, pero será la forma principal en que Google permitirá que las solicitudes de red se modifiquen en Manifest V3.
La controversia
Los cambios de Google parecen tener sentido hasta que escuchas el otro lado de la historia, principalmente el de los bloqueadores de anuncios. Esta migración de API en particular se considera la forma en que Google elimina los bloqueadores de anuncios, ya que cambia fundamentalmente la forma en que funciona uno de los bloqueadores de anuncios más populares. Esto se relaciona con la "teoría" de que Google está motivado hacia este cambio más desde la perspectiva empresarial que desde la perspectiva de la seguridad del usuario. Después de todo, Google depende en gran medida de la publicidad para obtener sus ingresos, y los bloqueadores de publicidad se perciben como una amenaza directa para los clientes de Google en este frente, como se reveló en Presentación del formulario 10-K de la SEC de 2018 de Alphabet (a través de El registro):
Las tecnologías nuevas y existentes podrían afectar nuestra capacidad de personalizar anuncios y/o bloquear anuncios en línea, lo que perjudicaría nuestro negocio.
Se han desarrollado tecnologías para dificultar la personalización de los anuncios o bloquear por completo la visualización de anuncios y algunos proveedores de los servicios en línea tienen tecnologías integradas que potencialmente podrían afectar la funcionalidad principal de los servicios digitales de terceros. publicidad. La mayoría de nuestros ingresos de Google se derivan de las tarifas que nos pagan en relación con la visualización de anuncios en línea. Como resultado, dichas tecnologías y herramientas podrían afectar negativamente nuestros resultados operativos.
Google tuvo que emitir una declaración Para abordar esto, reiterando su postura de que el cambio es en interés de la privacidad del usuario y no un ataque directo contra los bloqueadores de publicidad:
No impedimos el desarrollo de bloqueadores de anuncios ni impedimos que los usuarios bloqueen anuncios. En cambio, queremos ayudar a los desarrolladores, incluidos los bloqueadores de contenido, a escribir extensiones de una manera que proteja la privacidad de los usuarios.
Es necesario hacer referencia a dos de los bloqueadores de publicidad más populares disponibles en Google Chrome: Origen del uBloque y Adblock Plus, los cuales adoptan enfoques diferentes para lograr el mismo resultado de bloqueo de contenido. uBlock Origin depende en gran medida de la API de solicitud web y la comunidad ha dado preferencia a esta extensión a lo largo de los años. Adblock Plus y otras extensiones de bloqueo de contenido también dependen de la parte de bloqueo de Web Request, por lo que los cambios en esta API terminarán afectando a la mayoría de los bloqueadores de contenido al menos en cierta medida.
El impulso de Google para desaprobar Web Request esencialmente eliminará uBlock Origin en su formato actual, algo que de hecho afectará a muchos usuarios. Si bien los usuarios sin lealtad (y sin intención de preocuparse por cómo se logra el bloqueo de anuncios) encontrarán soluciones alternativas que tienen sus propios inconvenientes, será imposible. para que los leales y entusiastas propongan nuevos diseños de motores de filtrado para eludir las diversas técnicas que los sitios web eventualmente idearán para combatir los bloqueadores de anuncios en esta API específica.
También se propuso que la Solicitud neta declarativa fuera un motor de filtrado bastante limitado, ya que era inicialmente planeado tener un límite de 30 000 reglas de filtro estático por extensión (reglas que se declaran durante la instalación); y límite de 5000 reglas en reglas de filtro dinámico por extensión (reglas que se pueden agregar después de la instalación). Se ignorará cualquier exceso de reglas, lo cual es un problema ya que EasyList para Adblock Plus tiene 70.000 reglas, mientras que uBlock Origin se puede configurar para ejecutarse con más de 100.000 reglas. Después de la reacción inicial de la comunidad, Google respondió prometiendo alterar el límite de reglas estáticas de 30.000 reglas por extensión a un máximo global de 150.000 reglas. Esto tiene el efecto secundario de impedir que los usuarios utilicen otros scripts con muchas reglas junto con un bloqueador de anuncios, por lo que los usuarios tendrán que hacer malabarismos con sus preferencias.
Aparte del límite de filtrado limitado, Solicitud neta declarativa sólo puede redirigir a URL estáticas, por lo que no se incluye soporte para la coincidencia de patrones. uBlock Origin depende en gran medida de la coincidencia de patrones y el desarrollador de la extensión declaró que no es posible modernizar algoritmo de coincidencia de su extensión para cumplir con los requisitos de API. La API también requeriría una actualización completa de la extensión para simplemente actualizar la lista de filtros, lo que sería una actividad demasiado frecuente considerando la Frecuencia con la que se actualizan estas listas de filtros.. Por supuesto, estas actualizaciones también dependerían de los criterios y procesos de revisión de extensiones de Google.
Por otro lado, Google siempre ha mantenido su postura de que su intención de alejarse de Web Request es por una perspectiva de seguridad, ya que la API de solicitud web es demasiado poderosa en su forma actual y deja abierto un espacio muy amplio para abuso. Este abuso no es sólo teórico, ya que Google ha mencionado que el 42% de las extensiones maliciosas han abusado de esta API. Apple Safari API de bloqueo de contenido fue diseñado como Declarative Net Request por razones similares, ya que hay menos espacio para que un desarrollador deshonesto lo explote. En la solicitud web debilitada, las solicitudes de red aún serían observables, pero necesitarían permisos en los hosts relevantes. Con Manifest V3, los permisos de host también están cambiando significativamente y ya no se pueden otorgar de manera general en el momento de la instalación.
Google también ha utilizado los gastos generales de rendimiento como motivador para el cambio. La evaluación de las solicitudes de red se produce en el hilo JavaScript de la extensión, lo que puede resultar costoso para el rendimiento. Como refutación, el desarrollador de uBlock Origin menciona que su extensión no incurre en ninguna penalización de rendimiento significativa incluso cuando hay que aplicar hasta 140.000 filtros estáticos. Se afirma que los costos incurridos se recuperan fácilmente gracias a los recursos que no se pueden descargar de servidores remotos y, por lo tanto, no se procesan por el navegador.
Aunque Google no utiliza este razonamiento, también se puede argumentar en contra de Web Request la eficiencia del bloqueo de anuncios. Con Web Request, si una extensión no responde a tiempo (debido a un retraso o una falla), la solicitud de manejo de red está claramente permitida, lo que permite que los anuncios pasen por el bloqueador de anuncios. La Solicitud neta declarativa, por otro lado, no sufriría este inconveniente. En cambio, los anuncios pasarán si no quedan atrapados dentro de las reglas estáticas, y esto sucederá la mayoría de las veces.
Conclusión
De las explicaciones anteriores, queda claro que la Solicitud de red declarativa no es un clon de funcionalidad 1:1 para el bloqueo. capacidades de la API de solicitud web, y los desarrolladores de extensiones seguramente se molestarán cuando su arduo trabajo se vea obstaculizado por tales cambios. Pero el razonamiento de Google también tiene peso: Web Request es demasiado poderoso y sus poderes deben ser restringido en el interés más amplio de la comunidad de usuarios (que se compone de usuarios promedio junto con entusiastas).
El cambio hacia la Solicitud neta declarativa también podría haber sido un movimiento de relaciones públicas positivo: después de todo, ¡Google está agregando una API de bloqueo de contenido incorporada a Chrome! Pero dado que la nueva API viene con sus propias fuertes restricciones, la comunidad ve esto, con razón, como un recorte de alas. En un mundo ideal, Google debería haber explorado el funcionamiento de bloqueadores de anuncios como uBlock Origin antes de lanzar la nueva API. Tal como está ahora, la nueva API podría necesitar mayores flexibilizaciones en sus límites de reglas para adaptarse a escenarios en los que los usuarios querrían usar dos extensiones con muchos filtros.
De acuerdo a El registro, las primeras compilaciones con cambios en Manifest V3 estarán disponibles a partir de julio de 2019. Esperamos que Google tenga en cuenta los comentarios recibidos de la comunidad de desarrolladores de extensiones con estas compilaciones.
¡Un agradecimiento especial al editor en jefe de XDA, Mishaal Rahman, por sus aportes y ayuda!
Editar: el artículo equiparó incorrectamente el funcionamiento de Adblock Plus con el de la API de solicitud de red declarativa. El artículo ha sido modificado en consecuencia. Adblock Plus también se verá afectado por la eliminación de las capacidades de bloqueo de Web Request API.