W ubiegłym roku aktywnie uczestniczyliśmy w rozmowach z dostawcami, którzy stoją za kilkoma rozszerzeniami do blokowania treści, na temat tego, jak ulepszyć platformę rozszerzeń MV3. Na podstawie tych dyskusji, z których wiele z nich przeprowadzono w grupie WECG (WebExtensions Community Group) we współpracy z innymi przeglądarkami, udało nam się wprowadzić istotne ulepszenia.
Więcej statycznych zestawów reguł
Zbiory reguł filtrowania są zwykle grupowane w listy. Bardziej ogólna lista może na przykład zawierać reguły dotyczące wszystkich użytkowników, a bardziej szczegółowa lista może ukrywać treści związane z lokalizacją, które chcą zablokować tylko niektórzy użytkownicy. Do niedawna pozwalaliśmy każdemu rozszerzeniu udostępniać użytkownikom 50 list (czyli „statycznych zestawów reguł”) i jednocześnie włączonych 10 z nich. Podczas dyskusji ze społecznością deweloperzy rozszerzeń przedstawili przekonujące dowody, które dowodzą, że w niektórych przypadkach te wskaźniki były za niskie. Biorąc pod uwagę te kwestie, po przyjrzeniu się wydajności interfejsu API w Chrome postanowiliśmy zezwolić na jednoczesne korzystanie z maksymalnie 50 interfejsów. (Co więcej, jest to znacznie więcej niż limit 20 żądań wymaganych przez WECG). Łącznie można utworzyć 100 zestawów reguł. Funkcja ta jest dostępna w przeglądarce Chrome 120, a zwiększanie limitów jest obsługiwane zarówno w Firefoksie, jak i Safari, które wcześniej wskazały tę ofertę.
Więcej reguł dynamicznych
Większość reguł jest „statyczna” i jest wysyłana po każdej aktualizacji rozszerzenia. Jednak w celu obsługi częstszych aktualizacji i reguł definiowanych przez użytkownika rozszerzenia mogą też dodawać reguły dynamicznie, bez konieczności przesyłania przez deweloperów nowych wersji rozszerzenia do Chrome Web Store.
Gdy rozszerzenie może dynamicznie modyfikować żądania w sposób, który nie był sprawdzany podczas sprawdzania w Chrome Web Store, naraża to użytkowników na ryzyko phishingu lub kradzieży danych. Reguła przekierowania może na przykład zostać niewłaściwie użyta do wstrzyknięcia linków do witryny partnerskiej bez jej zgody.
Dlatego w rozszerzeniach można było dodać maksymalnie 5000 reguł, co ułatwia oszczędne korzystanie z tej funkcji i ułatwia wykrywanie nadużyć.
Jednak deweloperzy z rozszerzeń takich jak AdGuard i Adblock Plus przeprowadzili własną analizę i udostępnili dane, które pozwoliłyby na udostępnienie bardziej aktualnych reguł, a użytkownikom z większą liczbą list niestandardowych – przeniesienie ich do platformy Manifest V3. Firma AdGuard poinformowała, że w każdym tygodniu na popularnych listach jest wprowadzanych ponad 2600 zmian. Jeden na 4 z 5% użytkowników korzystających z list z filtrami niestandardowymi ma w sumie ponad 5000 reguł dynamicznych (źródło). Zespół AdGuard uznaje to za istotne wyzwanie w związku z migracją rozszerzenia do platformy Manifest V3. Podobne opinie słyszeliśmy od innych programów do blokowania treści.
Ustaliliśmy, że niektóre reguły filtrowania, na przykład te z działaniem block lub allow, są dużo bezpieczniejsze i mniej prawdopodobne, że będą nadużywane. Stanowią też większość reguł filtra blokowania reklam. Na tej podstawie przygotowałem i udostępniłem propozycję w grupie społeczności rozszerzeń internetowych, aby określić zestaw reguł, które uznajemy za niższe, i dopuszczamy do 30 000 takich reguł. Nadal obowiązuje górny limit, aby uniknąć spadków wydajności.
Ta propozycja była obsługiwana przez grupę społeczności rozszerzeń internetowych, więc wdrożyliśmy ją. Począwszy od wersji Chrome 121 wyższy limit 30 000 reguł obowiązuje w przypadku bezpiecznych reguł DNR, które definiujemy jako reguły z działaniem block, allow, allowAllRequests lub upgradeScheme.
Z danych udostępnianych przez AdGuard wynika, że wyższy limit powinien być korzystny w 98–99% reguł. Pozostałe reguły są nadal obsługiwane i można je dodać w ramach dotychczasowego limitu.
Ta wartość jest dostępna w Chrome jako stała MAX_NUMBER_OF_DYNAMIC_RULES. W przypadku pozostałych dynamicznych reguł żądań sieciowych limit reguły 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 filtrującej według adresu URL wielkość liter ma znaczenie. Dowiedzieliśmy się, że większość programistów ma inne rozszerzenia domyślne w swoich rozszerzeniach. W związku z tym wartość musiała być ustawiana wiele razy. Dzięki tej zmianie deweloperzy mogą znacznie zmniejszyć rozmiar swoich zestawów reguł.
Co dalej?
Cały czas będziemy inwestować w interfejs declarativeNetRequest API, aby móc obsługiwać jak najwięcej przypadków użycia. Liczymy na dalszą współpracę ze społecznością. W szczególności chcemy podziękować członkom WECG za ich zaangażowanie, w tym za udostępnianie znacznej ilości danych, dzięki którym ta praca była korzystna, oraz wszystkim dostawcom przeglądarek, którzy odegrali ważną rolę w skonstruowaniu tego interfejsu API.
Będziemy nadal sprawdzać obowiązujące limity, aby w razie potrzeby wprowadzać odpowiednie zmiany. W związku z tym planujemy udostępnić w najbliższej przyszłości niektóre dane, które zebraliśmy w ramach tych prac. Pracujemy też nad dodaniem dodatkowych funkcji, takich jak dopasowywanie do nagłówków odpowiedzi, co jest częstym żądaniem z rozszerzeń do przeglądarek plików PDF. We wszystkich przypadkach będziemy nadal informować o naszej pracy i regularnie korzystać z grupy społeczności rozszerzeń internetowych, aby omawiać swoje pomysły i ustalać, co powinniśmy zrobić w następnej kolejności.