Simeon Vincent, Chrome Extensions Developer Advocate, Chrome-teamleider, Google's huidige standpunt over de derde herziening van het Chrome-manifest, veel add-ons om ongepaste inhoud te blokkeren en de veiligheid te waarborgen. Het bedrijf is niet van plan af te zien van het oorspronkelijke plan om te stoppen met het ondersteunen van de blokkeringsmodus van de webRequest-API, waarmee u de geaccepteerde inhoud direct kunt wijzigen. Er wordt alleen een uitzondering gemaakt voor de Enterprise-editie van Chrome (), waardoor de webRequest API-ondersteuning intact blijft.
Voor gewone Chrome API-gebruikers zal beperkt zijn tot alleen-lezen modus. Er is een declaratieve API voorgesteld om de webRequest API voor contentfiltering te vervangen , dat slechts een beperkt deel van de functies omvat die worden gebruikt in moderne adblockers. In feite wordt in plaats van zijn eigen handlers die volledige toegang hebben tot netwerkverzoeken, een kant-en-klare universele ingebouwde filterengine aangeboden die blokkeerregels zelf verwerkt. Met de declarativeNetRequest API kunt u bijvoorbeeld niet uw eigen filteralgoritmen gebruiken en kunt u geen complexe regels maken die elkaar overlappen, afhankelijk van de voorwaarden.
De ontwikkelaars van ad-blocking add-ons hebben zich gezamenlijk voorbereid , waarin de tekortkomingen van de declarativeNetRequest API werden opgesomd. Google was het eens met veel van de opmerkingen en voegde de declarativeNetRequest API toe. Er is met name ondersteuning toegevoegd voor het dynamisch wijzigen en toevoegen van regels, en het is mogelijk geworden om HTTP-headers te verwijderen, maar alleen die in de witte lijst (Referer, Cookie, Set-Cookie). Er zijn plannen om ondersteuning te implementeren voor het toevoegen en vervangen van HTTP-headers (bijvoorbeeld voor het vervangen van Set-Cookie- en CSP-richtlijnen) en de mogelijkheid om verzoekparameters te verwijderen en te vervangen.
Een conceptversie van de derde versie van het manifest, die de lijst met functies en bronnen van Chrome-add-ons definieert, zal naar verwachting in de komende maanden worden gebruikt voor tests in experimentele builds van Chrome Canary.
Tegelijkertijd blijft de motivatie voor het verbieden van wijzigingen in de geaccepteerde inhoud via de webRequest API niet helemaal duidelijk. Beweringen dat de blokkeermodus van de webRequest API een negatieve invloed heeft op de prestaties, aangezien de browser wacht op de voltooiing van de voltooiingshandler voordat de pagina wordt weergegeven, houdt geen stand bij nauwkeurig onderzoek. Eerder uitgevoerd De prestaties van ad-blocking add-ons hebben aangetoond dat de latentie die ze introduceren verwaarloosbaar is. Gemiddeld vertraagt het gebruik van een blocker de uitvoering van een verzoek met slechts een fractie van milliseconden, wat verwaarloosbaar is tegen de algemene achtergrond.
Het tweede argument, gerelateerd aan de wens om gebruikers te beschermen tegen ongecontroleerde toegang tot content-add-ons, ziet er ook niet overtuigend uit, aangezien je in plaats van de al lang bestaande en algemene functionaliteit in legitieme add-ons te verwijderen, een nieuw type add-ons zou kunnen toevoegen. toestemming en geef de gebruiker de uiteindelijke keuze, installeer een add-on die volledige toegang heeft tot netwerkverzoeken of niet. Bovendien heeft Google de ondersteuning verlaten voor het gebruik van de webRequest-API in de modus alleen-lezen, waardoor volledige verkeersmonitoring mogelijk is, maar er geen interferentie op laag niveau mee is.
Add-ons kunnen de inhoud van gedownloade webpagina's wijzigen via andere API's (kwaadaardige add-ons kunnen bijvoorbeeld nog steeds hun advertenties weergeven, mijnwerkers uitvoeren en de inhoud van invoerformulieren analyseren).
Raymond Hill, auteur van de systemen voor het blokkeren van ongewenste inhoud uBlock Origin en uMatrix, is sterk genoeg de reactie van een Google-vertegenwoordiger en zinspeelde op demagogie en spelletjes achter de schermen waarin Google, onder het mom van een goede kans, zijn zakelijke belangen op het gebied van online adverteren probeert te bevorderen, controle probeert te krijgen over zijn filtermechanismen en rechtvaardigen deze acties in de ogen van het grote publiek.
Hij heeft nooit overtuigende argumenten gekregen voor de noodzaak om de veelgebruikte en populaire API onder ontwikkelaars van add-ons te stoppen. Volgens Raymond is prestatieverlies geen argument, aangezien pagina's langzaam laden vanwege hun opgeblazen gevoel, en niet vanwege het gebruik van de blokkerende webRequest-modus in correct geïmplementeerde add-ons. Als Google echt om prestaties gaf, zouden ze webRequest opnieuw hebben ontworpen op basis van de , naar analogie met webRequest in Firefox.
Volgens Raymond is de strategie van Google om de juiste balans te vinden tussen het uitbreiden van het gebruikersbestand van Chrome en de zakelijke schade veroorzaakt door het gebruik van content blockers. In de eerste fase van de uitbreiding van Chrome moest Google het opnemen tegen adblockers als een van de meest populaire add-ons onder gebruikers. Maar nadat Chrome de overhand kreeg, probeerde het bedrijf de balans in zijn voordeel te doen doorslaan en de blokkering onder controle te krijgen door reclame te maken om ongepaste advertentieblokkering in Chrome in te sluiten. De webRequest API verslaat dit doel, aangezien de controle over het blokkeren van inhoud nu in handen is van externe ontwikkelaars van advertentieblokkering.
Bron: opennet.ru