Google Chromees el navegador web multiplataforma más popular disponible en el mercado en este momento,con un 62,7 % de la cuota de uso de navegadores globaleshasta mayo de 2019, seguido por Safari de Apple con un 15,89 % y Firefox de Mozilla con un 5,07 %. Debido a su gran participación, los cambios más pequeños que Google Chrome lleva a cabo para su plataforma terminan afectando a millones de usuarios en todo el mundo. Por eso, 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 nos esperaban grandes cambios, especialmente cuando salió a la luz que Google estaba desarrollando una API de bloqueo de contenido dentro del propio Chrome.
¿Qué es Manifest 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 lasAPI que proporciona el navegador, lo que permite a los usuarios adaptar la funcionalidad y el comportamiento para satisfacer sus necesidades y preferencias individuales. Estas extensiones se distribuyen principalmente a través deChrome Web Store, que alberga más de 180.000 extensiones.
Desdefinales del año pasado, Google ha estado trabajando en "Manifest V3", un conjunto de cambios propuestos para la plataforma de extensiones de Chrome que pueden clasificarse como "cambios importantes". Como se indica en eldocumento de debate público para Manifest V3, 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. La restricción a una versión mínima permite que las API o capacidades más nuevas solo estén disponibles para las extensiones más nuevas, mientras que la restricción a una versión máxima del manifiesto permite que las API o capacidades más antiguas queden obsoletas gradualmente.
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, con el fin de obligar a los desarrolladores de extensiones a migrar de ciertas API antiguas debido a su impacto negativo en la experiencia del usuario. La implementación de una extensión en el manifiesto V3 debería, en teoría, brindar garantías más sólidas desde las perspectivas de seguridad, privacidad y rendimiento.
Si bien hay una amplia gama de cambios delineados en Manifest V3, el cambio más controvertido se relaciona con la decisión de Google de limitar las capacidades de bloqueo presentes en la APIchrome.webRequestexistente (y enfocar la API en la observación en lugar del bloqueo) y luego presentar estas capacidades de bloqueo a través de una nueva APIchrome.declarativeNetRequest. Este cambio en particular ha inflamado a la comunidad, ya que termina apuntando al mecanismo de bloqueo de anuncios de la famosa extensión de bloqueo de anuncios,uBlock Origin, y afecta directamente a sus más de 10 millones de usuarios.
Antes de abordar este problema, veamos cómo se compara la APIwebRequestcon la APIdeclarativaNetRequest.
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:
Utilice la chrome.webRequest API para observar y analizar el tráfico e interceptar, bloquear o modificar solicitudes en curso.Con Web Request, Chrome envíatodoslos datos de una solicitud de red a la extensión que la está escuchando. La extensión tiene la oportunidad de evaluar la solicitud e indicarle a Chrome qué hacer con ella: permitirla, bloquearla o enviarla con algunas modificaciones.
Siga la secuencia de eventos para comprender qué sucede cuando las extensiones utilizan la API de solicitud web. Cuando un usuario con una extensión de solicitud web 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 pasa nuevamente por la extensión, y esta puede determinar 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 clic.
Como Chrome entregatodos 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 un usuario hace en la web. Por lo tanto, 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 la misma para obtener acceso a la información personal de los usuarios. Según Google, el 42% de las extensiones maliciosas han utilizado la API de solicitud web desde enero de 2018. Google también afirma que existen "costos de rendimiento significativos" involucrados con la API, ya que la versión de bloqueo de la misma requiere un proceso persistente y, a menudo, de larga duración que es fundamentalmente incompatible con los procesos "perezosos".
Con Manifest V3, Google propone limitar esta API en su forma de bloqueo. Como alternativa, Google ofrece la API Declarative Net Request.
El futuro
La descripción oficial de Declarative Net Request describe la API de la siguiente manera:
La chrome.declarativeNetRequestAPI se utiliza para bloquear o modificar solicitudes de red especificando reglas declarativas.Con Declarative Net Request, Chrome no necesita enviar toda la información sobre una solicitud a la extensión que la escucha. En cambio, la extensión registra reglas con Chrome que le indican al navegador de antemano qué hacer si se detectan determinados tipos de solicitudes.
La extensión especifica sus reglas de antemano. El navegador (no la extensión) compara la solicitud del usuario con esta regla, y el navegador también realiza la acción y, posteriormente, se muestra 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 evitar o deshabilitar reglas ineficientes. También ofrece mejores garantías de privacidad para el usuario final, ya que los detalles de la solicitud de red no se exponen a la extensión. Dado que los procesos persistentes y de larga duración ya no son necesarios (ya 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 plataformas con recursos limitados.
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 se modifiquen las solicitudes de red en Manifest V3.
La controversia
Los cambios de Google parecen tener sentido hasta que se escucha la otra versión de la historia, principalmente la de los bloqueadores de anuncios. Esta migración de API en particular se considera como la forma de Google de acabar con 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 por este cambio más desde la perspectiva comercial que desde la perspectiva de la seguridad del usuario. Después de todo, Google depende en gran medida de la publicidad para sus ingresos, y los bloqueadores de anuncios se perciben como una amenaza directa para los clientes de Google en este frente, como se reveló a través dela presentación del Formulario 10-K de la SEC de 2018 de Alphabet(a través deThe Register):
Las tecnologías nuevas y existentes podrían afectar nuestra capacidad de personalizar anuncios y/o podrían bloquear anuncios en línea, lo que perjudicaría nuestro negocio.
Se han desarrollado tecnologías para dificultar la personalización de anuncios o para bloquear la visualización de anuncios por completo, y algunos proveedores de servicios en línea han integrado tecnologías que podrían perjudicar la funcionalidad básica de la publicidad digital de terceros. La mayor parte de nuestros ingresos de Google se derivan de las tarifas que se 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 queemitir un comunicadopara abordar este tema, reiterando su postura de que el cambio responde al interés de la privacidad del usuario y no es un ataque directo contra los bloqueadores de anuncios:
No estamos impidiendo el desarrollo de bloqueadores de anuncios ni impidiendo 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 anuncios más populares disponibles en Google Chrome:uBlock OriginyAdblock Plus, los cuales adoptan diferentes enfoques 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 optado por 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 la solicitud web, 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.
La iniciativa de Google de descontinuar Web Request básicamente acabará con uBlock Origin en su formato actual, algo que 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 los leales y entusiastas idear 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 Declarative Net Request fuera un motor de filtrado bastante limitado, ya queinicialmente se planeótener un límite de 30 000 reglas en las reglas de filtrado estático por extensión (reglas que se declaran durante la instalación); y un límite de 5000 reglas en las reglas de filtrado dinámico por extensión (reglas que se pueden agregar después de la instalación). Cualquier regla en exceso se ignorará, lo que es un pequeño 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, Declarative Net Requestsolo 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ónafirmó que no es posible adaptarel algoritmo de coincidencia de su extensión para cumplir con el requisito de las 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 lafrecuencia 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 desde una perspectiva de seguridad, ya que la API de Web Request es demasiado poderosa en su forma actual y deja abierto un amplio margen para el abuso. Este abuso no es solo teórico, ya que Google ha mencionado que el 42% de las extensiones maliciosas han abusado de esta API.La API Content Blockerde Apple Safari se diseñó como Declarative Net Request por razones similares, ya que hay menos margen para que un desarrollador deshonesto la explote. En la Web Request debilitada, las solicitudes de red seguirían siendo 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 costes de rendimiento como motivación para el cambio. La evaluación de las solicitudes de red se realiza en el hilo de JavaScript de la extensión, lo que puede resultar costoso para el rendimiento. Como réplica, el desarrollador de uBlock Origin menciona que su extensiónno incurre en ninguna penalización de rendimiento significativaincluso cuando tiene que aplicar hasta 140.000 filtros estáticos. Se afirma que los costes incurridos se recuperan fácilmente gracias a los recursos que no se pueden descargar de servidores remotos y, por lo tanto, no son procesados por el navegador.
Aunque Google no utiliza este razonamiento, también se puede argumentar en contra de Web Request en relación con 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 gestión de red se permite simplemente, lo que permite que los anuncios pasen por el bloqueador de anuncios. Por otro lado, Net Request declarativo no sufriría este inconveniente. En cambio, los anuncios pasarán si no quedan atrapados dentro de las reglas estáticas, y esto sucederá con más frecuencia que no.
Conclusión
De las explicaciones anteriores se desprende claramente que Declarative Net Request no es un clon funcional 1:1 de las capacidades de bloqueo de la API Web Request, y los desarrolladores de extensiones seguramente se enfadarán cuando su arduo trabajo se vea obstaculizado por dichos cambios. Pero el razonamiento de Google también tiene peso: Web Request es demasiado potente y sus poderes deben limitarse en beneficio de la comunidad de usuarios (que incluye a los usuarios promedio y a los entusiastas).
El paso a la Declarative Net Request también podría haber sido una medida positiva de relaciones públicas: después de todo, ¡Google está añadiendo una API de bloqueo de contenido integrada a Chrome! Pero como la nueva API viene con sus propias restricciones importantes, la comunidad lo ve con razón como un recorte de sus alas. En un mundo ideal, Google debería haber explorado el funcionamiento de bloqueadores de anuncios como uBlock Origin antes de impulsar la nueva API. Tal como está ahora, la nueva API podría beneficiarse de más relajaciones en sus límites de reglas para adaptarse a escenarios en los que los usuarios quieran utilizar dos extensiones con muchos filtros.
SegúnThe Register, las primeras compilaciones con los cambios de 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 web declarativa. El artículo se modificó en consecuencia. Adblock Plus también se verá afectado por la eliminación de las capacidades de bloqueo de la API de solicitud web.