Google rettferdiggjør begrensningen av webRequest API som brukes av annonseblokkere

Chrome-nettleserutviklere prøvde rettferdiggjøre avvikling av støtte for blokkeringsmodusen til webRequest API, som lar deg endre det mottatte innholdet på et øyeblikk og brukes aktivt i tillegg for blokkering av reklame,
beskyttelse mot skadelig programvare, phishing, spionering på brukeraktivitet, foreldrekontroll og personvern.

Googles motiver:

• API-blokkeringsmodus webRequest fører til høyt ressursforbruk.
  Når du bruker denne API-en, sender nettleseren først tillegget alle dataene i nettverksforespørselen, tillegget analyserer det og returnerer en modifisert versjon for videre behandling i nettleseren eller gir blokkeringsinstruksjoner. I dette tilfellet oppstår hovedforsinkelsene ikke på stadiet for behandling av trafikk av tillegget, men på grunn av overheadkostnadene ved å koordinere utførelsen av tillegget. Spesielt krever slike manipulasjoner lansering av en egen prosess for å komplementere, samt bruk av IPC for å samhandle med denne prosessen og dataserialiseringsmekanismer;

• Tillegget kontrollerer fullstendig all trafikk på et lavt nivå, noe som åpner for store muligheter for misbruk og brudd på personvernet. I følge Googles statistikk brukte 42 % av alle oppdagede skadelige tillegg webRequest API. Det bemerkes at forsøk på å plassere gjennomsnittlig 1800 ondsinnede tillegg hver måned blokkeres i Chrome Nettmarked-katalogen. Dessverre tillater ikke gjennomgang oss å fange opp alle ondsinnede tillegg uten unntak, så for å forbedre beskyttelsen ble det besluttet å begrense tillegg på API-nivå. Hovedideen er å gi tilleggsprogrammer tilgang ikke til all trafikk, men kun til dataene som er nødvendige for å implementere den tiltenkte funksjonaliteten. Spesielt for å blokkere innhold er det ikke nødvendig å gi tillegget full tilgang til alle konfidensielle brukerdata;
• Foreslått erstatningsdeklarativ API declarativeNetRequest tar seg av alt arbeidet med innholdsfiltrering med høy ytelse og krever kun tillegg for å laste inn filtreringsregler. Tillegget kan ikke forstyrre trafikk og brukerens private data forblir ukrenkelige;
• Google tok hensyn til mange av kommentarene angående mangelen på funksjonalitet til declarativeNetRequest API og utvidet grensen for antall filtreringsregler fra de opprinnelig foreslåtte 30 tusen per utvidelse til et globalt maksimum på 150 tusen, og la også til muligheten til dynamisk endre og legge til regler, fjerne og erstatte HTTP-hoder (Referer, Cookie, Set-Cookie) og forespørselsparametere;
• For bedrifter er det mulig å bruke blokkeringsmodusen til webRequest API, siden policyen for bruk av tillegg bestemmes av en administrator som forstår funksjonene til infrastrukturen og er klar over risikoene. For eksempel kan den angitte API-en brukes i bedrifter for å registrere ansattes trafikkstrømmer og integrere med interne systemer;
• Googles mål er ikke å undergrave eller undertrykke annonseblokkeringstillegg, men å muliggjøre opprettelsen av sikrere og kraftigere annonseblokkere;
• Motviljen mot å forlate blokkeringsmodusen til webRequest API sammen med den nye declarativeNetRequest er forklart med ønsket om å begrense tilgangen til tilleggsprogrammer til konfidensielle data. Hvis du lar webRequest API være som det er, vil de fleste tillegg ikke bruke den sikrere declarativeNetRequest, siden når du velger mellom sikkerhet og funksjonalitet, vil de fleste utviklere vanligvis velge funksjonalitet.

Innvendinger utviklere tillegg:

• Utført av tilleggsutviklere tester viser en ubetydelig total innvirkning på ytelsen til annonseblokkeringstillegg (under testing ble ytelsen til ulike tillegg sammenlignet, men uten å ta hensyn til overheaden til en ekstra prosess som koordinerer utførelsen av behandlere i blokkeringsmodus for webRequest API);
• Det er ikke praktisk å slutte helt å støtte en API som brukes aktivt i tillegg. I stedet for å fjerne den, kan du legge til en egen tillatelse og strengt kontrollere tilstrekkeligheten av bruken i tillegg, noe som vil spare forfatterne av mange populære tillegg fra å omarbeide produktene sine fullstendig og unngå å kutte funksjonalitet;
• For å redusere overheadkostnader kan du ikke slette API-en, men lage den på nytt basert på Promise-mekanismen, som ligner på implementeringen av webRequest i Firefox;
• Det foreslåtte alternativet, declarativeNetRequest, dekker ikke alle behovene til tilleggsutviklere for annonseblokkering og sikkerhet/personvern, siden det ikke gir full kontroll over nettverksforespørsler, ikke tillater bruk av tilpassede filtreringsalgoritmer og ikke tillater bruk av komplekse regler som overlapper hverandre avhengig av forholdene;
• Med den nåværende tilstanden til declarativeNetRequest API er det umulig å gjenskape den eksisterende funksjonaliteten til uBlock Origin og uMatrix-tilleggene uendret, og det gjør også videreutvikling av en NoScript-port for Chrome meningsløs;
• Bekymringer om personvern er langt inne, siden den skrivebeskyttede, ikke-blokkerende modusen til webRequest API er på plass og fortsatt lar ondsinnede tillegg kontrollere all trafikk, men ikke gir mulighet til å forstyrre den på fly (endre innhold, plasser annonser, kjør gruvearbeidere og analyser innholdet i inndataskjemaene kan brukes etter at siden er ferdig lastet);
• Nettleserutviklere Modig, Opera и Vivaldi, bygget på Chromium-motoren, har til hensikt å legge igjen støtte for webRequest-blokkeringsmodus i produktene deres.

Kilde: opennet.ru