Den kommende Manifest V3 for Google Chrome Extensions vil endre hvordan annonseblokkere fungerer på Chrome. Er dette den rette veien videre for annonseblokkere og Google?
Google Chrome er den mest populære nettleseren på tvers av plattformer tilgjengelig på markedet akkurat nå, krav på 62,7 % av den globale nettleserbruksandelen frem til mai 2019, med Apples Safari på andreplass med 15,89 % og Mozillas Firefox med 5,07 %. På grunn av brorparten vil de minste endringene som Google Chrome foretar for plattformen sin, påvirke millioner av brukere over hele verden. Så da Google kunngjorde neste utvidelsesmanifestversjon i form av Manifest V3 for Google Chrome Extensions, visste vi at vi var inne for noen store endringer, spesielt da det kom frem at Google bygde inn et innholdsblokkerings-API i Chrome seg selv.
Hva er Manifest V3?
Hvis du er en aktiv Chrome-bruker, bruker du utvilsomt noen få utvidelser. Utvidelser er små programmer som tilpasser nettleseropplevelsen ved å bruke API-er som nettleseren tilbyr
Siden sent i fjor, har Google jobbet med «Manifest V3», et sett med foreslåtte endringer i Chrome Extensions-plattformen som kan klassifiseres som «brytende endringer». Som offentlig diskusjonsdokument for Manifest V3 stater, er utvidelsesmanifestversjonen en mekanisme for å begrense visse funksjoner til en viss klasse av utvidelser. Disse begrensningene kan være i form av enten en minimumsversjon eller en maksimumsversjon. Begrensning til en minimumsversjon gjør at nyere APIer eller funksjoner bare er tilgjengelige for nyere utvidelser mens begrenset til en maksimal manifestversjon tillater eldre APIer eller funksjoner å bli gradvis avviklet.
Enkelt sagt lar en ny manifestversjon Chrome begrense APIer og funksjoner til denne nye manifestversjonen, i for å tvinge utvidelsesutviklere til å migrere bort fra visse eldre APIer på grunn av deres negative innvirkning på brukeren erfaring. Implementering av en utvidelse i Manifest V3 burde teoretisk sett gi sterkere garantier fra perspektivene sikkerhet, personvern og ytelse.
Selv om det er et bredt spekter av endringer skissert i Manifest V3, er den mest kontroversielle endringen knyttet til Googles beslutning om å begrense blokkeringsmulighetene som finnes i den eksisterende chrome.webRequest API (og fokuser API-en rundt observasjon i stedet for blokkering) og presenter deretter disse blokkeringsevnene gjennom en ny chrome.declarativeNetRequest API. Denne spesielle endringen har betent samfunnet når den ender opp med å målrette annonseblokkeringsmekanismen til den berømte annonseblokkeringsutvidelsen, uBlock Origin, og påvirker direkte 10 millioner+ brukere.
Før vi tar opp dette problemet, la oss ta en titt på hvordan webRequest API sammenligner med declarativeNetRequest API.
Web Request API og Declarative Net Request API
Nåtiden
Web Requests offisielle beskrivelse beskriver API som følger:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Med nettforespørsel sender Chrome alle dataene i en nettverksforespørsel til utvidelsen som lytter etter den. Utvidelsen har da en sjanse til å evaluere forespørselen og instruere Chrome om hva den skal gjøre med forespørselen: tillate den, blokker den eller send den med noen modifikasjoner.
Følg hendelsesforløpet for å forstå hva som skjer når utvidelser bruker Web Request API. Når en bruker med en Web Request-utvidelse installert klikker på en kobling, informerer Chrome utvidelsen om at en dataforespørsel er gjort før forespørselen når serveren. Utvidelsen kan velge å endre forespørselen på dette stadiet. Serveren svarer da, men svaret går igjen gjennom utvidelsen, og utvidelsen kan diktere om svaret må endres. Chrome gjengir til slutt siden og brukeren kan se resultatet av klikkhandlingen.
Som Chrome overleverer alle dataene i en nettverksforespørsel, utvidelser som bruker Web Request API har tilgang til å lese og endre alt en bruker gjør på nettet. Så mens innholdsblokkere som uBlock Origin bruker klokt potensialet til denne APIen, hevder Google det andre utvidelser med ondsinnede hensikter har misbrukt det samme for å få tilgang til brukernes personlige opplysninger informasjon. Ifølge Google har 42 % av ondsinnede utvidelser brukt Web Request API siden januar 2018. Google hevder også at det er "betydelige ytelseskostnader" involvert med API som blokkeringsversjon av det krever en vedvarende og ofte langvarig prosess som er fundamentalt uforenlig med "lat" prosesser.
Med Manifest V3 foreslår Google å begrense denne API-en i sin blokkeringsform. Som et alternativ leverer Google Declarative Net Request API.
Fremtiden
Declarative Net Requests offisielle 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 trenger ikke Chrome å sende all informasjon om en forespørsel til lytteutvidelsen. I stedet registrerer utvidelsen regler med Chrome som forteller nettleseren på forhånd hva den skal gjøre hvis visse typer forespørsler blir sett.
Utvidelsen spesifiserer sine regler på forhånd. Brukernes forespørsel blir deretter matchet mot denne regelen av nettleseren (og ikke utvidelsen), og handlingen utføres også av nettleseren, og siden blir deretter gjengitt. Google nevner at dette lar dem sikre effektivitet siden de kan utøve kontroll over algoritmen som bestemmer resultatet og kan forhindre eller deaktivere ineffektive regler. Det gir også bedre personverngarantier for sluttbrukeren ettersom detaljene i nettverksforespørselen ikke er utsatt for utvidelsen. Siden vedvarende og langvarige prosesser ikke lenger er nødvendige (siden reglene er registrert på forhånd), hevder Google at denne tilnærmingen gir også ytelsesforbedringer som vil gjøre utvidelser betydelig mer levedyktige på ressursbegrensede plattformer.
Declarative Net Request vil være tilgjengelig for både Manifest V2 (nåværende) og Manifest V3, men det vil være den primære måten Google vil tillate at nettverksforespørsler endres i Manifest V3.
Kontroversen
Googles endringer ser ut til å være fornuftige helt til du hører den andre siden av historien, hovedsakelig annonseblokkere. Denne spesielle API-migreringen blir sett på som Googles måte å drepe annonseblokkere på, da den fundamentalt endrer måten en av de mest populære annonseblokkeringene fungerer på. Dette henger sammen med "teorien" om at Google er motivert for denne endringen mer fra et forretningsperspektiv enn fra et brukersikkerhetsperspektiv. Tross alt er Google sterkt avhengig av annonsering for sine inntekter, og annonseblokkere oppfattes som en direkte trussel for Googles kunder på denne fronten, som ble avslørt gjennom Alphabets 2018 SEC Form 10-K innlevering (via Registeret):
Nye og eksisterende teknologier kan påvirke vår evne til å tilpasse annonser og/eller kan blokkere annonser på nettet, noe som vil skade virksomheten vår.
Teknologier er utviklet for å gjøre tilpassbare annonser vanskeligere eller for å blokkere visningen av annonser helt og noen leverandører av elektroniske tjenester har integrerte teknologier som potensielt kan svekke kjernefunksjonaliteten til tredjeparts digitale reklame. Mesteparten av Google-inntektene våre kommer fra gebyrer betalt til oss i forbindelse med visning av annonser på nettet. Som et resultat kan slike teknologier og verktøy påvirke driftsresultatene våre negativt.
Google måtte gi ut en uttalelse for å løse dette, og gjentar sin holdning om at endringen er av hensyn til brukernes personvern og ikke et direkte angrep mot annonseblokkere:
Vi hindrer ikke utviklingen av annonseblokkere eller hindrer brukere i å blokkere annonser. I stedet ønsker vi å hjelpe utviklere, inkludert innholdsblokkere, med å skrive utvidelser på en måte som beskytter brukernes personvern.
Det må henvises til to av de mest populære annonseblokkeringene som er tilgjengelige på Google Chrome: uBlock Origin og Adblock Plus, som begge bruker forskjellige tilnærminger for å oppnå samme resultat av innholdsblokkering. uBlock Origin er avhengig av Web Request API, og fellesskapet har valgt denne utvidelsen gjennom årene. Adblock Plus og andre innholdsblokkerende utvidelser er også avhengige av blokkeringsdelen av Web Request, så endringer i denne API-en vil ende opp med å påvirke de fleste innholdsblokkere i en viss grad.
Googles press for å avvise Web Request vil i hovedsak drepe uBlock Origin i sitt nåværende format, noe som faktisk vil påvirke mange brukere. Mens brukere uten lojalitet (og uten intensjon om å bry seg med hvordan annonseblokkeringen oppnås) vil finne alternative løsninger som kommer med sine egne ulemper, vil det bli umulig for lojalister og entusiaster å komme opp med nye filtreringsmotordesign for å omgå de ulike teknikkene som nettsider til slutt vil komme opp med for å bekjempe annonseblokkere på denne spesifikke API.
Declarative Net Request ble også foreslått å være en ganske begrenset filtreringsmotor, slik den var opprinnelig planlagt å ha en grense på 30 000 regler for statiske filterregler per utvidelse (regler som er deklarert under installasjonen); og 5000 regelgrense for dynamiske filterregler per utvidelse (regler som kan legges til etter installasjon). Eventuelle overskytende regler vil bli ignorert, noe som er litt av et problem siden EasyList for Adblock Plus selv har 70 000 regler, mens uBlock Origin kan konfigureres til å kjøre med over 100 000 regler. Etter det første tilbakeslaget fra samfunnet, Google svarte ved å love å endre den statiske regelgrensen fra 30 000 regler per utvidelse til et globalt maksimum på 150 000 regler. Dette har da den bieffekten at brukerne utelukkes fra å bruke andre regeltunge skript i forbindelse med en annonseblokkering, slik at brukerne må sjonglere med sine preferanser.
Annet enn den begrensede filtreringsgrensen, Declarative Net Request kan bare omdirigere til statiske nettadresser, så det er ingen støtte inkludert for mønstertilpasning. uBlock Origin er sterkt avhengig av mønstertilpasning og utvidelsesutvikleren opplyst at det ikke er mulig å ettermontere utvidelsens samsvarende algoritme for å møte API-kravet. API vil også kreve en fullstendig utvidelsesoppdatering for å bare oppdatere filterlisten, noe som ville være en altfor hyppig aktivitet tatt i betraktning hvor ofte disse filterlistene oppdateres. Selvfølgelig vil disse oppdateringene også avhenge av Googles kriterier og prosesser for utvidelsesvurdering.
På den annen side har Google alltid opprettholdt sin holdning om at hensikten med å gå bort fra Web Request er fra en sikkerhetsperspektiv, ettersom Web Request API er for kraftig i sin nåværende form og åpner et veldig stort rom for misbruke. Dette misbruket er ikke bare teoretisk, ettersom Google har nevnt at 42 % av ondsinnede utvidelser har misbrukt denne API-en. Apple Safari Content Blocker API ble designet som Declarative Net Request av lignende årsaker, siden det er mindre rom for en useriøs utvikler å utnytte. På den nervøse nettforespørselen vil nettverksforespørsler fortsatt være observerbare, men de vil trenge tillatelser på de relevante vertene. Med Manifest V3 endres også vertstillatelsene betydelig, og de kan ikke lenger gis på en generell måte ved installasjonstidspunktet.
Google har også brukt ytelseskostnader som en motivator for byttet. Evaluering av nettverksforespørsler skjer i JavaScript-tråden til utvidelsen, noe som kan være kostbart på ytelsen. Som en motbevisning nevner uBlock Origins utvikler at utvidelsen hans pådrar seg ingen betydelig ytelsesstraff selv når du har så mange som 140 000 statiske filtre å håndheve. Kostnadene som påløper hevdes å være enkelt dekket av ressursene som er forhindret fra å lastes ned fra eksterne servere og dermed ikke behandles av nettleseren.
Selv om Google ikke bruker dette resonnementet, kan ett argument mot Web Request også fremsettes for effektivitet med annonseblokkering. Med Web Request, hvis en utvidelse ikke svarer i tide (på grunn av etterslep eller krasj), er forespørselen om nettverkshåndtering helt klart tillatt, noe som lar annonser slippe gjennom annonseblokkeringen. Declarative Net Request, på den annen side, ville ikke lide av denne ulempen. I stedet vil annonser gå gjennom hvis de ikke blir fanget innenfor de statiske reglene, og dette vil skje oftere enn ikke.
Konklusjon
Fra forklaringene ovenfor er det klart at Declarative Net Request ikke er en 1:1 funksjonalitetsklon for blokkeringen funksjonene til Web Request API, og utvidelsesutviklere er nødt til å bli irriterte når deres harde arbeid vil bli handikappet av slike endringer. Men Googles resonnement veier også tungt -- Web Request er for kraftig, og dens krefter må være det begrenset i den større interessen til brukerfellesskapet (som består av gjennomsnittlige brukere sammen med entusiaster).
Bevegelsen mot Declarative Net Request kunne også ha vært et positivt PR-trekk – tross alt legger Google til en innebygd innholdsblokkerings-API til Chrome! Men siden det nye API-et kommer med sine egne tunge restriksjoner, ser samfunnet med rette på dette som et vingeklipp. I en ideell verden burde Google ha utforsket hvordan annonseblokkere som uBlock Origin fungerer før de lanserte det nye API-et. Slik det står nå, kan det nye API-et bruke ytterligere lempelser på regelgrensene for å imøtekomme scenarier der brukere ønsker å bruke to filtertunge utvidelser.
I følge Registeret, vil de første byggene med Manifest V3-endringer være tilgjengelige fra juli 2019 og utover. Vi håper Google imøtekommer tilbakemeldingene fra utvidelsesutviklerfellesskapet med disse byggene.
Spesiell takk til XDAs sjefredaktør Mishaal Rahman for hans innspill og hjelp!
Edit: Artikkelen likestilte feilaktig Adblock Pluss virkemåte med Declarative Net Request API. Artikkelen er endret tilsvarende. Adblock Plus vil også bli påvirket av fjerningen av Web Request APIs blokkeringsmuligheter.