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.
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.
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.
