Simeon Vincent, der er ansvarlig for interaktion med udvidelsesudviklere i Chrome-teamet (har stillingen som Extensions Developer Advocate), Googles nuværende holdning til den tredje udgave af Chrome-manifestet, mange tilføjelser for at blokere upassende indhold og sikre sikkerheden. Virksomheden har ikke til hensigt at opgive sin oprindelige plan om at stoppe med at understøtte blokeringstilstanden for webRequest API, som giver dig mulighed for at ændre det modtagne indhold på farten. En undtagelse vil kun blive gjort for virksomhedsudgaven af Chrome (), hvor understøttelse af webRequest API vil blive bevaret som før.
Til almindelige Chrome API-brugere vil være begrænset til skrivebeskyttet tilstand. En deklarativ API er blevet foreslået til at erstatte webRequest API til indholdsfiltrering , som kun dækker en begrænset del af de muligheder, der bruges i moderne annonceblokkere. I det væsentlige, i stedet for proprietære handlere, der har fuld adgang til netværksanmodninger, tilbydes en færdiglavet universel indbygget filtreringsmotor, der behandler blokeringsregler på egen hånd. For eksempel tillader declarativeNetRequest API dig ikke at bruge dine egne filtreringsalgoritmer og tillader dig ikke at oprette komplekse regler, der overlapper hinanden afhængigt af forhold.
Udviklerne af tilføjelser til annonceblokering har i fællesskab forberedt sig , som oplistede manglerne ved declarativeNetRequest API. Google var enig i mange af kommentarerne og føjede til declarativeNetRequest API. Der er især tilføjet understøttelse for dynamisk ændring og tilføjelse af regler, og det er muligt at slette HTTP-headere, men kun dem på hvidlisten (Referer, Cookie, Set-Cookie). Vi planlægger at implementere understøttelse af tilføjelse og udskiftning af HTTP-headere (for eksempel for Set-Cookie-substitution og CSP-direktiver) og muligheden for at slette og erstatte anmodningsparametre.
En foreløbig version af den tredje version af manifestet, som definerer listen over muligheder og ressourcer, der leveres til Chrome-tilføjelser, er planlagt til at blive brugt til test i eksperimentelle builds af Chrome Canary i de kommende måneder.
Samtidig er motivationen for at forbyde ændringer i modtaget indhold gennem webRequest API stadig ikke helt klar. Påstande om, at blokeringstilstanden for webRequest API har en negativ indvirkning på ydeevnen, fordi browseren venter på, at tilføjelsesbehandleren fuldfører sit arbejde, før den gengiver siden, tåler ikke kritik. Tidligere udført Ydeevnen for tilføjelser til annonceblokering har vist, at forsinkelsen, de introducerer, er ubetydelig. I gennemsnit bremser brugen af en blokering udførelsen af en anmodning med kun en brøkdel af millisekunder, hvilket er ubetydeligt sammenlignet med den generelle baggrund.
Det andet argument, relateret til ønsket om at beskytte brugerne mod ukontrolleret adgang af tilføjelser til indhold, ser heller ikke overbevisende ud, da det i stedet for at fjerne længe etableret og udbredt funktionalitet i legitime tilføjelser var muligt at tilføje en ny type myndighed og give brugeren det endelige valg om at installere en tilføjelse med fuld adgang til netværksanmodninger eller ej. Derudover har Google efterladt support til brug af webRequest API i skrivebeskyttet tilstand, hvilket muliggør fuld trafikovervågning uden indgreb på lavt niveau.
Tilføjelser kan ændre indholdet af indlæste websider gennem andre API'er (for eksempel kan ondsindede tilføjelser stadig levere deres annoncer, starte minearbejdere og analysere indholdet af inputformularer).
Raymond Hill, forfatter til uBlock Origin og uMatrix-systemerne til blokering af uønsket indhold, er ret streng svar fra en Google-repræsentant og antydet demagogi og spil bag kulisserne, hvor Google, under dække af en god mulighed, forsøger at fremme sine forretningsinteresser inden for internetannoncering, få kontrol over sine filtreringsmekanismer og retfærdiggøre disse handlinger set i offentlighedens øjne.
Han modtog aldrig overbevisende argumenter for behovet for at stoppe den udbredte og populære API blandt tilføjelsesudviklere. Ifølge Raymond er faldet i ydeevne ikke et argument, da sider indlæses langsomt på grund af deres bloat, og ikke på grund af brugen af webRequest-blokeringstilstand i korrekt implementerede tilføjelser. Hvis Google virkelig bekymrede sig om ydeevne, ville de have redesignet webRequest baseret på mekanismen , i analogi med webRequest i Firefox.
Ifølge Raymond er Googles strategi at bestemme den optimale balance mellem at udvide Chromes brugerbase og de forretningsmæssige skader forårsaget af brugen af indholdsblokkere. I den første fase af Chrome-udvidelsen blev Google tvunget til at finde sig i annonceblokering som en af de mest populære tilføjelser blandt brugerne. Men efter at Chrome fik dominans, forsøgte virksomheden at vippe balancen til sin fordel og få kontrol over blokering ved at promovere at integrere upassende annonceblokeringsfunktionalitet i Chrome. WebRequest API'en besejrer dette formål, fordi kontrol over indholdsblokering i øjeblikket er i hænderne på tredjeparts udviklere af annonceblokering.
Kilde: opennet.ru