Simeon Vincent, responsable da interacción cos desenvolvedores de extensións do equipo de Chrome (ocupa o cargo de Defensor de Programadores de Extensións), A posición actual de Google con respecto á terceira edición do manifesto de Chrome, moitos complementos para bloquear contido inadecuado e garantir a seguridade. A compañía non pretende abandonar o seu plan orixinal para deixar de admitir o modo de bloqueo da API webRequest, que permite cambiar o contido recibido sobre a marcha. Só se fará unha excepción para a edición empresarial de Chrome (), no que se manterá o soporte para a API webRequest como antes.
Para usuarios habituais da API de Chrome limitarase ao modo de só lectura. Propúxose unha API declarativa para substituír a API webRequest para o filtrado de contido , que cobre só unha parte limitada das capacidades utilizadas nos modernos bloqueadores de anuncios. Esencialmente, en lugar de controladores propietarios que teñen acceso total ás solicitudes de rede, ofrécese un motor de filtrado integrado universal preparado que procesa as regras de bloqueo por si só. Por exemplo, a API declarativeNetRequest non che permite usar os teus propios algoritmos de filtrado e non che permite crear regras complexas que se solapan entre si dependendo das condicións.
Os desenvolvedores de complementos de bloqueo de anuncios preparáronse conxuntamente , que enumeraba as deficiencias da API declarativeNetRequest. Google aceptou moitos dos comentarios e engadiuse á API declarativeNetRequest. En particular, engadiuse soporte para cambiar e engadir regras de forma dinámica, e é posible eliminar as cabeceiras HTTP, pero só as da lista branca (Referer, Cookie, Set-Cookie). Planeamos implementar compatibilidade para engadir e substituír cabeceiras HTTP (por exemplo, para as directivas de substitución de Set-Cookie e CSP) e a posibilidade de eliminar e substituír os parámetros de solicitude.
Está previsto que unha versión preliminar da terceira versión do manifesto, que define a lista de capacidades e recursos proporcionados aos complementos de Chrome, se use para probar en versións experimentais de Chrome Canary nos próximos meses.
Ao mesmo tempo, a motivación para prohibir os cambios no contido recibido a través da API webRequest non está totalmente clara. As afirmacións de que o modo de bloqueo da API webRequest ten un impacto negativo no rendemento porque o navegador agarda a que o controlador do complemento complete o seu traballo antes de renderizar a páxina non soportan as críticas. Realizado previamente O rendemento dos complementos de bloqueo de anuncios demostrou que o atraso que introducen é insignificante. De media, o uso dun bloqueador ralentiza a execución dunha solicitude só nunha fracción de milisegundos, o que é insignificante en comparación co fondo xeral.
O segundo argumento, relacionado co desexo de protexer aos usuarios do acceso incontrolado de complementos ao contido, tampouco parece convincente, xa que en lugar de eliminar a funcionalidade establecida e xeneralizada nos complementos lexítimos, foi posible engadir un novo tipo de autoridade e proporcionar ao usuario a opción final de instalar un complemento con acceso total ás solicitudes de rede ou non. Ademais, Google deixou soporte para usar a API webRequest en modo de só lectura, o que permite un seguimento completo do tráfico sen intervención de baixo nivel.
Os complementos poden cambiar o contido das páxinas web cargadas a través doutras API (por exemplo, os complementos maliciosos aínda poden entregar os seus anuncios, lanzar mineiros e analizar o contido dos formularios de entrada).
Raymond Hill, autor dos sistemas uBlock Origin e uMatrix para bloquear contido non desexado, é bastante estrito resposta dun representante de Google e insinuou a demagoxia e os xogos entre bastidores nos que Google, baixo o pretexto dunha boa oportunidade, trata de facer avanzar os seus intereses comerciais no ámbito da publicidade en Internet, facerse co control dos seus mecanismos de filtrado e xustificar estas accións aos ollos do público en xeral.
Nunca recibiu argumentos convincentes sobre a necesidade de deter a API estendida e popular entre os desenvolvedores de complementos. Segundo Raymond, a baixada do rendemento non é un argumento, xa que as páxinas se cargan lentamente debido ao seu inchazo, e non polo uso do modo de bloqueo webRequest en complementos correctamente implementados. Se a Google lle importase realmente o rendemento, tería redeseñado webRequest en función do mecanismo , por analoxía con webRequest en Firefox.
Segundo Raymond, a estratexia de Google é determinar o equilibrio óptimo entre a expansión da base de usuarios de Chrome e o dano empresarial causado polo uso de bloqueadores de contido. Na primeira etapa da expansión de Chrome, Google viuse obrigado a soportar os bloqueadores de anuncios como un dos complementos máis populares entre os usuarios. Pero despois de que Chrome gañou o dominio, a compañía intentou inclinar a balanza ao seu favor e controlar o bloqueo promovendo para integrar a funcionalidade de bloqueo de anuncios inadecuada en Chrome. A API webRequest invalida este propósito porque o control sobre o bloqueo de contido está actualmente en mans de desenvolvedores de bloqueadores de anuncios de terceiros.
Fonte: opennet.ru