Programadores de navegador Chrome descontinuación do soporte para o modo de funcionamento de bloqueo da API webRequest, que lle permite cambiar o contido recibido sobre a marcha e úsase activamente en complementos para bloquear publicidade,
protección contra software malicioso, phishing, espionaxe da actividade do usuario, controis parentais e privacidade.
Motivos de Google:
- Modo de bloqueo da API leva a un alto consumo de recursos.
Ao utilizar esta API, o navegador envía primeiro ao complemento todos os datos contidos na solicitude de rede, o complemento analízao e devolve unha versión modificada para o seu posterior procesamento no navegador ou emite instrucións de bloqueo. Neste caso, os principais atrasos xorden non na fase de procesamento do tráfico polo complemento, senón polos custos xerais de coordinación da execución do complemento. En particular, tales manipulacións requiren o lanzamento dun proceso separado para complementar, así como o uso de IPC para interactuar con este proceso e mecanismos de serialización de datos; - O complemento controla completamente todo o tráfico nun nivel baixo, o que abre grandes oportunidades de abuso e violacións da privacidade. Segundo as estatísticas de Google, o 42% de todos os complementos maliciosos detectados utilizaron a API webRequest. Nótese que cada mes, os intentos de colocar unha media de 1800 complementos maliciosos están bloqueados no catálogo de Chrome Web Store. Desafortunadamente, a revisión non nos permite atrapar todos os complementos maliciosos sen excepción, polo que para mellorar a protección, decidiuse limitar os complementos a nivel de API. A idea principal é proporcionar complementos con acceso non a todo o tráfico, senón só aos datos necesarios para implementar a funcionalidade prevista. En particular, para bloquear contido, non é necesario dar ao complemento acceso total a todos os datos confidenciais do usuario;
- API declarativa de substitución proposta encárgase de todo o traballo de filtrado de contido de alto rendemento e só require complementos para cargar regras de filtrado. O complemento non pode interferir co tráfico e os datos privados do usuario seguen sendo inviolables;
- Google tivo en conta moitos dos comentarios sobre a falta de funcionalidade da API declarativeNetRequest e ampliou o límite do número de regras de filtrado desde os 30 mil por extensión propostos inicialmente ata un máximo global de 150 mil, e tamén engadiu a posibilidade de cambiar e engadir regras, eliminar e substituír cabeceiras HTTP (Referer, Cookie, Set-Cookie) e solicitar parámetros;
- Para as empresas, é posible utilizar o modo de funcionamento de bloqueo da API webRequest, xa que a política de uso de complementos está determinada por un administrador que entende as características da infraestrutura e coñece os riscos. Por exemplo, a API especificada pódese usar nas empresas para rexistrar os fluxos de tráfico dos empregados e integrarse cos sistemas internos;
- O obxectivo de Google non é socavar nin suprimir os complementos de bloqueo de anuncios, senón permitir a creación de bloqueadores de anuncios máis seguros e potentes;
- A reticencia a abandonar o modo de funcionamento de bloqueo da API webRequest xunto co novo declarativeNetRequest explícase polo desexo de limitar o acceso dos complementos a datos confidenciais. Se deixas a API webRequest tal e como está, a maioría dos complementos non usarán o declarativeNetRequest máis seguro, xa que ao elixir entre seguridade e funcionalidade, a maioría dos desenvolvedores elixirán normalmente a funcionalidade.
:
- Realizado por desenvolvedores de complementos mostran un impacto xeral insignificante no rendemento dos complementos de bloqueo de anuncios (durante as probas, comparouse o rendemento de varios complementos, pero sen ter en conta a sobrecarga dun proceso adicional que coordina a execución dos controladores no modo de bloqueo de a API webRequest);
- Non é práctico deixar de admitir completamente unha API que se usa activamente nos complementos. En lugar de eliminalo, pode engadir un permiso separado e controlar estritamente a adecuación do seu uso en complementos, o que salvaría aos autores de moitos complementos populares de reelaborar completamente os seus produtos e evitaría cortar a funcionalidade;
- Para reducir os custos xerais, non se pode eliminar a API, senón refacela baseándose no mecanismo Promise, similar á implementación de webRequest en Firefox;
- A alternativa proposta, declarativeNetRequest, non cobre todas as necesidades dos desenvolvedores de complementos para o bloqueo de anuncios e a seguridade/privacidade, xa que non proporciona un control total sobre as solicitudes de rede, non permite o uso de algoritmos de filtrado personalizados e non permite o uso de regras complexas que se superpoñen en función das condicións;
- Co estado actual da API declarativeNetRequest, é imposible recrear a funcionalidade existente dos complementos uBlock Origin e uMatrix sen cambios, e tamén fai inútil o desenvolvemento dun porto NoScript para Chrome;
- As preocupacións sobre a privacidade son descabelladas, xa que o modo de só lectura e sen bloqueo da API webRequest permanece no seu lugar e aínda permite que os complementos maliciosos controlen todo o tráfico, pero non ofrece a capacidade de interferir con el no voar (cambiar o contido, colocar os seus anuncios, executar mineiros e analizar o contido dos formularios de entrada pódese usar despois de que a páxina remate de cargarse);
- Desenvolvedores de navegadores , и , construído sobre o motor Chromium, pretenden deixar a compatibilidade co modo de bloqueo webRequest nos seus produtos.
Fonte: opennet.ru