Simeon Vincent, kes vastutab Chrome'i meeskonnas laienduste arendajatega suhtlemise eest (tal on laienduste arendaja advokaadi positsioon), Google'i praegune seisukoht Chrome'i manifesti kolmanda väljaande kohta palju lisandmooduleid sobimatu sisu blokeerimiseks ja turvalisuse tagamiseks. Ettevõte ei kavatse loobuda oma esialgsest plaanist lõpetada webRequest API blokeerimisrežiimi toetamine, mis võimaldab vastuvõetud sisu lennult muuta. Erand tehakse ainult Chrome'i ettevõtte väljaande (), milles webRequest API tugi säilib nagu varem.
Tavalistele Chrome API kasutajatele piirdub kirjutuskaitstud režiimiga. Sisu filtreerimiseks mõeldud webRequest API asendamiseks on pakutud välja deklaratiivne API , mis hõlmab vaid piiratud osa tänapäevastes reklaamiblokeerijates kasutatavatest võimalustest. Põhimõtteliselt pakutakse patenteeritud töötlejate asemel, millel on täielik juurdepääs võrgupäringutele, valmis universaalset sisseehitatud filtreerimismootorit, mis töötleb blokeerimisreegleid iseseisvalt. Näiteks declarativeNetRequest API ei võimalda teil kasutada oma filtreerimisalgoritme ega luua keerulisi reegleid, mis olenevalt tingimustest kattuvad.
Reklaami blokeerimise lisandmoodulite arendajad on ühiselt ette valmistanud , mis loetles deklaratiivse NetRequest API puudused. Google nõustus paljude kommentaaridega ja lisas deklaratiivse NetRequest API. Eelkõige on lisatud tugi reeglite dünaamiliseks muutmiseks ja lisamiseks ning HTTP päiseid on võimalik kustutada, kuid ainult valges nimekirjas olevaid (Referer, Cookie, Set-Cookie). Plaanime juurutada HTTP-päiste lisamise ja asendamise toe (näiteks Set-Cookie asendus- ja CSP direktiivide jaoks) ning päringu parameetrite kustutamise ja asendamise võimaluse.
Manifesti kolmanda versiooni esialgset versiooni, mis määratleb Chrome'i lisandmoodulitele pakutavate võimaluste ja ressursside loendi, on kavas lähikuudel kasutada katsetamiseks Chrome Canary eksperimentaalsetes versioonides.
Samal ajal ei ole webRequest API kaudu vastuvõetud sisu muutmise keelamise motivatsioon täiesti selge. Väited, et webRequest API blokeerimisrežiimil on toimivusele negatiivne mõju, kuna brauser ootab enne lehe renderdamist, kuni lisandmooduli töötleja oma töö lõpetab, ei talu kriitikat. Varem läbi viidud Reklaamid blokeerivate lisandmoodulite toimivus on näidanud, et viivitus on tühine. Keskmiselt aeglustab blokeerija kasutamine päringu täitmist vaid millisekundite murdosa võrra, mis on üldise taustaga võrreldes tühine.
Ka teine argument, mis on seotud sooviga kaitsta kasutajaid lisandmoodulite kontrollimatu juurdepääsu eest sisule, ei tundu veenev, kuna selle asemel, et eemaldada seaduslikest lisandmoodulitest ammu juurdunud ja laialt levinud funktsionaalsus, oli võimalik lisada uus. volituse tüüpi ja anda kasutajale lõplik valik, kas installida võrgupäringutele täieliku juurdepääsuga pistikprogramm või mitte. Lisaks on Google jätnud toe webRequest API kasutamiseks kirjutuskaitstud režiimis, võimaldades liikluse täielikku jälgimist ilma madala taseme sekkumiseta.
Lisandmoodulid saavad muude API-de kaudu laadida laaditud veebilehtede sisu (näiteks võivad pahatahtlikud lisandmoodulid siiski oma reklaame edastada, kaevandajaid käivitada ja sisestusvormide sisu analüüsida).
Soovimatu sisu blokeerimiseks mõeldud süsteemide uBlock Origin ja uMatrix autor Raymond Hill on üsna range Google'i esindaja vastus ning vihjas demagoogiale ja telgitagustele mängudele, kus Google püüab hea võimaluse varjus edendada oma ärihuve internetireklaami vallas, saada kontrolli oma filtreerimismehhanismide üle ja õigustada neid tegusid avalikkuse silmis.
Ta ei saanud kunagi veenvaid argumente vajaduse kohta peatada lisandmoodulite arendajate seas laialt levinud ja populaarne API. Raymondi sõnul ei ole jõudluse langus argument, kuna lehed laaditakse aeglaselt nende paisumise tõttu, mitte webRequesti blokeerimisrežiimi kasutamise tõttu õigesti rakendatud lisandmoodulites. Kui Google tõesti jõudlusest hooliks, oleksid nad webRequesti mehhanismi alusel ümber kujundanud , analoogia põhjal webRequest Firefoxis.
Raymondi sõnul on Google'i strateegia määrata kindlaks optimaalne tasakaal Chrome'i kasutajabaasi laiendamise ja sisublokeerijate kasutamisest tuleneva ärikahju vahel. Chrome'i laienemise esimeses etapis oli Google sunnitud leppima reklaamiblokeerijatega kui kasutajate seas ühe populaarseima lisandmooduliga. Kuid pärast seda, kui Chrome saavutas domineerimise, püüdis ettevõte tasakaalu enda kasuks kallutada ja reklaamide abil blokeerimise üle kontrolli saada et integreerida Chrome'i sobimatu reklaamide blokeerimise funktsioon. WebRequest API ei suuda seda eesmärki, kuna sisu blokeerimise üle on praegu kolmandate osapoolte reklaamiblokeerijate arendajate käes.
Allikas: opennet.ru