El Manifiesto V3 de Google cambiará la forma en que funcionan las extensiones de Chrome que bloquean los anuncios: ¿es paralizarlas o es por seguridad?

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 15.89% y Firefox de Mozilla reclamando 5.07%. Debido a su gran parte, los cambios más pequeños que realiza Google Chrome para su plataforma terminan afectando a millones de usuarios en todo el mundo. Entonces, cuando Google anunció la próxima versión de manifiesto de extensiones en forma de Manifiesto V3 para Extensiones de Google Chrome, sabíamos que estábamos ante algunos cambios importantes, especialmente cuando salió a la luz que Google estaba construyendo una API bloqueadora de contenido dentro de Chrome.

¿Qué es el Manifiesto V3?

Si eres un usuario activo de Chrome, indudablemente usas algunas extensiones. Las extensiones son pequeños programas de software que personalizan la experiencia de navegación utilizando las API 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 de Chrome Web Store, que alberga más de 180, 000 extensiones.

Desde finales del año pasado, Google ha estado trabajando en "Manifest V3", un conjunto de cambios propuestos a la plataforma Chrome Extensions que pueden clasificarse como "cambios importantes". Como dice el documento de debate público para Manifest V3, la versión del manifiesto de extensión es Un mecanismo para restringir ciertas capacidades a una cierta clase de extensiones. Estas restricciones pueden tener 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 recientes solo estén disponibles para las extensiones más nuevas, mientras que restringir a una versión máxima de manifiesto permite que las API o capacidades más antiguas sean obsoletas gradualmente.

En términos más simples, una nueva versión de manifiesto permite a Chrome restringir las API y las características a esta nueva versión de manifiesto, para obligar a los desarrolladores de extensiones a migrar lejos de ciertas API anteriores debido a su impacto negativo en la experiencia del usuario. La implementación de una extensión en Manifest V3 debería proporcionar teóricamente garantías más fuertes desde las perspectivas de seguridad, privacidad y rendimiento.

Si bien hay una amplia gama de cambios descritos en el Manifiesto V3, el cambio más controvertido se relaciona con la decisión de Google de limitar las capacidades de bloqueo presentes en la API chrome.webRequest existente (y enfocar la API en la observación en lugar de bloquear) y luego presentar estos bloqueos habilidades a través de una nueva API chrome.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, echemos un vistazo a cómo se compara la API webRequest con la API declarativeNetRequest .

API de solicitud web y API de solicitud neta declarativa

El presente

La descripción oficial de Web Request describe la API de la siguiente manera:

 Use la API chrome.webRequest para observar y analizar el tráfico e interceptar, bloquear o modificar solicitudes en vuelo. 

Con Web Request, Chrome envía todos los datos en una solicitud de red a la extensión que lo está escuchando. 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 lo que sucede cuando las extensiones usan 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 elegir modificar la solicitud en esta etapa. El servidor responde, pero la respuesta vuelve a pasar por la extensión, y la extensión puede determinar si la respuesta debe modificarse. Chrome finalmente muestra la página y el usuario puede ver el resultado de su acción de clic.

A medida que Chrome entrega todos los datos en una solicitud de red, las extensiones que usan la API de solicitud web tienen acceso para leer y modificar todo lo que un usuario hace 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 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 hay "costos de rendimiento significativos" involucrados con la API, ya que la versión de bloqueo requiere un proceso persistente y a menudo de larga duración que es fundamentalmente incompatible con procesos 'flojos'.

Con Manifest V3, Google propone limitar esta API en su forma de bloqueo. Como alternativa, Google proporciona la API de solicitud de red declarativa.

El futuro

La descripción oficial de la Solicitud neta declarativa describe la API de la siguiente manera:

 La API chrome.declarativeNetRequest se usa para bloquear o modificar solicitudes de red especificando reglas declarativas. 

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 dicen al navegador de antemano qué hacer si se ven ciertos tipos de solicitudes.

La extensión especifica sus reglas de antemano. El navegador (y no la extensión) hace coincidir la solicitud de los usuarios con esta regla, y el navegador también realiza la acción y la página se procesa posteriormente. 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 deshabilitar 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 están registradas de antemano), Google afirma que este enfoque también trae mejoras de rendimiento que harán que las extensiones sean significativamente más viables en plataformas con recursos limitados.

La solicitud neta 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 escuche el otro lado de la historia, principalmente el de los bloqueadores de anuncios. Esta migración de API en particular se está viendo como 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 vincula 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 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 de la presentación del Formulario 10-K SEC 2018 de Alphabet (a través de The Register ):

Las tecnologías nuevas y existentes podrían afectar nuestra capacidad de personalizar anuncios y / o bloquear anuncios en línea, lo que dañaría nuestro negocio.

Se han desarrollado tecnologías para hacer que los anuncios personalizables sean más difíciles o para bloquear la visualización de anuncios por completo, y algunos proveedores de servicios en línea tienen tecnologías integradas que podrían afectar la funcionalidad principal de la publicidad digital de terceros. La mayoría 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, tales 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 anuncios:

No estamos impidiendo el desarrollo de bloqueadores de anuncios ni evitando que los usuarios bloqueen los 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.

Se debe hacer referencia a dos de los bloqueadores de anuncios más populares disponibles en Google Chrome: uBlock Origin y Adblock Plus, que adoptan enfoques diferentes para lograr el mismo resultado del bloqueo de contenido. uBlock Origin depende en gran medida de la API de solicitud web, y la comunidad ha preferido 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 capacidad.

El impulso de Google para desaprobar Web Request esencialmente matará a 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 molestarse en cómo se logra el bloqueo de anuncios) encontrarán soluciones alternativas que vienen con sus propios inconvenientes, será imposible para los leales y entusiastas encontrar nuevos diseños de motores de filtrado para eludir el varias técnicas que los sitios web eventualmente encontrará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 inicialmente se planeó tener un límite de 30, 000 reglas en las reglas de filtro estático por extensión (reglas que se declaran durante la instalación); y límite de 5, 000 reglas en las reglas de filtro dinámico por extensión (reglas que se pueden agregar después de la instalación). Cualquier exceso de reglas se ignorará, 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 la regla estática 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 reglas pesadas junto con un bloqueador de anuncios, por lo que los usuarios tendrán que hacer malabarismos con sus preferencias.

Además del límite de filtrado limitado, la Solicitud de red declarativa solo 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 adaptar el algoritmo de coincidencia de su extensión para cumplir con el requisito 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 teniendo en cuenta 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 desde una perspectiva de seguridad, ya que la API de Web Request es demasiado poderosa en su forma actual y deja 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. Content Blocker API de Apple Safari se diseñó como una Solicitud de red declarativa por razones similares, ya que hay menos espacio para que un desarrollador malintencionado explote. En la solicitud web nerfed, 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 gastos generales de rendimiento como un motivador para el cambio. La evaluación de las solicitudes de red se produce en el hilo de JavaScript de la extensión, lo que puede ser 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 tiene que aplicar hasta 140, 000 filtros estáticos. Se afirma que los costos incurridos se recuperan fácilmente por los recursos que no pueden descargarse de servidores remotos y, por lo tanto, no son procesados ​​por el navegador.

A pesar de que Google no utiliza este razonamiento, también se puede argumentar en contra de la Solicitud web para la eficiencia con el bloqueo de anuncios. Con Web Request, si una extensión no responde a tiempo (debido a un retraso o un bloqueo), 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, está claro que la Solicitud de red declarativa no es un clon de funcionalidad 1: 1 para las capacidades de bloqueo de la API de solicitud web, y los desarrolladores de extensiones seguramente se molestarán cuando su trabajo duro se vea perjudicado por tales cambios. Pero el razonamiento de Google también tiene peso: la solicitud web es demasiado poderosa y sus poderes deben reducirse en interés de la comunidad de usuarios (que comprende usuarios promedio junto con entusiastas).

El movimiento hacia la Solicitud de red declarativa también podría haber sido un movimiento de relaciones públicas positivo: después de todo, Google está agregando una API bloqueadora de contenido incorporada a Chrome. Pero dado que la nueva API viene con sus propias restricciones, la comunidad ve esto con razón como un recorte de sus alas. En un mundo ideal, Google debería haber explorado el funcionamiento de los bloqueadores de anuncios como uBlock Origin antes de lanzar la nueva API. Tal como está ahora, la nueva API podría usar más relajaciones en sus límites de reglas para acomodar escenarios en los que los usuarios desearían usar dos extensiones con filtros pesados.

Según The Register, las primeras compilaciones con los cambios del Manifiesto V3 estarán disponibles a partir de julio de 2019 en adelante. Esperamos que Google acomode los comentarios recibidos de la comunidad de desarrolladores de extensiones con estas compilaciones.


Un agradecimiento especial al Editor en Jefe Mishaal Rahman por sus aportes y asistencia.

Editar: el artículo equiparó incorrectamente el trabajo 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 la API de solicitud web.