Desenvolupadors del navegador Chrome la suspensió del suport per al mode de funcionament de bloqueig de l'API webRequest, que us permet canviar el contingut rebut sobre la marxa i s'utilitza activament en complements per bloquejar la publicitat,
protecció contra programari maliciós, phishing, espionatge de l'activitat dels usuaris, controls parentals i privadesa.
Motius de Google:
- Mode de bloqueig de l'API comporta un alt consum de recursos.
Quan s'utilitza aquesta API, el navegador envia primer al complement totes les dades contingudes a la sol·licitud de xarxa, el complement les analitza i retorna una versió modificada per a un posterior processament al navegador o emet instruccions de bloqueig. En aquest cas, els principals retards no es produeixen en l'etapa de processament del trànsit pel complement, sinó per les despeses generals de coordinació de l'execució del complement. En particular, aquestes manipulacions requereixen el llançament d'un procés separat per complementar, així com l'ús d'IPC per interactuar amb aquest procés i mecanismes de serialització de dades; - El complement controla completament tot el trànsit a un nivell baix, la qual cosa obre grans oportunitats d'abús i violacions de privadesa. Segons les estadístiques de Google, el 42% de tots els complements maliciosos detectats utilitzaven l'API webRequest. Cal assenyalar que cada mes es bloquegen els intents de col·locar una mitjana de 1800 complements maliciosos al catàleg de Chrome Web Store. Malauradament, la revisió no ens permet captar tots els complements maliciosos sense excepció, de manera que per millorar la protecció, es va decidir limitar els complements a nivell d'API. La idea principal és proporcionar complements amb accés no a tot el trànsit, sinó només a les dades necessàries per implementar la funcionalitat prevista. En particular, per bloquejar contingut, no és necessari donar al complement accés complet a totes les dades confidencials de l'usuari;
- API declarativa de substitució proposada s'ocupa de tot el treball de filtratge de contingut d'alt rendiment i només requereix complements per carregar les regles de filtratge. El complement no pot interferir amb el trànsit i les dades privades de l'usuari romanen inviolables;
- Google va tenir en compte molts dels comentaris sobre la manca de funcionalitat de l'API declarativeNetRequest i va ampliar el límit del nombre de regles de filtrat des dels 30 mil per extensió proposats inicialment fins a un màxim global de 150 mil, i també va afegir la possibilitat de fer de forma dinàmica. canviar i afegir regles, eliminar i substituir les capçaleres HTTP (Referer, Cookie, Set-Cookie) i sol·licitar paràmetres;
- Per a les empreses, és possible utilitzar el mode de funcionament de bloqueig de l'API webRequest, ja que la política d'ús de complements la determina un administrador que entén les característiques de la infraestructura i és conscient dels riscos. Per exemple, l'API especificada es pot utilitzar a les empreses per registrar els fluxos de trànsit dels empleats i integrar-se amb els sistemes interns;
- L'objectiu de Google no és soscavar o suprimir els complements de bloqueig d'anuncis, sinó permetre la creació de bloquejadors d'anuncis més segurs i potents;
- La reticència a abandonar el mode de funcionament de bloqueig de l'API webRequest juntament amb la nova declarativeNetRequest s'explica per la voluntat de limitar l'accés dels complements a dades confidencials. Si deixeu l'API webRequest tal com està, la majoria dels complements no utilitzaran el declarativeNetRequest més segur, ja que a l'hora de triar entre seguretat i funcionalitat, la majoria dels desenvolupadors solen triar la funcionalitat.
:
- Realitzat per desenvolupadors de complements mostren un impacte general insignificant en el rendiment dels complements de bloqueig d'anuncis (durant les proves, es va comparar el rendiment de diversos complements, però sense tenir en compte la sobrecàrrega d'un procés addicional que coordina l'execució dels controladors en el mode de bloqueig de l'API webRequest);
- No és pràctic deixar de donar suport per complet a una API que s'utilitza activament als complements. En lloc d'eliminar-lo, podeu afegir un permís separat i controlar estrictament l'adequació del seu ús als complements, cosa que estalviaria als autors de molts complements populars de reelaborar completament els seus productes i evitaria tallar la funcionalitat;
- Per reduir els costos generals, no podeu eliminar l'API, sinó refer-la basant-vos en el mecanisme Promise, de manera similar a la implementació de webRequest a Firefox;
- L'alternativa proposada, declarativeNetRequest, no cobreix totes les necessitats dels desenvolupadors de complements per al bloqueig d'anuncis i seguretat/privadesa, ja que no ofereix un control total sobre les sol·licituds de xarxa, no permet l'ús d'algorismes de filtratge personalitzats i no permet l'ús de regles complexes que se superposen en funció de les condicions;
- Amb l'estat actual de l'API declarativeNetRequest, és impossible recrear la funcionalitat existent dels complements uBlock Origin i uMatrix sense canvis, i també fa que el desenvolupament d'un port NoScript per a Chrome sigui inútil;
- Les preocupacions sobre la privadesa són inverosímiles, ja que el mode de només lectura i sense bloqueig de l'API webRequest es deixa al seu lloc i encara permet que els complements maliciosos controlin tot el trànsit, però no ofereix la capacitat d'interferir-hi a la volar (canviar el contingut, col·locar els vostres anuncis, executar miners i analitzar el contingut dels formularis d'entrada es pot utilitzar després que la pàgina s'hagi acabat de carregar);
- Desenvolupadors de navegadors , и , basat en el motor Chromium, tenen la intenció de deixar suport per al mode de bloqueig webRequest als seus productes.
Font: opennet.ru