Google revisa los cambios propuestos en el bloqueador de anuncios de Chrome luego de protestas públicas y amenazas legales
Google se encuentra actualmente en el proceso de actualizar la API utilizada por las extensiones de Chrome. Esto no es algo que a los usuarios típicos les habría importado mucho, hasta que los desarrolladores de extensiones señalaron que uno de los cambios propuestos podría impedir que funcionen muchos bloqueadores de contenido (incluido uBlock Origin) . Si bien Google no se ha retractado completamente de sus planes, ha hecho concesiones en medio de protestas públicas y amenazas legales.
Primero, un poco de historia de fondo: el nivel actual de API para las extensiones de Chrome, llamado ‘Manifest V2’, se introdujo en 2012. Desde entonces, Chrome ha estado sujeto una y otra vez a extensiones maliciosas. Con Manifest V3, actualmente en desarrollo, Google espera reducir el posible daño que podrían causar las extensiones maliciosas, al mismo tiempo que aumenta el rendimiento y agrega nuevas funciones.
Uno de los cambios propuestos es una nueva API declarativeNetRequest , diseñada para reemplazar la API webRequest que muchas extensiones (incluidas AdBlock Plus y uBlock Origin) usan actualmente. En pocas palabras, en lugar de que las extensiones se filtren a sí mismas, proporcionarían una lista de filtros que Chrome analizaría. En el documento de diseño de Manifest V3 , Google afirma que la API actual puede tener un «efecto significativo» en el rendimiento del navegador:
El flujo básico es que cuando comienza una solicitud de red, Chrome envía información al respecto a las extensiones interesadas, y las extensiones responden con qué acción tomar. Esto comienza en el proceso del navegador, implica un salto del proceso al proceso de representación de la extensión, donde la extensión realiza un JavaScript arbitrario (y potencialmente muy lento) y devuelve el resultado al proceso del navegador . Esto puede tener un efecto significativo en cada solicitud de red, incluso en aquellas que no están modificadas, redirigidas o bloqueadas por la extensión (ya que Chrome debe enviar el evento a la extensión para determinar el resultado).
En la superficie, parece completamente razonable que enviar cada solicitud de red a una extensión y detener el navegador hasta que la extensión envíe una respuesta ralentizaría el rendimiento. Cliqz, la compañía detrás de la popular extensión de navegador Ghostery , decidió realizar un estudio del impacto en el rendimiento real de los bloqueadores de anuncios, y los resultados no coincidían con lo que Google declaró.
La compañía dijo en una publicación del blog: «Este trabajo fue motivado por una de las afirmaciones formuladas en la propuesta Manifest V3 del proyecto Chromium: ‘la extensión realiza un JavaScript arbitrario (y potencialmente muy lento)’, hablando de bloqueadores de contenido ‘ capacidad para procesar todas las solicitudes de la red. A partir de las mediciones, no creemos que esta afirmación sea válida, ya que todos los bloqueadores de contenido populares ya son muy eficientes y no deberían incurrir en ninguna desaceleración notable para los usuarios «.
El estudio realizado por Cliqz mostró que el impacto en el rendimiento promedio de los bloqueadores de anuncios populares, incluidos Ghostery, uBlock Origin y AdBlock Plus, era a menudo inferior a 0,05 milisegundos. Si bien el documento de diseño decía que la API existente solo podía ralentizar «potencialmente» a Chrome, en la práctica, no es algo con lo que se encontraría el usuario promedio.
Ghostery / Cliqz anteriormente hizo que su disgusto por los cambios propuestos en la API fuera bien conocido. En una publicación del blog, la compañía escribió: «Pretenden hacer esto por el bien de la privacidad y el rendimiento del navegador, sin embargo, en realidad, los usuarios solo tendrían formas muy limitadas de evitar que terceros intercepten su comportamiento de navegación o deshacerse de ellos». de contenido no deseado. Ya sea que Google haga esto para proteger su negocio publicitario o simplemente para imponer sus propias reglas a todos los demás, no sería nada menos que otro caso de uso indebido de su posición dominante en el mercado. Si esto se cumple, consideraremos archivar Una queja antimonopolio «.
En respuesta a la protesta tanto de los desarrolladores como de los usuarios, el ingeniero de Chrome Devlin Cronin escribió en Grupos de Google que se están agregando nuevas características a la API de reemplazo:
Me gustaría reiterar que todos estos cambios aún están en la etapa de borrador y diseño, como se menciona explícitamente en el documento y el error de seguimiento. La API declarativeNetRequest aún se está expandiendo y se encuentra en desarrollo activo, y los cambios exactos que se implementarán como parte de Manifest V3 no están finalizados. La retroalimentación durante este tiempo es crucial, y absolutamente queremos escuchar sus comentarios e inquietudes.
Otra aclaración es que la API webRequest no se eliminará completamente como parte de Manifest V3. En particular, actualmente no hay cambios planificados en las capacidades de observación de webRequest (es decir, cualquier cosa que no modifique la solicitud). También estamos continuamente escuchando y evaluando los comentarios que estamos recibiendo, y todavía estamos reduciendo los cambios propuestos a la API de webRequest.
La publicación del foro también describe otros cambios que se están realizando en la propuesta en función de los comentarios de los desarrolladores, como agregar soporte de reglas dinámicas a la próxima API declarativa de solicitud de red y aumentar el tamaño máximo del conjunto de reglas. En resumen, la API antigua eventualmente dejará de poder bloquear las solicitudes de red, pero Google ha relajado algunas de las limitaciones para la nueva API.
Esta publicación indicó anteriormente que Google había retrocedido completamente en los cambios propuestos, pero eso no es cierto. La API webRequest aún perderá su capacidad para bloquear solicitudes de red, según los planes actuales. El texto ha sido corregido.
