Sok reklámblokkolót kivégezhet az új Chrome API

Komolyabb védelmet húzna fel a jövőben a potenciálisan kártékony Chrome-kiegészítők ellen a Google - a lépés ugyanakkor egyben a hirdetésblokkoló és biztonsági megoldások hatékonyságát is jelentősen visszavetheti a keresőóriás böngészőjében. Az átalakítások célja a Google szerint, hogy biztonságosabbá tegye a kiegészítőket, illetve a felhasználóknak is nagyobb szabadságot adjon azok funkcióinak kezelésében, a változások ugyanakkor a hirdetésblokkolókat használóknak komoly fejfájást is okozhatnak.

A vállalat Implement Manifest V3 dokumentumában számolt be a változásokról, amelyet az Ars Technica csípett el. Eszerint a fő problémát az jelenti, hogy a tervezett frissítéssel a webRequest API nem lesz majd használható blokkolási módban. Az API jelenleg lehetőséget ad a kiegészítőknek, hogy minden hálózati lekérést megvizsgáljanak, illetve igény szerint módosítsák azokat, mielőtt a böngésző továbbítaná a lekéréseket az adott szerver felé. A hirdetésblokkolók ezzel ki tudják válogatni a reklámokhoz tartozó lekérdezéseket, amelyeket egyszerűen el tudnak távolítani, de akár a JavaScript tartalmak blokkolására is lehetőség van vele.

Lassú és sebezhető?

A Google szerint ugyanakkor a megoldás lassú, a kiegészítők nincsenek időkorláthoz kötve a lekérések átvizsgálásánál, ami a keresőóriás szerint időigényesebb oldalbetöltéseket eredményezhet - persze a vizsgálatra szánt idő sok esetben valójában bőségesen megtérül, hiszen cserébe nem kell méretes reklámokat vagy médiaelemeket letölteni. Az API ugyanakkor biztonsági kockázatokat is hordoz, hiszen miután a cookie-k törlésére vagy módosítására is lehetősége van, rosszindulatú felek azzal akár adatlopást is megkísérelhetnek.

Ezért a cég alternatívaként a declarativeNetRequest API-t vezetné be, amely ahelyett, hogy egyenként megvizsgálja a kiküldésre váró lekéréseket, általános szabályok lefektetésére ad lehetőséget, bizonyos URL kategóriák átirányítására vagy épp blokkolására. A kitételek birtokában aztán a böngésző dönti el, hogy az aktuális tartalmakat ki kell-e szűrnie. A megoldás biztonsági szempontból kétségtelenül előnyös, hiszen így a böngészőkiegészítő nem fér hozzá a felhasználó lekérdezéseihez, cookie-khoz vagy más érzékeny adatokhoz - emellett a webRequest API-nál gyorsabb működést is ígér.

Sajnos azonban a manipulálni kívánt lekérések behatárolása jóval pontatlanabbá válik az új API-val. Igaz, lehetőség van vele egy JSON fájlban tárolt statikus URL lista blokkolására is a megadott szabályokon felül, utóbbi legfeljebb 30 ezer elemet tartalmazhat. Ahogy az Ars Technica is kiemeli, a uBlock Origin alapértelmezetten mintegy 90 ezer szűrővel érkezik, ez azonban akár félmillióra is felhizlalható.

Lesz, aki túléli

Az átalakítás nem jelenti a hirdetésszűrők végét, a korábban kétes blokkolási gyakorlata miatt támadott Adblock Plus például valószínűleg átvészeli majd a váltást, az ugyanis jelenleg is hasonló keretek között végzi a hirdetések kiszűrését.  Az Adblock Plus korábban egyébként épp azért került tűz alá, mert korábbi értesülések szerint több cég, köztük a Google is fizet a blokkolónak, hogy bizonyos reklámokat átengedjen szűrőin - egyesek akár összefüggést is sejthetnek az együttműködés és a mostani, az Adblock Plusnak nem különösen fájdalmas, riválisait azonban nagyon is érzékenyen érintő változások mellett.

Az ugyancsak népszerű uBlock Origin, illetve uMatrix fejlesztője blogposztban is hangot adott már aggodalmának, amely szerint az új API lényegében ellehetetleníti a kiegészítő használatát, már csak az általa alkalmazott, kiterjedt szűrőlista miatt is, továbbá a nagy méretű médiafájlokat, vagy a JavaScript végrehajtást sem lehet majd vele blokkolni. Ennek megfelelően többek között a NoScript és társai is bajba kerülhetnek az újítással.

Modern SOC, kiberhírszerzés és fenntartható IT védelem (x) Gyere el meetupunkra november 18-án, ahol valós használati eseteken keresztül mutatjuk be az IT-biztonság legújabb trendjeit.

De egy sor biztonsági kiegészítő is támaszkodik a webRequest API-ra, amelyek a hirdetések lekérései helyett a kártékonynak ítélt weboldalakat gyűjtő feketelisták elemeit blokkolják. Ezek a listák több esetben hashelt formában tárolódnak a kiegészítőben, hogy a phishing vagy egyéb rosszindulatú oldalak üzemeltetői ne tudják egyszerűen módosítani az URL-eket, hogy azok eltérjenek a feketelistázott változattól. A hashelt tárolásra ugyanakkor a declarativeNetRequest API-val már nem lesz lehetőség, az csak az egyszerű szöveget támogatja, ami nagyban visszavetheti a hasonló biztonsági kiegészítők hatékonyságát.

Az Implement Manifest V3-ban persze egy sor további hasznos biztonsági javítás is akad, a Google például a kiegészítőknél várhatóan a távoli szerverekről történő kódletöltést is tiltja majd, ennek megfelelően a moduloknak minden, a működéshez szükséges kódot lokálisan tartalmazniuk kell - így nem lesz lehetőség a Chrome Web Store biztonsági szűrőin átjutott kiegészítőkbe később kártékony kódot csempészni. Emellett a kiegészítőknek kiosztott engedélyek helyzete is változik, azok nem kaphatnak rögtön hozzáférést minden látogatott weboldalhoz.

A sorolt változtatások véglegesítése persze még várat magára, így egyelőre nem reménytelen, hogy a uBlock Origin és társai továbbra is használhatók maradnak, ha azonban a Google tartja magát a leírtakhoz, nagyban megnehezítheti a reklámblokkolók és azok felhasználóinak helyzetét. A The Register szerint, miután az új API kapcsán számos fejlesztő hangot adott nemtetszésének, a Google igyekezett aláhúzni, hogy annak bevezetése és pontos funkcionalitása még nem eldöntött kérdés, a vállalat továbbá a felmerülő problémák megoldásában az érintett csapatokkal is együttműködik majd.