Nadchodzące rozszerzenia Manifest V3 dla przeglądarki Google Chrome zmienią sposób działania programów blokujących reklamy w przeglądarce Chrome. Czy to właściwa droga dla programów blokujących reklamy i Google?
GoogleChrome to najpopularniejsza wieloplatformowa przeglądarka internetowa dostępna obecnie na rynku, zdobywając 62,7% światowego udziału w korzystaniu z przeglądarek do maja 2019 r., na drugim miejscu znalazła się przeglądarka Apple Safari z 15,89%, a Firefox Mozilli z 5,07%. Ze względu na lwią część, najmniejsze zmiany wprowadzane przez Google Chrome na swojej platformie wpływają na miliony użytkowników na całym świecie. Kiedy więc Google ogłosił kolejną wersję manifestu rozszerzeń w postaci Manifest V3 dla rozszerzeń Google Chrome, wiedzieliśmy, że tak czekały duże zmiany, zwłaszcza gdy wyszło na jaw, że Google pracuje nad interfejsem API blokowania treści w przeglądarce Chrome samo.
Co to jest Manifest V3?
Jeśli jesteś aktywnym użytkownikiem Chrome, niewątpliwie korzystasz z kilku rozszerzeń. Rozszerzenia to małe programy, które dostosowują sposób przeglądania za pomocą
Interfejsy API udostępniane przez przeglądarkę, umożliwiając użytkownikom dostosowanie funkcjonalności i zachowania do ich indywidualnych potrzeb i preferencji. Rozszerzenia te są dystrybuowane głównie poprzez Sklep internetowy Chrome, w którym znajduje się ponad 180 000 rozszerzeń.Od koniec zeszłego rokuGoogle pracuje nad „Manifest V3” – zestawem proponowanych zmian na platformie rozszerzeń Chrome, które można sklasyfikować jako „zmiany przełomowe”. jako dokument publicznej dyskusji dla Manifest V3 stwierdza, wersja manifestu rozszerzenia jest mechanizmem ograniczającym pewne możliwości do określonej klasy rozszerzeń. Ograniczenia te mogą mieć formę wersji minimalnej lub maksymalnej. Ograniczenie do wersji minimalnej pozwala, aby nowsze interfejsy API lub możliwości były dostępne tylko dla nowszych rozszerzeń ograniczenie do maksymalnej wersji manifestu umożliwia stopniowe udostępnianie starszych interfejsów API lub możliwości przestarzałe.
Mówiąc prościej, nowa wersja manifestu umożliwia Chrome ograniczenie interfejsów API i funkcji do tej nowej wersji manifestu, w aby zmusić twórców rozszerzeń do migracji z niektórych starszych interfejsów API ze względu na ich negatywny wpływ na użytkownika doświadczenie. Wdrożenie rozszerzenia w Manifest V3 powinno teoretycznie zapewnić silniejsze gwarancje z punktu widzenia bezpieczeństwa, prywatności i wydajności.
Chociaż w Manifest V3 przedstawiono szeroki zakres zmian, najbardziej kontrowersyjna zmiana dotyczy decyzji Google o ograniczeniu możliwości blokowania obecnych w istniejącym chrome.webRequest API (i skoncentruj API na obserwacji, a nie na blokowaniu), a następnie zaprezentuj te możliwości blokowania w nowy sposób chrome.declarativeNetRequest API. Ta konkretna zmiana ma rozgniewał społeczność ponieważ jego celem jest mechanizm blokowania reklam w słynnym rozszerzeniu blokującym reklamy, uBlock Origini bezpośrednio wpływa na ponad 10 milionów użytkowników.
Zanim zajmiemy się tym problemem, przyjrzyjmy się, w jaki sposób żądanie internetowe API porównuje deklaratywne żądanie sieciowe API.
Interfejs API żądań internetowych i deklaratywny interfejs API żądań sieciowych
Teraźniejszość
Oficjalny opis żądania internetowego opisuje interfejs API w następujący sposób:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Wraz z żądaniem internetowym Chrome wysyła Wszystko dane w żądaniu sieciowym do rozszerzenia nasłuchującego. Rozszerzenie ma wtedy szansę ocenić żądanie i poinstruować Chrome, co zrobić z żądaniem: zezwolić na nie, zablokować je lub wysłać z pewnymi modyfikacjami.
Prześledź sekwencję zdarzeń, aby zrozumieć, co się dzieje, gdy rozszerzenia korzystają z interfejsu API żądań sieciowych. Gdy użytkownik z zainstalowanym rozszerzeniem Web Request kliknie link, Chrome poinformuje rozszerzenie, że wysłano żądanie danych, zanim żądanie dotrze do serwera. Rozszerzenie może na tym etapie zmodyfikować żądanie. Następnie serwer odpowiada, ale odpowiedź ponownie przechodzi przez rozszerzenie, a rozszerzenie może decydować, czy odpowiedź wymaga modyfikacji. Następnie Chrome w końcu renderuje stronę, a użytkownik może zobaczyć wynik swojego kliknięcia.
Gdy Chrome przekaże wszystkie dane w żądaniu sieciowym, rozszerzenia korzystające z interfejsu Web Request API mają dostęp do odczytu i modyfikowania wszystkiego, co użytkownik robi w Internecie. Tak więc, chociaż programy blokujące treść, takie jak uBlock Origin, mądrze wykorzystują potencjał tego interfejsu API, Google tak twierdzi inne rozszerzenia o złośliwych intencjach wykorzystały je, aby uzyskać dostęp do danych osobowych użytkowników Informacja. Według Google od stycznia 2018 r. 42% złośliwych rozszerzeń korzystało z interfejsu Web Request API. Google twierdzi również, że interfejs API jako wersja blokująca wiąże się z „znacznymi kosztami wydajności”. wymaga to uporczywego i często długotrwałego procesu, zasadniczo nie do pogodzenia z „leniwym” procesy.
W wersji Manifest V3 Google proponuje ograniczenie tego interfejsu API w formie blokującej. Alternatywnie Google udostępnia interfejs API deklaratywnego żądania sieciowego.
Przyszłość
Oficjalny opis Declarative Net Request opisuje API w następujący sposób:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Dzięki deklaratywnemu żądaniu sieciowemu Chrome nie musi wysyłać wszystkich informacji o żądaniu do rozszerzenia nasłuchującego. Zamiast tego rozszerzenie rejestruje w przeglądarce Chrome reguły, które z wyprzedzeniem informują przeglądarkę, co zrobić, jeśli zostaną wyświetlone określone typy żądań.
Rozszerzenie określa z góry swoje reguły. Żądanie użytkownika jest następnie porównywane z tą regułą przez przeglądarkę (a nie rozszerzenie), a działanie jest również podejmowane przez przeglądarkę, a następnie strona jest renderowana. Google wspomina, że pozwala im to zapewnić efektywność, gdyż może sprawować kontrolę nad algorytmem wyznaczającym wynik oraz może zapobiegać lub wyłączać nieefektywne reguły. Zapewnia również lepsze gwarancje prywatności dla użytkownika końcowego, ponieważ szczegóły żądania sieciowego nie są ujawniane rozszerzeniu. Ponieważ trwałe i długotrwałe procesy nie są już potrzebne (ponieważ reguły są rejestrowane wcześniej), Google tak twierdzi podejście to zapewnia również poprawę wydajności, dzięki której rozszerzenia stają się znacznie bardziej opłacalne w przypadku ograniczonych zasobów platformy.
Deklaratywne żądanie sieciowe będzie dostępne zarówno w wersji Manifest V2 (bieżącej), jak i Manifest V3, ale będzie to główny sposób, w jaki Google umożliwi modyfikowanie żądań sieciowych w wersji Manifest V3.
Kontrowersja
Zmiany Google wydają się mieć sens, dopóki nie poznasz drugiej strony historii, głównie tej dotyczącej blokowania reklam. Ta konkretna migracja interfejsu API jest postrzegana jako sposób Google na pozbycie się programów blokujących reklamy, ponieważ zasadniczo zmienia sposób działania jednego z najpopularniejszych programów blokujących reklamy. Wiąże się to z „teorią”, że Google jest motywowany do tej zmiany bardziej z perspektywy biznesowej niż z perspektywy bezpieczeństwa użytkowników. W końcu przychody Google w dużym stopniu zależą od reklam, a programy blokujące reklamy są postrzegane w tym zakresie jako bezpośrednie zagrożenie dla klientów Google, jak ujawniono w Złożenie przez Alphabet formularza 10-K SEC 2018 (przez Rejestr):
Nowe i istniejące technologie mogą mieć wpływ na naszą zdolność dostosowywania reklam i/lub blokować reklamy online, co mogłoby zaszkodzić naszej firmie.
Opracowano technologie, które utrudniają dostosowywanie reklam lub całkowicie blokują wyświetlanie reklam u niektórych dostawców usług online ma zintegrowane technologie, które mogą potencjalnie osłabić podstawową funkcjonalność rozwiązań cyfrowych stron trzecich reklama. Większość naszych przychodów Google pochodzi z opłat płaconych nam w związku z wyświetlaniem reklam online. W efekcie tego rodzaju technologie i narzędzia mogą niekorzystnie wpłynąć na nasze wyniki operacyjne.
Google musiało wydać oświadczenie aby rozwiązać ten problem, powtarzając swoje stanowisko, że zmiana leży w interesie prywatności użytkowników, a nie jest bezpośrednim atakiem na programy blokujące reklamy:
Nie zapobiegamy rozwojowi programów blokujących reklamy ani nie uniemożliwiamy użytkownikom blokowania reklam. Zamiast tego chcemy pomóc programistom, w tym osobom blokującym treści, w pisaniu rozszerzeń w sposób chroniący prywatność użytkowników.
Należy zwrócić uwagę na dwa najpopularniejsze programy blokujące reklamy dostępne w przeglądarce Google Chrome: uBlock Origin I Adblock Plus, w obu przypadkach stosuje się różne podejścia, aby osiągnąć ten sam wynik blokowania treści. uBlock Origin w dużym stopniu opiera się na interfejsie Web Request API, a społeczność przez lata preferowała to rozszerzenie. Adblock Plus i inne rozszerzenia blokujące treść również opierają się na blokującej części żądania internetowego, więc zmiany w tym interfejsie API wpłyną przynajmniej w pewnym stopniu na większość blokerów treści.
Nacisk Google na wycofanie żądania internetowego zasadniczo zabije uBlock Origin w jego obecnym formacie, co rzeczywiście będzie miało wpływ na wielu użytkowników. Podczas gdy użytkownicy bez lojalności (i nie zamierzający zawracać sobie głowy sposobem osiągnięcia bloku reklam) znajdą alternatywne rozwiązania, które mają swoje wady, stanie się to niemożliwe dla lojalistów i entuzjastów opracowywanie nowych projektów silników filtrujących w celu obejścia różnych technik, które strony internetowe ostatecznie wymyślą w celu zwalczania programów blokujących reklamy w tym konkretnym interfejsie API.
Zaproponowano również, że deklaratywny żądanie sieciowe będzie raczej ograniczonym silnikiem filtrującym początkowo planowano mieć limit 30 000 reguł dla reguł filtrowania statycznego na rozszerzenie (reguły deklarowane podczas instalacji); i limit 5000 reguł dla reguł filtra dynamicznego na rozszerzenie (reguły, które można dodać po instalacji). Wszelkie nadmiarowe reguły zostaną zignorowane, co stanowi pewien problem, ponieważ sam EasyList dla Adblock Plus ma 70 000 reguł, podczas gdy uBlock Origin można skonfigurować tak, aby działał z ponad 100 000 reguł. Po początkowej reakcji społeczności, Google zareagowało obiecując zmianę statycznego limitu reguł z 30 000 reguł na rozszerzenie do globalnego maksimum wynoszącego 150 000 reguł. Ma to następnie skutek uboczny w postaci uniemożliwienia użytkownikom korzystania z innych skryptów zawierających duże ilości reguł w połączeniu z blokadą reklam, więc użytkownicy będą musieli pogodzić się ze swoimi preferencjami.
Poza ograniczonym limitem filtrowania, Deklaratywne żądanie sieciowe może przekierowywać tylko do statycznych adresów URL, więc nie ma obsługi dopasowywania wzorców. uBlock Origin w dużym stopniu opiera się na dopasowywaniu wzorców i twórcy rozszerzenia stwierdził, że nie ma możliwości modernizacji algorytm dopasowujący jego rozszerzenie, aby spełnić wymagania interfejsów API. Interfejs API wymagałby również pełnej aktualizacji rozszerzenia, aby po prostu zaktualizować listę filtrów, co byłoby zdecydowanie zbyt częstą czynnością, biorąc pod uwagę częstotliwość aktualizacji tych list filtrów. Oczywiście aktualizacje te będą również zależeć od kryteriów i procesów sprawdzania rozszerzeń Google.
Z drugiej strony Google zawsze utrzymywał swoje stanowisko, że jego zamiarem odejścia od żądania internetowego jest a punktu widzenia bezpieczeństwa, ponieważ interfejs Web Request API jest zbyt potężny w swojej obecnej formie i pozostawia bardzo szerokie pole do popisu nadużywać. To nadużycie nie jest tylko teoretyczne, ponieważ Google wspomniał, że 42% złośliwych rozszerzeń nadużywało tego interfejsu API. Apple Safari API blokowania treści został zaprojektowany podobnie jak Deklaracyjne żądanie sieciowe z podobnych powodów, ponieważ nieuczciwy programista ma mniej miejsca na wykorzystanie. W przypadku osłabionego żądania sieciowego żądania sieciowe będą nadal możliwe do zaobserwowania, ale będą wymagały uprawnień na odpowiednich hostach. W wersji Manifest V3 uprawnienia hosta również ulegają znaczącym zmianom i nie można ich już przyznawać w sposób ogólny podczas instalacji.
Google wykorzystał również koszty ogólne wydajności jako motywację do zmiany. Ocena żądań sieciowych odbywa się w wątku JavaScript rozszerzenia, co może kosztować wydajność. W ramach obalenia twórca uBlock Origin wspomina, że jego rozszerzenie nie powoduje żadnych znaczących spadków wydajności nawet w przypadku konieczności egzekwowania aż 140 000 filtrów statycznych. Twierdzi się, że poniesione koszty można łatwo odzyskać dzięki zasobom, które uniemożliwiają pobieranie ze zdalnych serwerów i tym samym nieprzetwarzanie przez przeglądarkę.
Chociaż Google nie korzysta z tego rozumowania, można również przedstawić jeden argument przeciwko żądaniu sieci Web, dotyczący wydajności blokowania reklam. W przypadku żądania internetowego, jeśli rozszerzenie nie odpowie na czas (z powodu opóźnienia lub awarii), żądanie obsługi sieci jest wyraźnie akceptowane, co pozwala reklamom prześlizgnąć się przez blokadę reklam. Z drugiej strony, deklaratywny żądanie netto nie miałby tej wady. Zamiast tego reklamy przejdą, jeśli nie zostaną złapane w statyczne reguły, a to zdarza się częściej.
Wniosek
Z powyższych wyjaśnień jasno wynika, że Deklaracyjne żądanie sieciowe nie jest klonem funkcjonalności 1:1 dla blokowania możliwości interfejsu Web Request API, a twórcy rozszerzeń z pewnością będą zdenerwowani, gdy ich ciężka praca zostanie utrudniona takie zmiany. Ale rozumowanie Google'a również ma znaczenie - żądanie sieciowe jest zbyt potężne i jego moc musi być ograniczone w większym interesie społeczności użytkowników (która składa się z przeciętnych użytkowników wraz z entuzjaści).
Przejście na deklaratywne żądanie sieciowe mogło być również pozytywnym posunięciem PR — w końcu Google dodaje do przeglądarki Chrome wbudowany interfejs API blokowania treści! Ponieważ jednak nowe API ma swoje własne, poważne ograniczenia, społeczność słusznie postrzega to jako podcięcie skrzydeł. W idealnym świecie Google powinien był zbadać działanie programów blokujących reklamy, takich jak uBlock Origin, przed wprowadzeniem nowego interfejsu API. W obecnym stanie nowy interfejs API mógłby jeszcze bardziej złagodzić ograniczenia reguł, aby uwzględnić scenariusze, w których użytkownicy chcieliby korzystać z dwóch rozszerzeń wymagających dużej liczby filtrów.
Według Rejestr, pierwsze kompilacje ze zmianami w Manifest V3 będą dostępne od lipca 2019 r. Mamy nadzieję, że Google uwzględni w tych kompilacjach opinie otrzymane od społeczności twórców rozszerzeń.
Specjalne podziękowania dla redaktora naczelnego XDA Mishaala Rahmana za jego wkład i pomoc!
Edycja: artykuł błędnie zrównał działanie Adblock Plus z działaniem deklaratywnego interfejsu API żądania sieciowego. Artykuł został odpowiednio zmieniony. Na Adblock Plus wpłynie również usunięcie możliwości blokowania Web Request API.