Chrome böngésző fejlesztők a webRequest API blokkoló működési módjának támogatásának megszüntetése, amely lehetővé teszi a fogadott tartalom menet közbeni megváltoztatását, és aktívan használják a hirdetések blokkolására szolgáló bővítményekben,
védelem a rosszindulatú programok, az adathalászat, a felhasználói tevékenység utáni kémkedés, a szülői felügyelet és a magánélet elleni védelem.
A Google indítékai:
- API blokkoló mód magas erőforrás-felhasználáshoz vezet.
Ennek az API-nak a használatakor a böngésző először elküldi a bővítménynek a hálózati kérésben szereplő összes adatot, a bővítmény elemzi azt, és egy módosított verziót küld vissza további feldolgozásra a böngészőben, vagy blokkolási utasításokat ad ki. Ebben az esetben a fő késések nem a forgalom bővítmény általi feldolgozásának szakaszában jelentkeznek, hanem a bővítmény végrehajtásának koordinálásával járó általános költségek miatt. Az ilyen manipulációkhoz külön kiegészítő folyamat elindítása, valamint az IPC használata szükséges a folyamattal való interakcióhoz és az adatsorosítási mechanizmusokhoz; - A bővítmény teljesen alacsony szinten szabályozza az összes forgalmat, ami hatalmas lehetőségeket nyit meg a visszaélésekre és a személyes adatok megsértésére. A Google statisztikái szerint az összes észlelt rosszindulatú bővítmény 42%-a használta a webRequest API-t. Megjegyzendő, hogy havonta átlagosan 1800 rosszindulatú bővítmény elhelyezésére irányuló kísérletet blokkolnak a Chrome Internetes áruház katalógusában. Sajnos az áttekintés nem teszi lehetővé, hogy kivétel nélkül minden rosszindulatú kiegészítőt elkapjunk, ezért a védelem fokozása érdekében úgy döntöttünk, hogy API-szinten korlátozzuk a kiegészítőket. A fő ötlet az, hogy a bővítményeket ne az összes forgalomhoz biztosítsák, hanem csak azokhoz az adatokhoz, amelyek szükségesek a tervezett funkcionalitás megvalósításához. Különösen a tartalom blokkolásához nem szükséges teljes hozzáférést biztosítani a bővítménynek az összes bizalmas felhasználói adathoz;
- Javasolt helyettesítő deklaratív API gondoskodik a nagy teljesítményű tartalomszűrés minden munkájáról, és csak a szűrési szabályok betöltéséhez van szüksége kiegészítőkre. A kiegészítő nem zavarhatja a forgalmat, és a felhasználó személyes adatai sérthetetlenek maradnak;
- A Google számos megjegyzést figyelembe vett a deklaratívNetRequest API funkcionalitásának hiányára vonatkozóan, és kiterjesztette a szűrési szabályok számának korlátját az eredetileg javasolt bővítményenkénti 30 ezerről a globális maximumra 150 ezerre, valamint hozzáadta a dinamikus szabályok módosítása és hozzáadása, HTTP-fejlécek eltávolítása és cseréje (Referer, Cookie, Set-Cookie) és paraméterek kérése;
- Vállalkozások számára lehetőség van a webRequest API blokkoló működési módjának használatára, mivel a kiegészítők használatára vonatkozó házirendet olyan rendszergazda határozza meg, aki ismeri az infrastruktúra jellemzőit és tisztában van a kockázatokkal. A megadott API például a vállalatoknál használható az alkalmazottak forgalmának rögzítésére és a belső rendszerekkel való integrációra;
- A Google célja nem a hirdetésblokkoló kiegészítők aláásása vagy elnyomása, hanem biztonságosabb és hatékonyabb hirdetésblokkolók létrehozásának lehetővé tétele;
- A webRequest API blokkoló működési módjának és az új deklaratív NetRequest-tel való kilépésétől való ódzkodást a bővítmények bizalmas adatokhoz való hozzáférésének korlátozása magyarázza. Ha a webRequest API-t úgy hagyja, ahogy van, a legtöbb kiegészítő nem használja a biztonságosabb deklaratív NetRequest-et, mivel a biztonság és a funkcionalitás közötti választás során a legtöbb fejlesztő általában a funkcionalitást választja.
:
- Kiegészítők fejlesztői vezették jelentéktelen általános hatást mutatnak a hirdetésblokkoló bővítmények teljesítményére (a tesztelés során összehasonlították a különböző kiegészítők teljesítményét, de nem vették figyelembe egy további folyamat többletköltségét, amely koordinálja a kezelők végrehajtását a blokkoló módban a webRequest API);
- Nem célszerű teljesen leállítani a kiegészítőkben aktívan használt API támogatását. Eltávolítása helyett hozzáadhat egy külön engedélyt, és szigorúan ellenőrizheti a kiegészítőkben való felhasználásának megfelelőségét, ami megkíméli számos népszerű kiegészítő szerzőjét a termékeik teljes átdolgozásától, és elkerülheti a funkcionalitás megszakítását;
- A rezsiköltségek csökkentése érdekében nem törölheti az API-t, hanem a Promise mechanizmus alapján készítheti újra, hasonlóan a webRequest Firefoxban való megvalósításához;
- A javasolt alternatíva, a deklaratív NetRequest nem fedi le a bővítmények fejlesztőinek összes hirdetésblokkolási és biztonsági/adatvédelmi igényeit, mivel nem biztosítja a hálózati kérések teljes körű ellenőrzését, nem teszi lehetővé az egyéni szűrőalgoritmusok használatát, és nem teszi lehetővé. összetett szabályok alkalmazása, amelyek a feltételektől függően átfedik egymást;
- A declarativeNetRequest API jelenlegi állapotában lehetetlen az uBlock Origin és az uMatrix kiegészítők meglévő funkcionalitását változatlanul újra létrehozni, és értelmetlenné teszi a NoScript-port Chrome-hoz való továbbfejlesztését;
- Az adatvédelemmel kapcsolatos aggodalmak távolról keltettek, mivel a webRequest API csak olvasható, nem blokkoló módja a helyén maradt, és továbbra is lehetővé teszi a rosszindulatú kiegészítők számára, hogy irányítsák az összes forgalmat, de nem ad lehetőséget a beavatkozásra a repülni (tartalom módosítása, hirdetéseinek elhelyezése, bányászok futtatása és a beviteli űrlapok tartalmának elemzése használható az oldal betöltődése után);
- Böngésző fejlesztők , и A Chromium motorra épülő webRequest blokkoló mód támogatását kívánják meghagyni termékeikben.
Forrás: opennet.ru