Den kommande Manifest V3 för Google Chrome Extensions kommer att ändra hur annonsblockerare fungerar i Chrome. Är detta rätt väg framåt för annonsblockerare och Google?
Google Chrome är den mest populära webbläsaren för flera plattformar som finns på marknaden just nu, hävdar 62,7 % av den globala webbläsaranvändningsandelen fram till maj 2019, med Apples Safari på andra plats med 15,89 % och Mozillas Firefox med 5,07 %. På grund av sin lejonpart kommer de minsta förändringar som Google Chrome gör för sin plattform att påverka miljontals användare runt om i världen. Så när Google tillkännagav nästa tilläggsmanifestversion i form av Manifest V3 för Google Chrome Extensions, visste vi att vi stod inför stora förändringar, särskilt när det kom fram att Google byggde in ett API för innehållsblockerare i Chrome sig.
Vad är Manifest V3?
Om du är en aktiv Chrome-användare använder du utan tvekan några tillägg. Tillägg är små program som anpassar webbupplevelsen med hjälp av API: er som webbläsaren tillhandahåller
Eftersom slutet av förra året, har Google arbetat med "Manifest V3", en uppsättning föreslagna ändringar av Chrome Extensions-plattformen som kan klassificeras som "brytande ändringar." Som den offentligt diskussionsdokument för Manifest V3 sägs, är tilläggsmanifestversionen en mekanism för att begränsa vissa möjligheter till en viss klass av tillägg. Dessa begränsningar kan vara i form av antingen en lägsta version eller en maxversion. Genom att begränsa till en minimiversion kan nyare API: er eller funktioner endast vara tillgängliga för nyare tillägg medan en begränsning till en maximal manifestversion tillåter att äldre API: er eller funktioner gradvis kan göras utfasad.
I enklare termer tillåter en ny manifestversion Chrome att begränsa API: er och funktioner till denna nya manifestversion, i för att tvinga tilläggsutvecklare att migrera bort från vissa äldre API: er på grund av deras negativa inverkan på användaren erfarenhet. Att implementera en förlängning i Manifest V3 borde teoretiskt sett ge starkare garantier ur perspektiven säkerhet, integritet och prestanda.
Även om det finns ett brett spektrum av förändringar som beskrivs i Manifest V3, är den mest kontroversiella förändringen relaterad till Googles beslut att begränsa blockeringsförmågan som finns i den befintliga chrome.webRequest API (och fokusera API: n kring observation istället för blockering) och presentera sedan dessa blockeringsförmågor genom en ny chrome.declarativeNetRequest API. Denna speciella förändring har uppflammade samhället eftersom det slutar inrikta sig på annonsblockeringsmekanismen i det berömda annonsblockeringstillägget, uBlock Ursprung, och direkt påverkar dess 10 miljoner+ användare.
Innan vi tar upp det här problemet, låt oss ta en titt på hur webRequest API jämför med declarativeNetRequest API.
Web Request API och Declarative Net Request API
Nuet
Web Requests officiella beskrivning beskriver API: t enligt följande:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Med Web Request skickar Chrome Allt data i en nätverksbegäran till anknytningen som lyssnar efter den. Tillägget har sedan en chans att utvärdera begäran och instruera Chrome om vad den ska göra med begäran: tillåta den, blockera den eller skicka den med några ändringar.
Följ händelseförloppet för att förstå vad som händer när tillägg använder Web Request API. När en användare med ett Web Request-tillägg installerat klickar på en länk, informerar Chrome tillägget om att en databegäran har gjorts innan begäran når servern. Förlängningen kan välja att ändra begäran i detta skede. Servern svarar sedan, men svaret går återigen genom tillägget, och tillägget kan diktera om svaret behöver ändras. Chrome renderar sedan äntligen sidan och användaren kan se resultatet av sin klickåtgärd.
Som Chrome lämnar över all data i en nätverksbegäran, tillägg som använder Web Request API har tillgång till att läsa och ändra allt som en användare gör på webben. Så även om innehållsblockerare som uBlock Origin på ett klokt sätt utnyttjar potentialen hos detta API, hävdar Google det andra tillägg med skadliga avsikter har missbrukat detsamma för att få tillgång till användarnas personliga information. Enligt Google har 42 % av skadliga tillägg använt Web Request API sedan januari 2018. Google hävdar också att det är "betydande prestationskostnader" involverade med API: et som blockeringsversion av det kräver en ihållande och ofta långvarig process som i grunden är oförenlig med "lat" processer.
Med Manifest V3 föreslår Google att detta API begränsas i dess blockeringsform. Som ett alternativ tillhandahåller Google Declarative Net Request API.
Framtiden
Declarative Net Requests officiella beskrivning beskriver API: t enligt följande:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Med Declarative Net Request behöver Chrome inte skicka all information om en begäran till avlyssningstillägget. Istället registrerar tillägget regler med Chrome som talar om för webbläsaren i förväg om vad den ska göra om vissa typer av förfrågningar ses.
Tillägget specificerar sina regler i förväg. Användarnas begäran matchas sedan mot denna regel av webbläsaren (och inte tillägget), och åtgärden utförs också av webbläsaren, och sidan renderas därefter. Google nämner att detta tillåter dem att säkerställa effektivitet eftersom de kan utöva kontroll över algoritmen som bestämmer resultatet och kan förhindra eller inaktivera ineffektiva regler. Det ger också bättre integritetsgarantier för slutanvändaren eftersom detaljerna i nätverksförfrågan inte exponeras för tillägget. Eftersom ihållande och långvariga processer inte längre är nödvändiga (eftersom reglerna är registrerade i förväg), hävdar Google att detta tillvägagångssätt ger också prestandaförbättringar som kommer att göra tillägg betydligt mer lönsamma på resursbegränsade plattformar.
Declarative Net Request kommer att vara tillgänglig för både Manifest V2 (nuvarande) och Manifest V3, men det kommer att vara det primära sättet som Google kommer att tillåta att nätverksbegäranden ändras i Manifest V3.
Kontroversen
Googles ändringar verkar vara vettiga tills du hör den andra sidan av historien, främst annonsblockerare. Denna speciella API-migrering ses som Googles sätt att döda annonsblockerare eftersom det i grunden förändrar hur en av de mest populära annonsblockerarna fungerar. Detta knyter an till "teorin" att Google är motiverat för denna förändring mer ur ett affärsperspektiv än ur användarsäkerhetsperspektiv. När allt kommer omkring är Google starkt beroende av reklam för sina intäkter, och annonsblockerare uppfattas som ett direkt hot mot Googles kunder på denna front, vilket avslöjades genom Alphabets 2018 SEC Form 10-K-fil (via Registret):
Ny och befintlig teknik kan påverka vår förmåga att anpassa annonser och/eller blockera annonser online, vilket skulle skada vår verksamhet.
Teknik har utvecklats för att göra anpassningsbara annonser svårare eller för att blockera visningen av annonser helt och hållet och vissa leverantörer av onlinetjänster har integrerad teknik som potentiellt kan försämra kärnfunktionaliteten hos tredje part digitalt reklam. De flesta av våra Google-intäkter härrör från avgifter som betalas till oss i samband med visning av annonser online. Som ett resultat av detta kan sådana tekniker och verktyg ha en negativ inverkan på våra verksamhetsresultat.
Google var tvungen släppa ett uttalande för att ta itu med detta och upprepar sin ståndpunkt att förändringen är i användarnas integritets intresse och inte en direkt attack mot annonsblockerare:
Vi hindrar inte utvecklingen av annonsblockerare eller hindrar användare från att blockera annonser. Istället vill vi hjälpa utvecklare, inklusive innehållsblockerare, att skriva tillägg på ett sätt som skyddar användarnas integritet.
Hänvisning måste göras till två av de mest populära annonsblockerarna som finns tillgängliga på Google Chrome: uBlock Ursprung och Adblock plus, som båda använder olika tillvägagångssätt för att uppnå samma resultat av innehållsblockering. uBlock Origin är starkt beroende av Web Request API, och communityn har föredrat denna tillägg under åren. Adblock Plus och andra innehållsblockerande tillägg förlitar sig också på den blockerande delen av Web Request, så ändringar av detta API kommer att påverka de flesta innehållsblockerare i åtminstone viss kapacitet.
Googles strävan att fasa ut Web Request kommer i huvudsak att döda uBlock Origin i sitt nuvarande format, något som verkligen kommer att påverka många användare. Medan användare utan lojalitet (och utan avsikt att bry sig om hur annonsblockeringen uppnås) kommer att hitta alternativa lösningar som kommer med sina egna nackdelar, kommer det att bli omöjligt för lojalister och entusiaster att komma med nya filtermotordesigner för att kringgå de olika tekniker som webbplatser så småningom kommer att komma med för att bekämpa annonsblockerare på detta specifika API.
Declarative Net Request föreslogs också vara en ganska begränsad filtreringsmotor, som den var ursprungligen planerat att ha en gräns på 30 000 regler för statiska filterregler per tillägg (regler som deklareras under installationen); och 5 000 regelgräns för dynamiska filterregler per tillägg (regler som kan läggas till efter installation). Eventuella överskottsregler kommer att ignoreras, vilket är lite av ett problem eftersom EasyList för Adblock Plus själv har 70 000 regler, medan uBlock Origin kan konfigureras att köras med över 100 000 regler. Efter den första motreaktionen från samhället, Google svarade genom att lova att ändra den statiska regelgränsen från 30 000 regler per tillägg till ett globalt maximum på 150 000 regler. Detta har då bieffekten att det hindrar användare från att använda andra regeltunga skript i kombination med en annonsblockerare, så användarna måste jonglera med sina preferenser.
Annat än den begränsade filtreringsgränsen, Declarative Net Request kan bara omdirigera till statiska webbadresser, så det finns inget stöd för mönstermatchning. uBlock Origin är starkt beroende av mönstermatchning och tilläggsutvecklaren uppgett att det inte går att eftermontera hans tilläggs matchningsalgoritm för att möta API: s krav. API: et skulle också kräva en komplett tilläggsuppdatering för att helt enkelt uppdatera filterlistan, vilket skulle vara en alldeles för frekvent aktivitet med tanke på frekvensen med vilken dessa filterlistor uppdateras. Naturligtvis skulle dessa uppdateringar också vara beroende av Googles kriterier och processer för förlängningsgranskning.
Å andra sidan har Google alltid upprätthållit sin ståndpunkt att dess avsikt att gå bort från Web Request är från en säkerhetsperspektiv, eftersom Web Request API är för kraftfullt i sin nuvarande form och lämnar ett mycket stort utrymme öppet för missbruk. Detta missbruk är inte bara teoretiskt, eftersom Google har nämnt att 42 % av skadliga tillägg har missbrukat detta API. Apple Safari Content Blocker API designades som Declarative Net Request av liknande skäl, eftersom det finns mindre utrymme för en oseriös utvecklare att utnyttja. På den nervösa webbförfrågan skulle nätverksförfrågningar fortfarande kunna observeras, men de skulle behöva behörigheter för de relevanta värdarna. Med Manifest V3 ändras också värdbehörigheterna avsevärt och de kan inte längre beviljas på ett generellt sätt vid installationstillfället.
Google har också använt prestationskostnader som en motivation för bytet. Utvärdering av nätverksförfrågningar sker i JavaScript-tråden för tillägget, vilket kan vara kostsamt för prestanda. Som ett motbevis nämner uBlock Origins utvecklare att hans förlängning inte medför något betydande prestationspåföljd även när man har så många som 140 000 statiska filter att tillämpa. De uppkomna kostnaderna påstås enkelt återvinnas av de resurser som hindras från att laddas ner från fjärrservrar och därmed inte bearbetas av webbläsaren.
Även om Google inte använder detta resonemang, kan ett argument mot Web Request också framföras för effektivitet med annonsblockering. Med Web Request, om en förlängning inte svarar i tid (på grund av en fördröjning eller en krasch), är nätverkshanteringsbegäran helt enkelt tillåten, vilket låter annonser glida igenom annonsblockeraren. Deklarativ nettoförfrågan skulle å andra sidan inte lida av denna nackdel. Istället kommer annonser att passera om de inte fastnar inom de statiska reglerna, och detta kommer att hända oftare än inte.
Slutsats
Från förklaringarna ovan är det tydligt att Declarative Net Request inte är en 1:1 funktionsklon för blockeringen funktionerna hos Web Request API, och tilläggsutvecklare är skyldiga att bli irriterade när deras hårda arbete kommer att bli handikappat av sådana förändringar. Men Googles resonemang väger också tungt -- Web Request är för kraftfullt, och dess krafter måste vara det inskränkt i användargemenskapens större intresse (som består av genomsnittliga användare tillsammans med entusiaster).
Övergången till Declarative Net Request kunde också ha varit ett positivt PR-drag - trots allt lägger Google till ett inbyggt API för innehållsblockerare i Chrome! Men eftersom det nya API: et kommer med sina egna tunga restriktioner, ser samhället med rätta detta som ett vingklipp. I en idealisk värld borde Google ha utforskat hur annonsblockerare som uBlock Origin fungerar innan de lanserade det nya API: et. Som det ser ut nu kan det nya API: et använda ytterligare uppmjukningar av sina regelgränser för att tillgodose scenarier där användare skulle vilja använda två filtertunga tillägg.
Enligt Registret, kommer de första versionerna med Manifest V3-ändringar att vara tillgängliga från juli 2019 och framåt. Vi hoppas att Google tar emot feedbacken från tilläggsutvecklare med dessa versioner.
Speciellt tack till XDA: s chefredaktör Mishaal Rahman för hans input och hjälp!
Edit: Artikeln likställde felaktigt Adblock Pluss arbete med Declarative Net Request API. Artikeln har ändrats i enlighet med detta. Adblock Plus kommer också att påverkas av borttagningen av Web Request API: s blockeringsmöjligheter.