Kolejny odcinek telenoweli zatytułowanej „nowy manifest rozszerzeń przeglądarki Chromium”. Im więcej osób zdaje sobie sprawę, że zmiany w obsłudze API służą umacnianiu władzy Google nad tym, co wyświetlają przeglądarki, tym bardziej Google stara się nas przekonywać, że prawdziwą motywacją jest troska o internautów.
Tym razem Google opublikowało nie jeden, lecz dwa artykuły, które streścić można do prób przekonywania przez Google, że zmiany w manifeście podyktowane są kwestiami bezpieczeństwa. Na łamach bloga Chromium i Google Security Blog przedstawiciele korporacji przekonują, że wykorzystywane przez wiele diablo popularnych i lubianych rozszerzeń (uBlock, uMatrix, NanoBlock czy Ghostery) webRequest API może być wykorzystywane do kradzieży danych.
![manifest-1 manifest-1](/img/static/blog/keyword_asset_1_.png.webp)
webRequest API, jak wskazuje sama nazwa, modyfikuje żądania, przetwarzając ruch. Paradoksalnie to tej cesze np. uBlock zawdzięcza swoją popularność, gdyż pozbywanie się reklam ma miejsce już na etapie wysyłania żądania i uniemożliwia zaoszczędzenie cennego transferu. Dla Google nie ma to jednak znaczenia. Według korporacji jedynym wyjściem jest taka modyfikacja rozszerzeń, aby te wykorzystywały zamiennik webRequest API – declarativeNetRequest API.
Aby podeprzeć swoją narrację o bezpieczeństwie, Google dzieli się konkretnymi danymi: od stycznia 2018 roku 42% złośliwych rozszerzeń w ten lub inny sposób wykorzystywało webRequest API. Google nie dzieli się natomiast informacjami, jak wiele rozszerzeń blokujących reklamy wykorzystało to API w niecnym celu, co już naraziło korporację na kpiny. Czy w związku z tym, że w przypadku lwiej części napadów na bank wykorzystywany jest samochód, Google zakazałoby wszystkim poruszania się autami?
Pytań jest więcej. Skoro Google motywuje zmiany w manifeście bezpieczeństwem, to dlaczego pozwoli korzystać z webRequest API użytkownikom biznesowym, których bezpieczeństwo jest kluczowe? Według Google organizacje zazwyczaj dysponują administratorami, którzy zatroszczą się o „bezpieczne” użycie webRequest API. Krytycy kontrują, że w przypadku klientów enterprise po prostu nie zachodzi już konieczność zarabiania na wyświetlaniu reklam, więc Google może sobie pozwolić na dalsze udostępnianie im skutecznego webRequest API.
![manifest-2 manifest-2](/img/static/blog/pasted_image_0_1_.png.webp)
Na szczęście są i dobre wieści. Dotąd jednym z mankamentów declarativeNetRequest API była obsługa stosunkowo niewielkiej liczby reguł blokowania – mogło być ich maksymalnie 30 tys. Korporacja zapowiedziała w tej kwestii zmiany, w których rezultacie nowe API będzie mogło obsługiwać maksymalnie 150 tysięcy reguł, co jest już całkiem dorzeczną liczbą, biorąc pod uwagę stan wykorzystywanych dziś filtrów antyreklamowych.
Jak widać, opór i krytyka przynosi rezultaty, choć nic nie wskazuje na to, aby Google wycofało się z decyzji zablokowania webRequest API dla darmowych użytkowników, mimo że korporacja spotyka się z falą krytyki tak branżowych mediów, jak i użytkowników, twórców przeglądarek opartych na Blink/V8, a nawet programistów będących częścią społeczności zaangażowanej w rozwój Chromium.