W ciągu ostatniego roku angażowaliśmy się w rozmowy z dostawcami, którzy opracowują kilka rozszerzeń do blokowania treści, aby pomóc nam ulepszyć platformę rozszerzeń MV3. Na podstawie tych dyskusji, wielu z nich, które przeprowadzono w grupie WebExtensions Community Group (WECG) we współpracy z innymi przeglądarkami, udało nam się wprowadzić istotne ulepszenia.
Więcej statycznych zestawów reguł
Zestawy reguł filtrowania są zwykle pogrupowane w listy. Na przykład bardziej ogólna lista może zawierać reguły obowiązujące wszystkich użytkowników, a bardziej szczegółowa lista może ukrywać treści dotyczące lokalizacji, które tylko niektórzy użytkownicy chcą zablokować. Do niedawna pozwalaliśmy każdemu rozszerzeniu na oferowanie użytkownikom do wyboru 50 list (czyli „statycznych zestawów reguł”), przy czym każdy z nich mógł być włączonych jednocześnie. W rozmowach ze społecznością deweloperzy rozszerzeń przedstawili przekonujące dowody na to, że w niektórych przypadkach użycia ta wartość była zbyt niska. Mając na uwadze powyższe kwestie związane z wydajnością interfejsu API w Chrome, postanowiliśmy obecnie włączyć maksymalnie 50 interfejsów API jednocześnie. (W szczególności liczba ta znacznie przekracza limit 20 ustanowiony przez WECG). puścimy łącznie 100 zbiorów reguł. Ta funkcja jest dostępna w Chrome 120, a zwiększenie limitów jest obsługiwane przez przeglądarki Firefox i Safari, które na wczesnym etapie dostarczyły informacji na temat tej oferty.
Więcej reguł dynamicznych
Większość reguł jest „statyczna” i jest wysyłana z każdą aktualizacją rozszerzenia. Jednak ze względu na częstsze aktualizacje i reguły zdefiniowane przez użytkownika rozszerzenia mogą dynamicznie dodawać reguły, dzięki czemu programiści nie muszą przesyłać nowej wersji rozszerzenia do Chrome Web Store.
Jeśli rozszerzenie może dynamicznie modyfikować żądania w sposób, który nie został sprawdzony w Chrome Web Store, naraża to użytkowników na ryzyko wyłudzenia informacji lub kradzieży danych. Na przykład reguła przekierowania mogła zostać niewłaściwie wykorzystana do wstawienia linków do witryn partnerskich bez uzyskania zgody użytkownika.
Dlatego zezwoliliśmy na dodanie maksymalnie 5000 reguł, co zachęcało do korzystania z tej funkcji oszczędnie i ułatwiło nam wykrywanie nadużyć.
Deweloperzy korzystający z rozszerzeń takich jak AdGuard i Adblock Plus przeprowadzili jednak własną analizę i udostępnili dane, zgodnie z którymi wyższy limit pozwoliłby na korzystanie z bardziej aktualnych reguł, a użytkownicy z większą liczbą list niestandardowych mogli przejść na platformę Manifest V3. Zespół AdGuard poinformował, że w każdym tygodniu na popularnych listach jest wprowadzanych ponad 2600 zmian, a w przypadku 5 procent użytkowników korzystających z niestandardowych list filtrów 1 na 4 ma łącznie ponad 5000 reguł dynamicznych (źródło). Firma AdGuard uznała to za poważne wyzwanie związane z migracją rozszerzenia na Manifest V3 i otrzymaliśmy podobne opinie od innych firm blokujących treści.
Ustaliliśmy, że niektóre reguły filtrowania, na przykład te z działaniem block
lub allow
, są znacznie bezpieczniejsze i rzadsze nadużywanie. Stanowią też zdecydowaną większość reguł filtra bloków reklamowych. Dlatego przygotowałam wersję roboczą i udostępniłam ją w grupie społeczności rozszerzeń internetowych, aby zdefiniować zestaw reguł,które uważamy za mniejsze ryzyko i dozwolone są maksymalnie 30 tys. takich zmian. Nadal utrzymujemy górny limit, aby uniknąć spadków wydajności.
Ta propozycja została zatwierdzona przez grupę społeczności rozszerzeń internetowych, więc wdrożyliśmy ją. Od wersji Chrome 121 w przypadku bezpiecznych reguł DNR, które definiujemy jako reguły z działaniem block
, allow
, allowAllRequests
lub upgradeScheme
, obowiązuje wyższy limit 30 000 reguł.
Z danych udostępnianych przez AdGuard wynika, że ten wyższy limit powinien skorzystać 98–99% reguł. Pozostałe reguły są nadal obsługiwane i można je dodawać w ramach bieżącego limitu.
Jest ona dostępna w Chrome jako stała MAX_NUMBER_OF_DYNAMIC_RULES. W przypadku wszystkich innych reguł dynamicznych żądań sieci limit reguł wynosi 5000.
Zmniejszony rozmiar zestawu reguł
Na podstawie opinii społeczności w Chrome 118 zmieniliśmy domyślną wartość pola isUrlFilterCaseSensitive
na false
. To pole określa, czy w regule filtrowania według adresu URL wielkość liter ma znaczenie, i dowiedzieliśmy się, że większość deweloperów ma w swoim rozszerzeniu inną wartość domyślną. W związku z tym wartość trzeba było ustawić wielokrotnie. Wprowadzając tę zmianę, deweloperzy mogą znacznie zmniejszyć rozmiar swoich zbiorów reguł.
Co dalej?
Zależy nam na ciągłym inwestowaniu w interfejs declarativeNetRequest API, abyśmy mogli obsługiwać jak najwięcej przypadków użycia. Cieszymy się, że będziemy kontynuować współpracę ze społecznością. W szczególności chcemy podziękować członkom WECG za zaangażowanie, w tym AdGuard za udostępnienie sporej ilości danych niezbędnych do przeprowadzenia tych działań, a także wszystkim dostawcom przeglądarek, którzy zaprojektowali ten interfejs API.
Będziemy na bieżąco sprawdzać limity, aby w razie potrzeby wprowadzać odpowiednie zmiany. W tym celu planujemy udostępnić w najbliższej przyszłości część danych, które zgromadziliśmy w ramach tych prac. Pracujemy też nad dodatkowymi możliwościami, takimi jak możliwość dopasowywania danych do nagłówków odpowiedzi, co jest częstym żądaniem z rozszerzeń przeglądarki PDF. We wszystkich przypadkach będziemy nadal informować o naszej pracy i regularnie korzystać z grupy społeczności rozszerzeń internetowych, by omówić pomysły i ustalić, co powinniśmy omówić w przyszłości.