Simeon Vincent, som er ansvarlig for samhandling med utvidelsesutviklere i Chrome-teamet (har stillingen som Extensions Developer Advocate), Googles nåværende posisjon angående den tredje utgaven av Chrome-manifestet, mange tillegg for å blokkere upassende innhold og sikre sikkerhet. Selskapet har ikke til hensikt å forlate sin opprinnelige plan om å slutte å støtte blokkeringsmodusen til webRequest API, som lar deg endre det mottatte innholdet på farten. Et unntak gjøres kun for bedriftsutgaven av Chrome (), der støtte for webRequest API vil bli beholdt som før.
For vanlige Chrome API-brukere vil være begrenset til skrivebeskyttet modus. En deklarativ API er foreslått for å erstatte webRequest API for innholdsfiltrering , som bare dekker en begrenset del av funksjonene som brukes i moderne annonseblokkere. I hovedsak, i stedet for proprietære behandlere som har full tilgang til nettverksforespørsler, tilbys en ferdig universal innebygd filtreringsmotor som behandler blokkeringsregler på egen hånd. For eksempel lar declarativeNetRequest API deg ikke bruke dine egne filtreringsalgoritmer og lar deg ikke lage komplekse regler som overlapper hverandre avhengig av forhold.
Utviklerne av annonseblokkeringstillegg har i fellesskap forberedt seg , som listet opp manglene ved declarativeNetRequest API. Google var enig i mange av kommentarene og la til declarativeNetRequest API. Spesielt er det lagt til støtte for dynamisk endring og tilføying av regler, og det er mulig å slette HTTP-hoder, men kun de som er på hvitlisten (Referer, Cookie, Set-Cookie). Vi planlegger å implementere støtte for å legge til og erstatte HTTP-hoder (for eksempel for Set-Cookie-erstatning og CSP-direktiver) og muligheten til å slette og erstatte forespørselsparametere.
En foreløpig versjon av den tredje versjonen av manifestet, som definerer listen over funksjoner og ressurser gitt til Chrome-tillegg, er planlagt brukt til testing i eksperimentelle versjoner av Chrome Canary i løpet av de kommende månedene.
Samtidig er motivasjonen for å forby endringer i mottatt innhold gjennom webRequest API fortsatt ikke helt klar. Påstander om at blokkeringsmodusen til webRequest API har en negativ innvirkning på ytelsen fordi nettleseren venter på at tilleggsbehandleren skal fullføre arbeidet før den gjengir siden, tåler ikke kritikk. Tidligere utført Ytelsen til annonseblokkerende tillegg har vist at forsinkelsen de introduserer er ubetydelig. I gjennomsnitt bremser bruken av en blokkering utførelsen av en forespørsel med bare en brøkdel av millisekunder, noe som er ubetydelig sammenlignet med den generelle bakgrunnen.
Det andre argumentet, knyttet til ønsket om å beskytte brukere mot ukontrollert tilgang av tillegg til innhold, ser heller ikke overbevisende ut, siden det i stedet for å fjerne lenge etablert og utbredt funksjonalitet i legitime tillegg var mulig å legge til en ny type autoritet og gi brukeren det endelige valget om å installere et tillegg med full tilgang til nettverksforespørsler eller ikke. I tillegg har Google forlatt støtte for bruk av webRequest API i skrivebeskyttet modus, noe som tillater full trafikkovervåking uten intervensjon på lavt nivå.
Tillegg kan endre innholdet på lastede nettsider gjennom andre APIer (for eksempel kan ondsinnede tillegg fortsatt levere annonsene deres, starte gruvearbeidere og analysere innholdet i inndataskjemaer).
Raymond Hill, forfatter av uBlock Origin og uMatrix-systemene for blokkering av uønsket innhold, er ganske streng svar fra en Google-representant og antydet demagogi og spill bak kulissene der Google, under dekke av en god mulighet, prøver å fremme sine forretningsinteresser innen internettannonsering, få kontroll over sine filtreringsmekanismer og rettferdiggjøre disse handlingene i allmennhetens øyne.
Han mottok aldri overbevisende argumenter for behovet for å stoppe det utbredte og populære API-et blant tilleggsutviklere. Ifølge Raymond er ikke nedgangen i ytelse et argument, siden sidene lastes sakte på grunn av oppblåsthet, og ikke på grunn av bruken av webRequest-blokkeringsmodus i korrekt implementerte tillegg. Hvis Google virkelig brydde seg om ytelse, ville de ha redesignet webRequest basert på mekanismen , i analogi med webRequest i Firefox.
Ifølge Raymond er Googles strategi å finne den optimale balansen mellom å utvide Chromes brukerbase og forretningsskaden forårsaket av bruk av innholdsblokkere. I den første fasen av Chrome-utvidelsen ble Google tvunget til å stille opp med annonseblokkere som et av de mest populære tilleggene blant brukere. Men etter at Chrome fikk dominans, prøvde selskapet å tippe balansen i sin favør og få kontroll over blokkering ved å promotere å integrere upassende annonseblokkeringsfunksjonalitet i Chrome. WebRequest API bekjemper dette formålet fordi kontroll over innholdsblokkering for tiden er i hendene på tredjepartsutviklere av annonseblokkering.
Kilde: opennet.ru