Den kommende Manifest V3 til Google Chrome-udvidelser vil ændre, hvordan annonceblokering fungerer på Chrome. Er dette den rigtige vej frem for annonceblokkere og Google?
Google Chrome er den mest populære cross-platform webbrowser tilgængelig på markedet lige nu, hævder 62,7 % af den globale browserbrugsandel frem til maj 2019, hvor Apples Safari kommer på andenpladsen med 15,89 % og Mozillas Firefox med 5,07 %. På grund af sin broderpart ender de mindste ændringer, som Google Chrome foretager for sin platform, med at påvirke millioner af brugere rundt om i verden. Så da Google annoncerede den næste udvidelsesmanifestversion i form af Manifest V3 til Google Chrome Extensions, vidste vi, at vi var med til nogle store ændringer, især da det kom frem, at Google indbyggede en indholdsblokerings-API i Chrome sig selv.
Hvad er Manifest V3?
Hvis du er en aktiv Chrome-bruger, bruger du uden tvivl et par udvidelser. Udvidelser er små softwareprogrammer, der tilpasser browsingoplevelsen ved hjælp af
Siden sidst sidste år, har Google arbejdet på "Manifest V3", et sæt foreslåede ændringer til Chrome Extensions-platformen, der kan klassificeres som "breaking changes". Som offentligt diskussionsdokument for Manifest V3 stater, er udvidelsesmanifestversionen en mekanisme til at begrænse visse kapaciteter til en bestemt klasse af udvidelser. Disse begrænsninger kan være i form af enten en minimumsversion eller en maksimumversion. Begrænsning til en minimumsversion tillader, at nyere API'er eller kapaciteter kun er tilgængelige for nyere udvidelser mens begrænsning til en maksimal manifestversion tillader ældre API'er eller kapaciteter at blive gradvist forældet.
I enklere vendinger giver en ny manifestversion Chrome mulighed for at begrænse API'er og funktioner til denne nye manifestversion, i for at tvinge udvidelsesudviklere til at migrere væk fra visse ældre API'er på grund af deres negative indvirkning på brugeren erfaring. Implementering af en udvidelse i Manifest V3 burde teoretisk set give stærkere garantier ud fra perspektiver af sikkerhed, privatliv og ydeevne.
Selvom der er en lang række ændringer skitseret i Manifest V3, vedrører den mest kontroversielle ændring Googles beslutning om at begrænse blokeringsevnerne i den eksisterende chrome.webRequest API (og fokuser API'et omkring observation i stedet for blokering) og præsenterer derefter disse blokeringsevner gennem en ny chrome.declarativeNetRequest API. Denne særlige ændring har opildnede samfundet da det ender med at målrette mod annonceblokeringsmekanismen i den berømte annonceblokeringsudvidelse, uBlock oprindelse, og påvirker direkte dets 10 millioner+ brugere.
Før vi behandler dette problem, lad os tage et kig på, hvordan webRequest API sammenligner med declarativeNetRequest API.
Web Request API og Declarative Net Request API
Gaven
Web Requests officielle beskrivelse beskriver API'et som følger:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Med webanmodning sender Chrome alle dataene i en netværksanmodning til lokalnummeret, der lytter efter det. Udvidelsen har derefter en chance for at evaluere anmodningen og instruere Chrome om, hvad den skal gøre med anmodningen: tillade den, bloker den eller send den med nogle ændringer.
Følg med i rækkefølgen af begivenheder for at forstå, hvad der sker, når udvidelser bruger Web Request API. Når en bruger med en webanmodningsudvidelse installeret klikker på et link, informerer Chrome udvidelsen om, at der er foretaget en dataanmodning, før anmodningen når serveren. Udvidelsen kan vælge at ændre anmodningen på dette trin. Serveren svarer så, men svaret går igen gennem udvidelsen, og udvidelsen kan diktere, om svaret skal ændres. Chrome gengiver derefter siden endelig, og brugeren er i stand til at se resultatet af sin klikhandling.
Som Chrome afleverer alle data i en netværksanmodning, udvidelser, der bruger Web Request API har adgang til at læse og ændre alt, hvad en bruger gør på nettet. Så mens indholdsblokkere som uBlock Origin klogt udnytter potentialet i denne API, hævder Google det andre udvidelser med ondsindede hensigter har misbrugt det samme for at få adgang til brugernes personlige oplysninger Information. Ifølge Google har 42 % af ondsindede udvidelser brugt Web Request API siden januar 2018. Google hævder også, at der er "betydelige ydeevneomkostninger" involveret i API'en som blokeringsversion af det kræver en vedvarende og ofte langvarig proces, som grundlæggende er uforenelig med 'doven' processer.
Med Manifest V3 foreslår Google at begrænse denne API i sin blokeringsform. Som et alternativ leverer Google Declarative Net Request API.
Fremtiden
Declarative Net Requests officielle beskrivelse beskriver API'en som følger:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Med Declarative Net Request behøver Chrome ikke at sende alle oplysninger om en anmodning til lytteudvidelsen. I stedet registrerer udvidelsen regler med Chrome, der fortæller browseren på forhånd, hvad den skal gøre, hvis der ses visse typer anmodninger.
Udvidelsen specificerer sine regler på forhånd. Brugernes anmodning matches derefter mod denne regel af browseren (og ikke udvidelsen), og handlingen udføres også af browseren, og siden gengives efterfølgende. Google nævner, at dette giver dem mulighed for at sikre effektivitet, da de kan udøve kontrol over den algoritme, der bestemmer resultatet, og kan forhindre eller deaktivere ineffektive regler. Det giver også bedre privatlivsgarantier til slutbrugeren, da detaljerne i netværksanmodningen ikke eksponeres for udvidelsen. Da vedvarende og langvarige processer ikke længere er nødvendige (da reglerne er registreret på forhånd), hævder Google, at denne tilgang bringer også præstationsforbedringer, der vil gøre udvidelser væsentligt mere levedygtige på ressourcebegrænsede platforme.
Declarative Net Request vil være tilgængelig for både Manifest V2 (nuværende) og Manifest V3, men det vil være den primære måde, Google vil tillade, at netværksanmodninger ændres i Manifest V3.
Kontroversen
Googles ændringer ser ud til at give mening, indtil du hører den anden side af historien, hovedsageligt annonceblokkere. Denne særlige API-migrering bliver betragtet som Googles måde at dræbe annonceblokkere på, da den fundamentalt ændrer den måde, en af de mest populære annonceblokkere fungerer på. Dette hænger sammen med "teorien" om, at Google er motiveret for denne ændring mere fra et forretningsperspektiv end fra et brugersikkerhedsperspektiv. Når alt kommer til alt er Google stærkt afhængig af annoncering for sin indtjening, og annonceblokering opfattes som en direkte trussel for Googles kunder på denne front, som det blev afsløret gennem Alphabets 2018 SEC Form 10-K indgivelse (via Registeret):
Nye og eksisterende teknologier kan påvirke vores evne til at tilpasse annoncer og/eller kunne blokere annoncer online, hvilket ville skade vores forretning.
Teknologier er blevet udviklet til at gøre tilpassede annoncer sværere eller for at blokere visningen af annoncer helt og nogle udbydere af onlinetjenester har integrerede teknologier, der potentielt kan forringe kernefunktionaliteten af tredjeparts digitale annoncering. De fleste af vores Google-indtægter stammer fra gebyrer betalt til os i forbindelse med visning af annoncer online. Som følge heraf kan sådanne teknologier og værktøjer påvirke vores driftsresultater negativt.
Google var nødt til det frigive en erklæring for at løse dette og gentager sin holdning om, at ændringen er i brugernes privatlivs interesse og ikke et direkte angreb mod annonceblokkere:
Vi forhindrer ikke udviklingen af annonceblokkere eller forhindrer brugere i at blokere annoncer. I stedet vil vi hjælpe udviklere, herunder indholdsblokkere, med at skrive udvidelser på en måde, der beskytter brugernes privatliv.
Der skal henvises til to af de mest populære annonceblokkere, der er tilgængelige på Google Chrome: uBlock oprindelse og Adblock Plus, som begge tager forskellige tilgange for at opnå det samme resultat af indholdsblokering. uBlock Origin er stærkt afhængig af Web Request API, og fællesskabet har valgt at foretrække denne udvidelse gennem årene. Adblock Plus og andre indholdsblokerende udvidelser er også afhængige af den blokerende del af Web Request, så ændringer af denne API vil ende med at påvirke de fleste indholdsblokeringer i det mindste i en vis kapacitet.
Googles pres for at forælde Web Request vil i det væsentlige dræbe uBlock Origin i dets nuværende format, noget der faktisk vil påvirke en masse brugere. Mens brugere uden loyalitet (og uden intention om at genere sig selv med, hvordan annonceblokeringen opnås) vil finde alternative løsninger, der kommer med deres egne ulemper, vil det blive umuligt for loyalister og entusiaster at komme med nye filtreringsmotordesigns for at omgå de forskellige teknikker, som websteder i sidste ende vil komme op med for at bekæmpe annonceblokkere på denne specifikke API.
Declarative Net Request blev også foreslået at være en ret begrænset filtreringsmotor, som den var oprindeligt planlagt at have en 30.000 reglergrænse for statiske filterregler pr. udvidelse (regler, der erklæres under installationen); og 5.000 regelgrænse for dynamiske filterregler pr. udvidelse (regler, der kan tilføjes efter installation). Eventuelle overskydende regler vil blive ignoreret, hvilket er lidt af et problem, da EasyList for Adblock Plus selv har 70.000 regler, mens uBlock Origin kan konfigureres til at køre med over 100.000 regler. Efter den første modreaktion fra samfundet, Google svarede ved at love at ændre den statiske regelgrænse fra 30.000 regler pr. udvidelse til et globalt maksimum på 150.000 regler. Dette har så den bivirkning, at det forhindrer brugere i at bruge andre regeltunge scripts i forbindelse med en annonceblokering, så brugerne bliver nødt til at jonglere med deres præferencer.
Ud over den begrænsede filtreringsgrænse, Declarative Net Request kan kun omdirigere til statiske URL'er, så der er ingen støtte inkluderet til mønstermatchning. uBlock Origin er stærkt afhængig af mønstermatching og udvidelsesudvikleren oplyst, at det ikke er muligt at eftermontere hans udvidelses matchende algoritme for at opfylde API's krav. API'en ville også kræve en komplet udvidelsesopdatering for blot at opdatere filterlisten, hvilket ville være en alt for hyppig aktivitet i betragtning af hyppigheden, hvormed disse filterlister opdateres. Disse opdateringer vil naturligvis også afhænge af Googles kriterier og processer for udvidelsesgennemgang.
På den anden side har Google altid fastholdt sin holdning om, at dens hensigt med at bevæge sig væk fra Web Request er fra en sikkerhedsperspektiv, da Web Request API er for kraftfuld i sin nuværende form og efterlader et meget stort rum til misbrug. Dette misbrug er ikke kun teoretisk, da Google har nævnt, at 42 % af ondsindede udvidelser har misbrugt denne API. Apple Safari Content Blocker API blev designet som Declarative Net Request af lignende årsager, da der er mindre plads for en useriøs udvikler at udnytte. På den nervøse webanmodning ville netværksanmodninger stadig kunne observeres, men de ville have brug for tilladelser på de relevante værter. Med Manifest V3 ændres værtstilladelser også betydeligt, og de kan ikke længere gives på en generel måde på installationstidspunktet.
Google har også brugt præstationsomkostninger som en motivator for skiftet. Evaluering af netværksanmodninger sker i JavaScript-tråden af udvidelsen, hvilket kan være dyrt på ydeevnen. Som en modbevisning nævner uBlock Origins udvikler, at hans udvidelse ikke pådrager sig nogen væsentlig præstationsstraf selv når man har så mange som 140.000 statiske filtre at håndhæve. De afholdte omkostninger hævdes let at kunne inddrives af de ressourcer, der forhindres i at blive downloadet fra fjernservere og dermed ikke behandles af browseren.
Selvom Google ikke bruger denne begrundelse, kan et argument mod Web Request også fremføres for effektivitet med annonceblokering. Med Web Request, hvis en udvidelse ikke reagerer i tide (på grund af en forsinkelse eller et nedbrud), er netværkshåndteringsanmodningen helt klart tilladt, hvilket lader annoncer glide gennem annonceblokeringen. Declarative Net Request ville på den anden side ikke lide under denne ulempe. I stedet vil annoncer passere igennem, hvis de ikke bliver fanget inden for de statiske regler, og det vil ske oftere end ikke.
Konklusion
Ud fra forklaringerne ovenfor er det klart, at Declarative Net Request ikke er en 1:1-funktionsklon til blokeringen funktionerne i Web Request API, og udvidelsesudviklere er nødt til at blive kede af det, når deres hårde arbejde bliver handicappet af sådanne ændringer. Men Googles ræsonnement vejer også tungt - Web Request er for kraftfuld, og dens beføjelser skal være det indskrænket i brugerfællesskabets større interesse (som består af gennemsnitlige brugere sammen med entusiaster).
Bevægelsen mod Declarative Net Request kunne også have været et positivt PR-træk - Google tilføjer trods alt en indbygget indholdsblokerings-API til Chrome! Men da den nye API kommer med sine egne tunge restriktioner, ser samfundet med rette dette som et vingeklipp. I en ideel verden burde Google have undersøgt funktionen af annonceblokkere som uBlock Origin, før de skubbede den nye API frem. Som det ser ud nu, kunne den nye API bruge yderligere lempelser af sine regelgrænser for at imødekomme scenarier, hvor brugere ønsker at bruge to filtertunge udvidelser.
Ifølge Registeret, vil de første builds med Manifest V3-ændringer være tilgængelige fra juli 2019 og fremefter. Vi håber, at Google imødekommer feedbacken modtaget fra udvidelsesudviklerfællesskabet med disse builds.
Særlig tak til XDAs chefredaktør Mishaal Rahman for hans input og assistance!
Rediger: Artiklen sidestillede fejlagtigt Adblock Plus's arbejde med Declarative Net Request API. Artiklen er blevet ændret i overensstemmelse hermed. Adblock Plus vil også blive påvirket af fjernelse af Web Request API's blokeringsfunktioner.