De komende Manifest V3 voor Google Chrome-extensies zullen de manier veranderen waarop adblockers in Chrome werken. Is dit de juiste weg voorwaarts voor adblockers en Google?
Google Chrome is de populairste platformonafhankelijke webbrowser die momenteel op de markt verkrijgbaar is, claimt 62,7% van het wereldwijde browsergebruiksaandeel tot mei 2019, waarbij Apple's Safari op de tweede plaats kwam met 15,89% en Mozilla's Firefox met 5,07%. Vanwege zijn leeuwendeel hebben de kleinste veranderingen die Google Chrome doorvoert voor zijn platform gevolgen voor miljoenen gebruikers over de hele wereld. Dus toen Google de volgende manifestversie van de extensies aankondigde in de vorm van Manifest V3 voor Google Chrome Extensions, wisten we dat we stonden een aantal grote veranderingen te wachten, vooral toen bekend werd dat Google een contentblocker-API in Chrome inbouwde zelf.
Wat is Manifest V3?
Als je een actieve Chrome-gebruiker bent, maak je ongetwijfeld gebruik van enkele extensies. Extensies zijn kleine softwareprogramma's die de surfervaring aanpassen met behulp van de
Sinds eind vorig jaarheeft Google gewerkt aan 'Manifest V3', een reeks voorgestelde wijzigingen aan het Chrome Extensions-platform die kunnen worden geclassificeerd als 'brekende wijzigingen'. Zoals de openbaar discussiedocument voor Manifest V3 Volgens staten is de manifestversie van de extensie een mechanisme om bepaalde mogelijkheden te beperken tot een bepaalde klasse extensies. Deze beperkingen kunnen de vorm hebben van een minimumversie of een maximumversie. Door te beperken tot een minimumversie zijn nieuwere API's of mogelijkheden alleen beschikbaar voor nieuwere extensies terwijl het beperken tot een maximale manifestversie het mogelijk maakt dat oudere API's of mogelijkheden geleidelijk worden aangepast verouderd.
In eenvoudiger bewoordingen stelt een nieuwe manifestversie Chrome in staat API's en functies te beperken tot deze nieuwe manifestversie om ontwikkelaars van extensies te dwingen om weg te migreren van bepaalde oudere API's vanwege hun negatieve impact op de gebruiker ervaring. Het implementeren van een uitbreiding in Manifest V3 zou theoretisch sterkere garanties moeten bieden vanuit het perspectief van veiligheid, privacy en prestaties.
Hoewel er een breed scala aan veranderingen is beschreven in Manifest V3, heeft de meest controversiële verandering betrekking op het besluit van Google om de blokkeermogelijkheden in de bestaande systemen te beperken. chrome.webRequest API (en richt de API op observatie in plaats van op blokkeren) en presenteer deze blokkerende mogelijkheden vervolgens via een nieuwe chrome.declarativeNetRequest API. Deze specifieke verandering heeft heeft de gemeenschap in vuur en vlam gezet omdat het zich uiteindelijk richt op het advertentieblokkeringsmechanisme van de beroemde advertentieblokkeringsextensie, uBlock-oorsprong, en heeft directe gevolgen voor de meer dan 10 miljoen gebruikers.
Voordat we dit probleem aanpakken, kijken we eerst hoe de webAanvraag API vergelijkt met declaratieveNetRequest API.
Web Request API en Declarative Net Request API
Het heden
De officiële beschrijving van Web Request beschrijft de API als volgt:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Met webverzoek verzendt Chrome alle de gegevens in een netwerkverzoek naar het toestel dat ernaar luistert. De extensie heeft dan de kans om het verzoek te evalueren en Chrome te instrueren wat er met het verzoek moet gebeuren: het toestaan, blokkeren of met enkele aanpassingen verzenden.
Volg de reeks gebeurtenissen om te begrijpen wat er gebeurt als extensies de Web Request API gebruiken. Wanneer een gebruiker met een geïnstalleerde Web Request-extensie op een link klikt, informeert Chrome de extensie dat er een gegevensverzoek is gedaan voordat het verzoek de server bereikt. De extensie kan ervoor kiezen om het verzoek in dit stadium te wijzigen. De server reageert dan, maar het antwoord gaat opnieuw via de extensie en de extensie kan bepalen of het antwoord moet worden aangepast. Chrome geeft vervolgens de pagina uiteindelijk weer en de gebruiker kan het resultaat van zijn klikactie bekijken.
Terwijl Chrome het overhandigt alle gegevens in een netwerkverzoek, extensies die de Web Request API gebruiken, hebben toegang tot het lezen en wijzigen van alles wat een gebruiker op internet doet. Dus hoewel contentblokkers zoals uBlock Origin verstandig gebruik maken van het potentieel van deze API, beweert Google dat andere extensies met kwaadaardige bedoelingen hebben deze misbruikt om toegang te krijgen tot de persoonlijke gegevens van gebruikers informatie. Volgens Google maakt 42% van de kwaadaardige extensies sinds januari 2018 gebruik van de Web Request API. Google beweert ook dat er "aanzienlijke prestatiekosten" zijn verbonden aan de API als blokkerende versie ervan vereist een aanhoudend en vaak langdurig proces dat fundamenteel onverenigbaar is met ‘luie’ processen.
Met Manifest V3 stelt Google voor om deze API in zijn blokkerende vorm te beperken. Als alternatief biedt Google de Declarative Net Request API.
De toekomst
De officiële beschrijving van Declarative Net Request beschrijft de API als volgt:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Met Declarative Net Request hoeft Chrome niet alle informatie over een verzoek naar de luisterextensie te sturen. In plaats daarvan registreert de extensie regels bij Chrome die de browser vooraf vertellen wat te doen als bepaalde soorten verzoeken worden gezien.
De extensie specificeert vooraf de regels. Het verzoek van de gebruiker wordt vervolgens door de browser (en niet door de extensie) aan deze regel getoetst. De actie wordt ook door de browser ondernomen en de pagina wordt vervolgens weergegeven. Google vermeldt dat ze hierdoor efficiëntie kunnen garanderen, omdat ze controle kunnen uitoefenen over het algoritme dat het resultaat bepaalt en inefficiënte regels kunnen voorkomen of uitschakelen. Het biedt ook betere privacygaranties voor de eindgebruiker, omdat details van het netwerkverzoek niet aan de extensie worden blootgesteld. Omdat hardnekkige en langlopende processen niet meer nodig zijn (aangezien de regels vooraf worden geregistreerd), beweert Google dat deze aanpak brengt ook prestatieverbeteringen met zich mee die uitbreidingen aanzienlijk haalbaarder zullen maken als de middelen beperkt zijn platforms.
Declarative Net Request zal beschikbaar zijn voor zowel Manifest V2 (huidig) als Manifest V3, maar het zal de belangrijkste manier zijn waarop Google toestaat dat netwerkverzoeken worden gewijzigd in Manifest V3.
De controverse
De veranderingen van Google lijken logisch totdat je de andere kant van het verhaal hoort, vooral die van adblockers. Deze specifieke API-migratie wordt gezien als Google's manier om adblockers uit te schakelen, omdat het de manier waarop een van de populairste adblockers werkt fundamenteel verandert. Dit sluit aan bij de ‘theorie’ dat Google meer gemotiveerd is voor deze verandering vanuit zakelijk perspectief dan vanuit het perspectief van gebruikersveiligheid. Google is voor zijn inkomsten immers sterk afhankelijk van advertenties, en adblockers worden op dit vlak gezien als een directe bedreiging voor de klanten van Google, zoals bleek uit Alfabet's SEC-formulier 10-K-aanvraag uit 2018 (via Het register):
Nieuwe en bestaande technologieën kunnen van invloed zijn op ons vermogen om advertenties aan te passen en/of kunnen advertenties online blokkeren, wat schadelijk zou zijn voor ons bedrijf.
Er zijn technologieën ontwikkeld om aanpasbare advertenties moeilijker te maken of om de weergave van advertenties bij sommige providers helemaal te blokkeren van de onlinediensten beschikt over geïntegreerde technologieën die mogelijk de kernfunctionaliteit van digitale diensten van derden kunnen aantasten reclame. Het grootste deel van onze Google-inkomsten komt voort uit vergoedingen die aan ons worden betaald in verband met de online weergave van advertenties. Als gevolg hiervan zouden dergelijke technologieën en hulpmiddelen een negatieve invloed kunnen hebben op onze bedrijfsresultaten.
Google moest een verklaring vrijgeven om dit aan te pakken, waarbij het zijn standpunt herhaalt dat de verandering in het belang is van de privacy van gebruikers en niet een directe aanval op adblockers is:
We voorkomen niet de ontwikkeling van advertentieblokkers en voorkomen niet dat gebruikers advertenties blokkeren. In plaats daarvan willen we ontwikkelaars, inclusief inhoudblokkers, helpen extensies te schrijven op een manier die de privacy van gebruikers beschermt.
Er moet worden verwezen naar twee van de meest populaire advertentieblokkers die beschikbaar zijn in Google Chrome: uBlock-oorsprong En Adblock Plus, die beide verschillende benaderingen hanteren om hetzelfde resultaat van inhoudblokkering te bereiken. uBlock Origin is sterk afhankelijk van de Web Request API en de gemeenschap heeft in de loop der jaren de voorkeur gegeven aan deze extensie. Adblock Plus en andere extensies voor het blokkeren van inhoud zijn ook afhankelijk van het blokkeergedeelte van Web Request, dus wijzigingen aan deze API zullen uiteindelijk op zijn minst in zekere zin invloed hebben op de meeste inhoudblokkers.
De poging van Google om Web Request af te schaffen zal in wezen uBlock Origin in zijn huidige formaat vernietigen, iets dat inderdaad veel gebruikers zal treffen. Hoewel gebruikers zonder loyaliteit (en zonder de intentie zich bezig te houden met de manier waarop het advertentieblok wordt bereikt) alternatieve oplossingen zullen vinden die hun eigen nadelen met zich meebrengen, zal het onmogelijk worden voor loyalisten en enthousiastelingen om nieuwe filterengine-ontwerpen te bedenken om de verschillende technieken te omzeilen die websites uiteindelijk zullen bedenken om adblockers op deze specifieke API te bestrijden.
Er werd ook voorgesteld dat Declarative Net Request een vrij beperkte filterengine zou zijn, zoals het was aanvankelijk gepland een limiet van 30.000 regels hebben voor statische filterregels per extensie (regels die tijdens de installatie worden gedeclareerd); en een regellimiet van 5.000 voor dynamische filterregels per extensie (regels die na installatie kunnen worden toegevoegd). Eventuele overtollige regels worden genegeerd, wat een probleem is, aangezien EasyList voor Adblock Plus zelf 70.000 regels heeft, terwijl uBlock Origin kan worden geconfigureerd om met meer dan 100.000 regels te werken. Na de aanvankelijke reactie van de gemeenschap, Google reageerde door te beloven de statische regellimiet te wijzigen van 30.000 regels per extensie naar een mondiaal maximum van 150.000 regels. Dit heeft vervolgens als neveneffect dat gebruikers ervan worden weerhouden andere scripts met veel regels te gebruiken in combinatie met een advertentieblokkering, zodat gebruikers moeten jongleren met hun voorkeuren.
Afgezien van de beperkte filterlimiet, Declarative Net Request kan alleen omleiden naar statische URL's, dus er is geen ondersteuning voor patroonvergelijking. uBlock Origin is sterk afhankelijk van patroonmatching en de extensie-ontwikkelaar aangegeven dat het niet mogelijk is om dit achteraf aan te passen het matching-algoritme van zijn extensie om aan de API-vereiste te voldoen. De API zou ook een volledige update van de extensie vereisen om eenvoudigweg de filterlijst bij te werken, wat een veel te frequente activiteit zou zijn gezien de frequentie waarmee deze filterlijsten worden bijgewerkt. Uiteraard zouden deze updates ook afhangen van de beoordelingscriteria en -processen van Google voor extensies.
Aan de andere kant heeft Google altijd bij zijn standpunt gebleven dat het zijn bedoeling is om afstand te nemen van Web Request veiligheidsperspectief, omdat de Web Request API in zijn huidige vorm te krachtig is en er veel ruimte voor openlaat misbruik. Dit misbruik is niet alleen theoretisch, aangezien Google heeft vermeld dat 42% van de kwaadaardige extensies deze API hebben misbruikt. Apple Safari's Content Blocker-API is om vergelijkbare redenen ontworpen als Declarative Net Request, omdat er minder ruimte is voor misbruik door een malafide ontwikkelaar. Op het nerfed-webverzoek zouden netwerkverzoeken nog steeds waarneembaar zijn, maar zouden ze machtigingen voor de relevante hosts nodig hebben. Met Manifest V3 veranderen de hostmachtigingen ook aanzienlijk en kunnen ze niet langer op een algemene manier worden verleend tijdens de installatie.
Google heeft ook prestatie-overheads gebruikt als motivatie voor de overstap. Evaluatie van netwerkverzoeken vindt plaats in de JavaScript-thread van de extensie, wat kostbaar kan zijn voor de prestaties. Als weerlegging vermeldt de ontwikkelaar van uBlock Origin dat zijn extensie geen noemenswaardige prestatieboete met zich meebrengt zelfs als er maar liefst 140.000 statische filters moeten worden afgedwongen. Er wordt beweerd dat de gemaakte kosten gemakkelijk kunnen worden terugverdiend door de bronnen die niet kunnen worden gedownload van externe servers en dus niet worden verwerkt door de browser.
Hoewel Google deze redenering niet gebruikt, kan er ook één argument tegen Web Request worden aangevoerd vanwege de efficiëntie bij het blokkeren van advertenties. Als een extensie bij Web Request niet op tijd reageert (vanwege een vertraging of een crash), wordt het netwerkverzoek duidelijk toegestaan, waardoor advertenties door de advertentieblokkering glippen. Declarative Net Request daarentegen zou niet onder dit nadeel lijden. In plaats daarvan zullen advertenties doorkomen als ze niet binnen de statische regels vallen, en dit zal vaker wel dan niet gebeuren.
Conclusie
Uit de bovenstaande uitleg wordt duidelijk dat Declarative Net Request geen 1:1-functionaliteitskloon is voor het blokkeren mogelijkheden van de Web Request API, en ontwikkelaars van extensies zullen ongetwijfeld teleurgesteld zijn als hun harde werk hierdoor wordt belemmerd zulke veranderingen. Maar de redenering van Google is ook van belang: Web Request is te krachtig, en dat moet ook zo zijn ingeperkt in het grotere belang van de gebruikersgemeenschap (die bestaat uit gemiddelde gebruikers en liefhebbers).
De stap naar Declarative Net Request had ook een positieve PR-zet kunnen zijn: Google voegt tenslotte een ingebouwde contentblocker-API toe aan Chrome! Maar aangezien de nieuwe API zijn eigen zware beperkingen met zich meebrengt, ziet de gemeenschap dit terecht als een knipoog. In een ideale wereld had Google de werking van adblockers zoals uBlock Origin moeten onderzoeken voordat hij de nieuwe API naar voren bracht. Zoals het er nu uitziet, zou de nieuwe API verdere versoepelingen van de regellimieten kunnen gebruiken om tegemoet te komen aan scenario's waarin gebruikers twee filterzware extensies zouden willen gebruiken.
Volgens Het register, zullen de eerste builds met Manifest V3-wijzigingen vanaf juli 2019 beschikbaar zijn. We hopen dat Google met deze builds rekening houdt met de feedback van de gemeenschap van extensie-ontwikkelaars.
Speciale dank aan XDA's hoofdredacteur Mishaal Rahman voor zijn input en hulp!
Bewerken: het artikel stelde de werking van Adblock Plus ten onrechte gelijk aan die van de Declarative Net Request API. Het artikel is dienovereenkomstig aangepast. Adblock Plus zal ook worden beïnvloed door het verwijderen van de blokkeermogelijkheden van de Web Request API.