Ontwikkelaars van Chrome-browsers stopzetting van de ondersteuning voor de blokkeermodus van de webRequest API, waarmee u de ontvangen inhoud direct kunt wijzigen en die actief wordt gebruikt in add-ons voor het blokkeren van advertenties,
bescherming tegen malware, phishing, het bespioneren van gebruikersactiviteiten, ouderlijk toezicht en privacy.
Motieven van Google:
- API-blokkeermodus leidt tot een hoog verbruik van hulpbronnen.
Bij gebruik van deze API stuurt de browser de add-on eerst alle gegevens uit het netwerkverzoek, de add-on analyseert deze en retourneert een aangepaste versie voor verdere verwerking in de browser of geeft blokkeerinstructies. In dit geval ontstaan de grootste vertragingen niet in de fase van het verwerken van verkeer door de add-on, maar als gevolg van de overheadkosten voor het coördineren van de uitvoering van de add-on. In het bijzonder vereisen dergelijke manipulaties de lancering van een afzonderlijk proces ter aanvulling, evenals het gebruik van IPC om met dit proces en dataserialisatiemechanismen te interageren; - De add-on controleert al het verkeer volledig op een laag niveau, wat enorme mogelijkheden biedt voor misbruik en privacyschendingen. Volgens de statistieken van Google maakte 42% van alle gedetecteerde kwaadaardige add-ons gebruik van de webRequest API. Er wordt opgemerkt dat elke maand pogingen om gemiddeld 1800 kwaadaardige add-ons te plaatsen in de Chrome Web Store-catalogus worden geblokkeerd. Helaas kunnen we door de evaluatie niet zonder uitzondering alle kwaadaardige add-ons onderscheppen. Om de bescherming te verbeteren, werd besloten om add-ons op API-niveau te beperken. Het hoofdidee is om add-ons niet toegang te geven tot al het verkeer, maar alleen tot de gegevens die nodig zijn om de beoogde functionaliteit te implementeren. Om inhoud te blokkeren is het met name niet nodig om de add-on volledige toegang te geven tot alle vertrouwelijke gebruikersgegevens;
- Voorgestelde vervangende declaratieve API zorgt voor al het werk van hoogwaardige inhoudfiltering en vereist alleen add-ons om filterregels te laden. De add-on kan het verkeer niet verstoren en de privégegevens van de gebruiker blijven onschendbaar;
- Google hield rekening met veel van de opmerkingen over het gebrek aan functionaliteit van de declarativeNetRequest API en breidde de limiet op het aantal filterregels uit van de aanvankelijk voorgestelde 30 per extensie naar een wereldwijd maximum van 150, en voegde ook de mogelijkheid toe om dynamisch regels wijzigen en toevoegen, HTTP-headers (Referer, Cookie, Set-Cookie) verwijderen en vervangen en parameters opvragen;
- Voor ondernemingen is het mogelijk om de blokkeermodus van de webRequest API te gebruiken, aangezien het beleid voor het gebruik van add-ons wordt bepaald door een beheerder die de kenmerken van de infrastructuur begrijpt en zich bewust is van de risico's. De gespecificeerde API kan bijvoorbeeld in ondernemingen worden gebruikt om de verkeersstromen van werknemers vast te leggen en te integreren met interne systemen;
- Het doel van Google is niet om add-ons voor het blokkeren van advertenties te ondermijnen of te onderdrukken, maar om de creatie van veiligere en krachtigere advertentieblokkers mogelijk te maken;
- De terughoudendheid om de blokkerende werking van de webRequest API samen met de nieuwe declarativeNetRequest te verlaten, wordt verklaard door de wens om de toegang van add-ons tot vertrouwelijke gegevens te beperken. Als u de webRequest API ongewijzigd laat, zullen de meeste add-ons niet het veiligere declarativeNetRequest gebruiken, aangezien de meeste ontwikkelaars bij het kiezen tussen beveiliging en functionaliteit meestal voor functionaliteit zullen kiezen.
:
- Uitgevoerd door add-on-ontwikkelaars laten een onbeduidende algehele impact zien op de prestaties van add-ons voor advertentieblokkering (tijdens het testen werden de prestaties van verschillende add-ons vergeleken, maar zonder rekening te houden met de overhead van een aanvullend proces dat de uitvoering van handlers coördineert in de blokkeermodus van de webRequest-API);
- Het is niet praktisch om volledig te stoppen met het ondersteunen van een API die actief wordt gebruikt in add-ons. In plaats van het te verwijderen, kunt u een afzonderlijke toestemming toevoegen en de geschiktheid van het gebruik ervan in add-ons strikt controleren, wat de auteurs van veel populaire add-ons ervan zou weerhouden hun producten volledig te herwerken en te voorkomen dat de functionaliteit wordt verminderd;
- Om de overheadkosten te verlagen, kunt u de API niet verwijderen, maar opnieuw maken op basis van het Promise-mechanisme, vergelijkbaar met de implementatie van webRequest in Firefox;
- Het voorgestelde alternatief, declarativeNetRequest, dekt niet alle behoeften van add-on-ontwikkelaars op het gebied van advertentieblokkering en beveiliging/privacy, aangezien het geen volledige controle biedt over netwerkverzoeken, het gebruik van aangepaste filteralgoritmen niet toestaat en geen het gebruik van complexe regels die elkaar overlappen, afhankelijk van de omstandigheden;
- Met de huidige status van de declarativeNetRequest API is het onmogelijk om de bestaande functionaliteit van de uBlock Origin- en uMatrix-add-ons ongewijzigd opnieuw te creëren, en maakt ook de verdere ontwikkeling van een NoScript-poort voor Chrome zinloos;
- Zorgen over privacy zijn vergezocht, omdat de alleen-lezen, niet-blokkerende modus van de webRequest API behouden blijft en kwaadwillende add-ons nog steeds in staat stelt al het verkeer te controleren, maar niet de mogelijkheid biedt om dit op het internet te verstoren. fly (inhoud wijzigen, uw advertenties plaatsen, miners uitvoeren en de inhoud van de invoerformulieren analyseren kan worden gebruikt nadat de pagina is geladen);
- Browser-ontwikkelaars , и , gebouwd op de Chromium-engine, zijn van plan ondersteuning voor de webRequest-blokkeermodus in hun producten achter te laten.
Bron: opennet.ru