Chrome browser udviklere afbrydelse af understøttelse af blokeringstilstanden til webRequest API, som giver dig mulighed for at ændre det modtagne indhold i farten og bruges aktivt i tilføjelser til blokering af annoncering,
beskyttelse mod malware, phishing, spionering af brugeraktivitet, forældrekontrol og privatliv.
Googles motiver:
- API-blokeringstilstand fører til et højt ressourceforbrug.
Når du bruger denne API, sender browseren først tilføjelsen alle data indeholdt i netværksanmodningen, tilføjelsen analyserer den og returnerer en ændret version til yderligere behandling i browseren eller udsteder blokeringsinstruktioner. I dette tilfælde opstår de vigtigste forsinkelser ikke på stadiet for behandling af trafik af tilføjelsen, men på grund af de overheadomkostninger ved at koordinere udførelsen af tilføjelsen. Især kræver sådanne manipulationer lanceringen af en separat proces for at supplere, såvel som brugen af IPC til at interagere med denne proces og dataserialiseringsmekanismer; - Tilføjelsen kontrollerer fuldstændig al trafik på et lavt niveau, hvilket åbner op for enorme muligheder for misbrug og krænkelser af privatlivets fred. Ifølge Googles statistik brugte 42 % af alle opdagede ondsindede tilføjelser webRequest API. Det bemærkes, at hver måned blokeres forsøg på at placere i gennemsnit 1800 ondsindede tilføjelser i Chrome Webshop-kataloget. Desværre giver gennemgang os ikke mulighed for at fange alle ondsindede tilføjelser uden undtagelse, så for at forbedre beskyttelsen blev det besluttet at begrænse tilføjelser på API-niveau. Hovedideen er at give tilføjelser med adgang ikke til al trafik, men kun til de data, der er nødvendige for at implementere den tilsigtede funktionalitet. Især for at blokere indhold er det ikke nødvendigt at give tilføjelsen fuld adgang til alle fortrolige brugerdata;
- Foreslået erstatningsdeklarativ API tager sig af alt arbejdet med højtydende indholdsfiltrering og kræver kun tilføjelser for at indlæse filtreringsregler. Tilføjelsen kan ikke forstyrre trafikken, og brugerens private data forbliver ukrænkelige;
- Google tog højde for mange af kommentarerne vedrørende den deklarative NetRequest API's manglende funktionalitet og udvidede grænsen for antallet af filtreringsregler fra de oprindeligt foreslåede 30 pr. udvidelse til et globalt maksimum på 150, og tilføjede også muligheden for dynamisk ændre og tilføje regler, fjerne og erstatte HTTP-headere (Referer, Cookie, Set-Cookie) og anmode om parametre;
- For virksomheder er det muligt at bruge blokeringstilstanden til webRequest API, da politikken for brug af tilføjelser bestemmes af en administrator, der forstår funktionerne i infrastrukturen og er opmærksom på risiciene. For eksempel kan den angivne API bruges i virksomheder til at registrere medarbejdertrafikstrømme og integrere med interne systemer;
- Googles mål er ikke at underminere eller undertrykke tilføjelser til annonceblokering, men at muliggøre oprettelsen af sikrere og mere kraftfulde annonceblokeringer;
- Modviljen mod at forlade blokeringstilstanden for webRequest API'et sammen med den nye declarativeNetRequest forklares med ønsket om at begrænse adgangen til tilføjelser til fortrolige data. Hvis du lader webRequest API'en være som den er, vil de fleste tilføjelser ikke bruge den mere sikre declarativeNetRequest, da når der skal vælges mellem sikkerhed og funktionalitet, vil de fleste udviklere normalt vælge funktionalitet.
:
- Udført af tilføjelsesudviklere viser en ubetydelig samlet indvirkning på ydeevnen af tilføjelsesprogrammer til annonceblokering (under test blev ydeevnen af forskellige tilføjelser sammenlignet, men uden at tage hensyn til omkostningerne ved en yderligere proces, der koordinerer udførelsen af behandlere i blokeringstilstanden af webRequest API);
- Det er ikke praktisk helt at stoppe med at understøtte en API, der bruges aktivt i tilføjelser. I stedet for at fjerne det, kan du tilføje en separat tilladelse og strengt kontrollere tilstrækkeligheden af dens brug i tilføjelser, hvilket ville spare forfatterne af mange populære tilføjelser fra fuldstændigt at omarbejde deres produkter og undgå at skære i funktionalitet;
- For at reducere overheadomkostningerne kan du ikke slette API'en, men lave den om baseret på Promise-mekanismen, svarende til implementeringen af webRequest i Firefox;
- Det foreslåede alternativ, declarativeNetRequest, dækker ikke alle tilføjelsesudvikleres behov for annonceblokering og sikkerhed/privatliv, da det ikke giver fuld kontrol over netværksanmodninger, ikke tillader brug af tilpassede filtreringsalgoritmer og ikke tillader brugen af komplekse regler, der overlapper hinanden afhængigt af forholdene;
- Med den nuværende tilstand af declarativeNetRequest API er det umuligt at genskabe den eksisterende funktionalitet af uBlock Origin og uMatrix tilføjelser uændret, og det gør også videreudvikling af en NoScript-port til Chrome meningsløs;
- Bekymringer om privatlivets fred er langt ude, da den skrivebeskyttede, ikke-blokerende tilstand af webRequest API'et efterlades på plads og stadig tillader ondsindede tilføjelser at kontrollere al trafik, men ikke giver mulighed for at forstyrre den på flyve (ændre indhold, placere dine annoncer, køre minearbejdere og analysere indholdet af inputformularerne kan bruges efter siden er færdig med at indlæse);
- Browser udviklere , и , bygget på Chromium-motoren, har til hensigt at efterlade support til webRequest-blokeringstilstanden i deres produkter.
Kilde: opennet.ru