W ciągu ostatniego roku prowadziliśmy aktywne rozmowy z dostawcami różnych rozszerzeń blokujących treści na temat sposobów ulepszania platformy rozszerzeń MV3. Na podstawie tych rozmów, z których wiele miało miejsce w grupie WECG (WebExtensions Community Group) we współpracy z innymi przeglądarkami, wprowadziliśmy znaczne ulepszenia.
Więcej statycznych zestawów reguł
Zestawy reguł filtra są zwykle grupowane na listy. Na przykład bardziej ogólna lista może zawierać reguły stosowane do wszystkich użytkowników, a bardziej szczegółowa może ukrywać treści związane z lokalizacją, które chcą blokować tylko niektórzy użytkownicy. Do niedawna każde rozszerzenie mogło oferować użytkownikom 50 list (czyli „statycznych zestawów reguł”), z których 10 można było włączyć jednocześnie. W trakcie rozmów z użytkownikami deweloperzy rozszerzeń przedstawili przekonujące dowody na to, że w przypadku niektórych zastosowań ten limit jest zbyt niski. Po przeanalizowaniu wydajności interfejsu API w Chrome w świetle tych dyskusji zezwalamy teraz na jednoczesne włączenie do 50 interfejsów. (jest to znacznie więcej niż limit 20 wymagany w WECG). Pozwalamy też na 100 reguł łącznie. Funkcja ta jest dostępna w Chrome 120. Zwiększenie limitów jest obsługiwane przez przeglądarki Firefox i Safari, które przekazały nam wstępne opinie na temat tej propozycji.
Więcej reguł dynamicznych
Większość reguł jest „statyczna” i wysyłana wraz z każdą aktualizacją rozszerzenia. Aby jednak obsługiwać częstsze aktualizacje i reguły definiowane przez użytkownika, rozszerzenia mogą też dodawać reguły dynamicznie, bez konieczności przesyłania nowej wersji rozszerzenia do Chrome Web Store.
Jeśli rozszerzenie może dynamicznie modyfikować żądania w sposób, który nie został sprawdzony podczas weryfikacji w Chrome Web Store, użytkownicy są narażeni na ryzyko wyłudzenia informacji lub kradzieży danych. Na przykład reguła przekierowania może zostać wykorzystana do wstawiania linków afiliacyjnych bez zgody.
W rezultacie zezwoliliśmy na dodanie maksymalnie 5000 reguł, co zachęcało do oszczędnego korzystania z tej funkcji i ułatwiało nam wykrywanie nadużyć.
Deweloperzy rozszerzeń, w tym AdGuard i Adblock Plus, przeprowadzili jednak własną analizę i udostępnili dane, które wskazują, że wyższy limit pozwoliłby na stosowanie bardziej aktualnych reguł i ułatwiłby użytkownikom z większą liczbą list niestandardowych przejście na Manifest V3. AdGuard twierdzi, że co tydzień wprowadza się ponad 2600 zmian na popularnych listach, a wśród 5% użytkowników korzystających z list filtrów niestandardowych co czwarty ma łącznie ponad 5000 reguł dynamicznych (źródło). AdGuard zauważył, że jest to poważne wyzwanie w przypadku przenoszenia rozszerzenia na Manifest 3.0. Otrzymaliśmy podobne opinie od innych blokujących treści.
Ustaliliśmy, że niektóre reguły filtrów, np. te z działaniem block lub allow, są znacznie bezpieczniejsze i mają mniejsze prawdopodobieństwo nadużyć. Stanowią one też większość reguł filtrów blokowania reklam. W związku z tym w ramach grupy dotyczącej rozszerzeń internetowych sporządziliśmy i opublikowaliśmy propozycję, która określa zestaw reguł,które naszym zdaniem stanowią mniejsze zagrożenie i umożliwiają dodanie do 30 tys. rozszerzeń. Nadal utrzymujemy górny limit, aby uniknąć regresji skuteczności.
Ta propozycja została poparta przez grupę społecznościową Web Extensions, więc ją wdrożyliśmy. Począwszy od Chrome 121 wyższy limit 30 tys. reguł dotyczy bezpiecznych reguł DNR, które definiujemy jako reguły z działaniem block, allow, allowAllRequests lub upgradeScheme.
Na podstawie danych udostępnionych przez AdGuard od 98 do 99 procent reguł powinno korzystać z wyższego limitu. Pozostałe reguły są nadal obsługiwane i można je dodawać w ramach obecnego limitu.
W Chrome jest to stała MAX_NUMBER_OF_DYNAMIC_RULES. Limit reguł dla wszystkich pozostałych dynamicznych reguł żądań sieciowych pozostaje na poziomie 5000.
Zmniejszony rozmiar reguł
W Chrome 118 zmieniliśmy domyślną wartość pola isUrlFilterCaseSensitive na false na podstawie opinii społeczności. To pole określa, czy reguła filtrująca adresy URL rozróżnia wielkość liter. Okazało się, że większość deweloperów miała inną domyślną wartość w swojej rozszerzeniu. W związku z tym wartość musiała być ustawiana wiele razy. Dzięki tej zmianie deweloperzy mogą znacznie zmniejszyć rozmiar swoich zbiorów reguł.
Co dalej?
Będziemy nadal inwestować w interfejs API declarativeNetRequest, aby obsługiwać jak najwięcej przypadków użycia. Z niecierpliwością czekamy na dalszą współpracę z użytkownikami. Szczególnie dziękujemy członkom grupy roboczej WECG za zaangażowanie, w tym firmie AdGuard za udostępnienie znacznej ilości danych, które umożliwiły nam realizację tego projektu, oraz wszystkim dostawcom przeglądarek, którzy w znacznym stopniu przyczynili się do opracowania tego interfejsu API.
Będziemy nadal sprawdzać obowiązujące limity, aby w razie potrzeby wprowadzić odpowiednie zmiany. W tym celu w najbliższej przyszłości udostępnimy część danych zebranych w ramach tych prac. Dodatkowo pracujemy nad dodaniem dodatkowych funkcji, takich jak możliwość dopasowywania nagłówków odpowiedzi, co jest częstym żądaniem ze strony rozszerzeń czytników PDF. W każdym przypadku będziemy informować o naszych działaniach i regularnie korzystać z grupy społecznościowej rozszerzeń internetowych, aby omawiać pomysły i ustalać, nad czym chcielibyśmy pracować w kolejnej kolejności.