Leer actualización
- Esta publicación indicó anteriormente que Google se había retractado por completo de los cambios propuestos, pero eso no es cierto. La API webRequest eventualmente perderá su capacidad para bloquear solicitudes de red, según los planes actuales. El texto ha sido corregido.
Actualmente, Google se encuentra en proceso de actualizar la API utilizada por las extensiones de Chrome. Esto no es algo que les haya importado mucho a los usuarios típicos, hasta que los desarrolladores de extensiones señalaron que uno de los cambios propuestos podría evitar que funcionen muchos bloqueadores de contenido (incluido uBlock Origin). Si bien Google no se ha retractado por completo de sus planes, ha hecho concesiones en medio de la protesta pública y las 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.
ANDROIDPOLICE VÍDEO DEL DÍA
Uno de los cambios propuestos es una nueva API NetRequest declarativa, diseñada para reemplazar la API webRequest que utilizan actualmente muchas extensiones (incluidas AdBlock Plus y uBlock Origin). En pocas palabras, en lugar de que las extensiones realicen el filtrado de la red por sí mismas, proporcionarían una lista de filtros que el propio Chrome analizaría. En el documento de diseño 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 de proceso al proceso de representación de la extensión, donde la extensión luego ejecuta 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 aquellas que la extensión no modifica, redirige o bloquea (ya que Chrome necesita 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 pausar 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 sobre el impacto en el rendimiento real de los bloqueadores de anuncios, y los resultados no se alinearon con lo que dijo Google.
La compañía dijo en una publicación de blog: "Este trabajo fue motivado por una de las afirmaciones formuladas en la propuesta Manifest V3 del proyecto Chromium: 'la extensión luego ejecuta 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 se mantenga, ya que todos los bloqueadores de contenido populares ya son muy eficientes y no deberían incurrir en ninguna ralentización notable para los usuarios".
(Crédito de la imagen: ZDNet)
El estudio realizado por Cliqz mostró que el impacto de rendimiento promedio en los bloqueadores de anuncios populares, incluidos Ghostery, uBlock Origin y AdBlock Plus, a menudo era inferior a 0,05 milisegundos. Si bien el documento de diseño decía que la API existente solo podría "potencialmente" ralentizar Chrome, en la práctica, no es algo que el usuario promedio encontraría.
Ghostery/Cliqz previamente hizo bien conocido su disgusto por los cambios API propuestos. En una publicación de 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 para deshacerse de contenido no deseado. Ya sea que Google haga esto para proteger su negocio de publicidad o simplemente para imponer sus propias reglas a todos los demás, sería nada menos que otro caso de mal uso de su posición dominante en el mercado. Si esto se hace realidad, consideraremos presentar una denuncia antimonopolio".
En respuesta a las protestas 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 funciones a la API de reemplazo:
Me gustaría reiterar que todos estos cambios aún se encuentran en la etapa de borrador y diseño, como se menciona explícitamente en el documento y el error de seguimiento. La API declarativeNetRequest todavía se está expandiendo y está en desarrollo activo, y los cambios exactos que se implementarán como parte del Manifiesto V3 no están finalizados. Los comentarios durante este tiempo son cruciales y queremos escuchar sus comentarios e inquietudes.
Otra aclaración es que la API webRequest no se eliminará por completo como parte del Manifiesto V3. En particular, actualmente no hay cambios planificados en las capacidades de observación de webRequest (es decir, nada que no modifique la solicitud). También escuchamos y evaluamos continuamente los comentarios que recibimos, y todavía estamos limitando los cambios propuestos a la API 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 declarativeNetRequest y aumentar el tamaño máximo del conjunto de reglas. En resumen, la antigua API eventualmente dejará de poder bloquear solicitudes de red, pero Google ha relajado algunas de las limitaciones de la nueva API.
ACTUALIZACIÓN: 2019/02/17 9:20 a.m. PST POR CORBIN DAVENPORT
Esta publicación indicó anteriormente que Google se había retractado por completo de los cambios propuestos, pero eso no es cierto. La API webRequest eventualmente perderá su capacidad para bloquear solicitudes de red, según los planes actuales. El texto ha sido corregido.
Fuente: Documentos de Google (archivado), Ghostery, WhoTracksMe, Grupos de Google