Firma Mozilla opublikowała plan wdrożenia w Firefox trzeciej wersji manifestu Chrome, definiującego możliwości i zasoby dostępne dla rozszerzeń. Trzecia wersja manifestu została skrytykowana za zakłócanie działania wielu rozszerzeń do blokowania niepożądanego kontentu i zapewniania bezpieczeństwa.
W Firefox zamierzają wdrożyć prawie wszystkie możliwości i ograniczenia nowego manifestu, w tym deklaratywne API do filtrowania treści (declarativeNetRequest), jednak w przeciwieństwie do Chrome w Firefox nie zakończy się wsparcie dla starego trybu blokowania API webRequest, przynajmniej dopóki nowe API nie spełni w pełni potrzeb deweloperów korzystających z API webRequest. Takie podejście umożliwi zapewnienie zgodności z rozszerzeniami Chrome bez naruszania kompatybilności z rozszerzeniami opartymi na API webRequest.
Przypomnijmy, że główne niezadowolenie z nowego manifestu wynika z przejścia API webRequest w tryb tylko do odczytu, co uniemożliwia podłączanie własnych handlerów mających pełen dostęp do zapytań sieciowych i zdolnych do modyfikacji ruchu w locie. Wspomniane API wykorzystywane jest w uBlock Origin i wielu innych rozszerzeniach do blokowania niepożądanego kontentu i zapewniania bezpieczeństwa. Zamiast API webRequest zaproponowano API declarativeNetRequest, ograniczone w swoich możliwościach, które udostępnia dostęp do wbudowanego silnika filtrowania, samodzielnie przetwarzającego zasady blokowania, nie pozwalającego na korzystanie z własnych algorytmów filtrowania oraz nieumożliwiającego definiowania złożonych zasad, które się wzajemnie pokrywają w zależności od warunków.
W Firefox planowane jest udostępnienie wsparcia dla trzeciej wersji manifestu Chrome do testów pod koniec 2021 roku, a wdrożenie nowego manifestu przewidziano na początku 2022 roku. Wśród cech realizacji nowego manifestu w Firefox wyróżnia się:
- Udzielenie API declarativeNetRequest, ale z zachowaniem możliwości korzystania ze starego API webRequest.
- Zmiana przetwarzania zapytań z innego źródła — zgodnie z nowym manifestem dla skryptów przetwarzania treści będą obowiązywały te same ograniczenia, co dla głównej strony, do której te skrypty są wbudowywane (na przykład, jeśli strona nie ma dostępu do API określenia lokalizacji, to również skrypt dodatku nie zyska tego dostępu). Część związanych z ograniczeniami zapytań z innego źródła zmian jest już dostępna do testowania w nocnych kompilacjach Firefox (rozwijane w ramach projektu Fission, który można włączyć w about:preferences#experimental) i planowane jest do powszechnego wdrożenia w trzecim kwartale 2021 roku.
- Strony w tle zostaną zastąpione przez Service workers, działające w formie procesów w tle. Zmiana ta nie jest jeszcze gotowa do rozpoczęcia testów.
- API oparte na Promise. Firefox już obsługuje ten typ API w przestrzeni nazw „browser.*” i dla trzeciej wersji manifestu przeniesie go do przestrzeni nazw „chrome.*”.
- Nowy uszczegółowiony model zapytania uprawnień — dodatek nie będzie mógł aktywować się od razu dla wszystkich stron (usunięto uprawnienie „all_urls”), a będzie działać tylko w kontekście aktywnej zakładki, tzn. użytkownik będzie musiał potwierdzać działanie dodatku dla każdej witryny. Firma Mozilla pracuje nad wzmocnieniem kontroli dostępu, ale zamierza umożliwić użytkownikom samodzielne podejmowanie decyzji, czy pozwolić dodatkom działać z różnymi zakładkami.
- Zakaz wykonywania kodu, załadowanego z zewnętrznych źródeł. serwerów (mowa o sytuacjach, gdy dodatek ładuje i wykonuje zewnętrzny kod). W Firefoxie już stosuje się blokowanie zewnętrznego kodu, a deweloperzy Mozilli są gotowi dodać dodatkowe techniki śledzenia ładowania kodu, zaproponowane w trzeciej wersji manifestu. Dla skryptów przetwarzania treści zostanie przedstawiona osobna polityka ograniczenia dostępu do treści (CSP, Content Security Policy), a istniejące API userScripts i contentScripts zostaną przerobione na potrzeby rozszerzeń opartych na Service worker.
Źródło: opennet.ru
