Desarrolladores del navegador Chrome interrupción del soporte para el modo de funcionamiento de bloqueo de la API webRequest, que le permite cambiar el contenido recibido sobre la marcha y se utiliza activamente en complementos para bloquear publicidad,
protección contra malware, phishing, espionaje de la actividad del usuario, controles parentales y privacidad.
Los motivos de Google:
- Modo de bloqueo de API conduce a un alto consumo de recursos.
Cuando se utiliza esta API, el navegador primero envía al complemento todos los datos contenidos en la solicitud de red, el complemento los analiza y devuelve una versión modificada para su posterior procesamiento en el navegador o emite instrucciones de bloqueo. En este caso, los principales retrasos surgen no en la etapa de procesamiento del tráfico por parte del complemento, sino debido a los costos generales de coordinar la ejecución del complemento. En particular, tales manipulaciones requieren el lanzamiento de un proceso separado para complementar, así como el uso de IPC para interactuar con este proceso y mecanismos de serialización de datos; - El complemento controla completamente todo el tráfico a un nivel bajo, lo que abre grandes oportunidades para abusos y violaciones de la privacidad. Según las estadísticas de Google, el 42% de todos los complementos maliciosos detectados utilizaban la API webRequest. Cabe señalar que cada mes se bloquean en el catálogo de Chrome Web Store un promedio de 1800 complementos maliciosos. Desafortunadamente, la revisión no nos permite detectar todos los complementos maliciosos sin excepción, por lo que para mejorar la protección, se decidió limitar los complementos a nivel de API. La idea principal es proporcionar complementos con acceso no a todo el tráfico, sino solo a los datos necesarios para implementar la funcionalidad prevista. En particular, para bloquear contenido, no es necesario darle al complemento acceso completo a todos los datos confidenciales del usuario;
- API declarativa de reemplazo propuesta se encarga de todo el trabajo de filtrado de contenido de alto rendimiento y solo requiere complementos para cargar reglas de filtrado. El complemento no puede interferir con el tráfico y los datos privados del usuario siguen siendo inviolables;
- Google tuvo en cuenta muchos de los comentarios sobre la falta de funcionalidad de la API declarativeNetRequest y amplió el límite en el número de reglas de filtrado de las 30 mil propuestas inicialmente por extensión a un máximo global de 150 mil, y también agregó la capacidad de dinámicamente cambiar y agregar reglas, eliminar y reemplazar encabezados HTTP (Referer, Cookie, Set-Cookie) y solicitar parámetros;
- Para las empresas, es posible utilizar el modo de funcionamiento de bloqueo de la API webRequest, ya que la política de uso de complementos la determina un administrador que comprende las características de la infraestructura y es consciente de los riesgos. Por ejemplo, la API especificada se puede utilizar en empresas para registrar los flujos de tráfico de los empleados e integrarla con los sistemas internos;
- El objetivo de Google no es socavar ni suprimir los complementos de bloqueo de anuncios, sino permitir la creación de bloqueadores de anuncios más seguros y potentes;
- La renuencia a abandonar el modo de funcionamiento de bloqueo de la API webRequest junto con el nuevo declarativeNetRequest se explica por el deseo de limitar el acceso de los complementos a datos confidenciales. Si deja la API webRequest como está, la mayoría de los complementos no utilizarán el declarativeNetRequest más seguro, ya que al elegir entre seguridad y funcionalidad, la mayoría de los desarrolladores normalmente elegirán la funcionalidad.
:
- Realizado por desarrolladores de complementos muestran un impacto general insignificante en el rendimiento de los complementos de bloqueo de anuncios (durante las pruebas, se comparó el rendimiento de varios complementos, pero sin tener en cuenta la sobrecarga de un proceso adicional que coordina la ejecución de los controladores en el modo de bloqueo de la API webRequest);
- No es práctico dejar de admitir por completo una API que se utiliza activamente en complementos. En lugar de eliminarlo, puede agregar un permiso separado y controlar estrictamente la idoneidad de su uso en complementos, lo que evitaría que los autores de muchos complementos populares reelaboren completamente sus productos y evitarían recortar funcionalidades;
- Para reducir los costos generales, no puede eliminar la API, sino rehacerla según el mecanismo Promise, similar a la implementación de webRequest en Firefox;
- La alternativa propuesta, declarativeNetRequest, no cubre todas las necesidades de los desarrolladores de complementos para el bloqueo de anuncios y la seguridad/privacidad, ya que no proporciona control total sobre las solicitudes de red, no permite el uso de algoritmos de filtrado personalizados y no permite el uso de reglas complejas que se superponen entre sí según las condiciones;
- Con el estado actual de la API declarativeNetRequest, es imposible recrear la funcionalidad existente de los complementos uBlock Origin y uMatrix sin cambios, y también hace que sea inútil seguir desarrollando un puerto NoScript para Chrome;
- Las preocupaciones sobre la privacidad son inverosímiles, ya que el modo de solo lectura y sin bloqueo de la API webRequest se mantiene y aún permite que complementos maliciosos controlen todo el tráfico, pero no brinda la posibilidad de interferir con él en la red. volar (cambiar contenido, colocar anuncios, ejecutar mineros y analizar el contenido de los formularios de entrada se puede utilizar después de que la página haya terminado de cargarse);
- Desarrolladores de navegadores , и , construido sobre el motor Chromium, tiene la intención de dejar la compatibilidad con el modo de bloqueo webRequest en sus productos.
Fuente: opennet.ru