Kontrowersje wokół ograniczającego możliwości blokujących reklamy rozszerzeń Chrome standardu Manifest v3 nie ustają. Już wiadomo, że wiele firm tworzących przeglądarki na bazie opensource’owego Chromium po prostu nie wprowadzi do nich zmian forsowanych przez Google, co w praktyce oznacza koniec kompatybilności i konieczność budowania oddzielnych wersji rozszerzeń. To jednak nie wszystko. Idąc na wojnę z blokerami reklam, Google mogło niechcący przyczynić się do udoskonalenia technologii blokowania. Przełomem może pochwalić się producent niezależnej przeglądarki Brave.
Jak wiadomo, Google zamierza zmienić webRequest API w Chromium/Chrome tak, aby uniemożlić rozszerzeniom przechwytywanie żądań sieciowych w celu ich modyfikacji, przekierowania lub zablokowania. Zamiast tego webRequest API zostałoby zredukowane do roli obserwacyjnej, stałoby się narzędziem pasywnego śledzenia żądań sieciowych przez rozszerzenia. Oficjalne uzasadnienie – chęć uniknięcia spowolnienia ładowania stron przez rozszerzenia oraz zapewnienie użytkownikom większej kontroli nad uprawnieniami rozszerzeń.
Szybkie blokowanie dla szybkiego ładowania
Być może taka właśnie intencja deweloperom Chromium przyświecała, jednak branża odczytała to jednoznacznie, jako chęć zneutralizowania wydajnych rozszerzeń blokujących reklamy, a co za tym idzie, psujących biznes Google’a. Niemniej jednak zarazem cała sprawa przypomniała, że wydajność blokerów reklam pozostawia sporo do życzenia. Implementowane w pisanych w JavaScripcie rozszerzeniach muszą spowalniać wczytywanie współczesnych stron. A biorąc pod uwagę to, że typowa współczesna strona to 75 żądań, z których każde musi być sprawdzone na dziesiątkach tysięcy reguł filtrowania, narzut ten jest całkiem spory.
A co, gdyby bloker reklam stał się częścią kodu samej przeglądarki? Tak właśnie jest to zrobione w Brave. Zabezpieczenia Brave Browser Shield, służące osłonięciu użytkownika przed trackerami, reklamami i malware, zostały zaimplementowane na bazie napisanego w C++ silnika filtrującego. Przetwarza on żądania z narzutem nie przekraczającym milisekundy, karmiąc się standardowymi filtrami o składni Adblock Plusa.
Właśnie dlatego afera z Manifestem v3 nie wywołała większego poruszenia wśród twórców Brave – ich przeglądarka przetwarza żądania natywnie, głęboko w swoim stosie sieciowym. Zwróciła jednak ich uwagę na kwestię wydajności. Niespełna milisekunda na żądanie to niewiele, jednak czy nie można byłoby tego przyspieszyć? Ostatnie testy przeprowadzone przez deweloperów Cliqz/Ghostery pokazały, że wiele można tu jeszcze poprawić.
Rust – nie tylko bezpieczeństwo
Ulepszenie Brave przyszło w postaci przepisania całej technologii blokowania reklam w stworzonym przez Mozillę języku Rust, oraz ulepszeniu algorytmu parsowania reguł. Wydana już w kanałach dev i nightly wersja okazuje się być średnio aż 69 razy wydajniejsza od starego rozwiązania w C++, zmniejszając średni czas klasyfikacji jednego żądania do 5,6 mikrosekundy, czyli 420 mikrosekund dla typowej strony. Taki narzut nie tylko jest już zdecydowanie poniżej progu ludzkiej percepcji, ale też co szczególnie ważne, zwalnia zasoby procesora dla innych zadań.
Wyniki te pokazują, że kontekst, w którym działa bloker to coś, czego nie da się przeskoczyć. Głębsza integracja w przeglądarce oznacza, że można uruchamiać zoptymalizowany, natywny kod, zmniejszając koszty przetwarzania danych. W dodatku, jako że przeglądarka już wykonuje część pracy użytecznej dla blokera, można uniknąć powielania wielu aktywności i jeszcze bardziej zredukować narzut.
Warto wspomnieć też, że nowy algorytm Brave obsługuje również więcej reguł blokowania i pomoże w walce ze skryptami ograniczającymi funkcjonalność stron po wykryciu blokerów. Więcej informacji znajdziecie oczywiście na blogu Brave .
