Firma Mozilla ogłosiła rozpoczęcie testowania implementacji trzeciej wersji manifestu Chrome w przeglądarce Firefox, który określa możliwości i zasoby dostępne dla dodatków napisanych przy użyciu API WebExtensions. Aby przetestować trzecią wersję manifestu w wersji beta Firefox 101, należy ustawić parametr „extensions.manifestV3.enabled” na wartość true, a parametr „xpinstall.signatures.required” na wartość false na stronie about:config. Do instalacji dodatków można użyć interfejsu about:debugging. Włączenie trzeciej wersji manifestu domyślnie planowane jest na koniec roku.
Od wersji 57 Firefox całkowicie przeszedł na używanie API WebExtensions do tworzenia dodatków i zakończył wsparcie dla technologii XUL. Przejście na WebExtensions pozwoliło zjednolicić rozwój dodatków z platformami Chrome, Opera, Safari i Edge, uprościło portowanie dodatków między różnymi przeglądarkami internetowymi oraz umożliwiło pełne wykorzystanie trybu pracy wieloprocesowej (dodatki WebExtensions mogą działać w oddzielnych procesach, izolowanych od innych części przeglądarki). Aby zrealizować zjednolicony rozwój dodatków z innymi przeglądarkami, Firefox zapewnia prawie pełną kompatybilność z drugą wersją manifestu Chrome.
Obecnie w Chrome trwają prace nad przejściem na trzecią wersję manifestu, a wsparcie dla drugiej wersji zostanie zakończone w styczniu 2023 roku. Ponieważ trzecia wersja manifestu spotkała się z krytyką i spowoduje problemy z funkcjonowaniem wielu dodatków do blokowania niechcianych treści oraz zapewniania bezpieczeństwa, firma Mozilla zdecydowała się odejść od praktyki zapewniania pełnej kompatybilności z manifestem w Firefox i wprowadzić niektóre zmiany inaczej.
Główne zastrzeżenie dotyczące trzeciej wersji manifestu wiąże się z przeniesieniem API webRequest w tryb tylko do odczytu, co uniemożliwia podłączanie własnych obsług żądania, które miały pełny dostęp do zapytań sieciowych i mogły w czasie rzeczywistym modyfikować ruch. Wspomniane API jest stosowane w uBlock Origin oraz wielu innych rozszerzeniach służących do blokowania niechcianych treści i zapewnienia bezpieczeństwa. Zamiast API webRequest w trzeciej wersji manifestu zaproponowano ograniczone API declarativeNetRequest, które zapewnia dostęp do wbudowanego silnika filtrowania, samodzielnie przetwarzającego zasady blokowania, nie pozwalającego na stosowanie własnych algorytmów filtrowania i nie umożliwiającego definiowania skomplikowanych zasad, które wzajemnie się nakładają w zależności od warunków.
W zaproponowanej w Firefox implementacji trzeciej wersji manifestu dodano nowy deklaratywny interfejs API do filtrowania treści, ale w przeciwieństwie do Chrome nie skoncentrowano się na zakończeniu wsparcia dla starego blokującego trybu działania API webRequest. Wśród innych cech implementacji nowego manifestu w Firefox znajdują się:
- Manifest określa zastąpienie stron tła wariantem Service Workers, działającym jako procesy tła (Background Service Workers). Aby zapewnić zgodność z Firefox, to wymaganie zostanie wdrożone, ale dodatkowo zaproponowano nowy mechanizm Event Pages, który jest bardziej znajomy dla programistów webowych, nie wymaga pełnego przeprojektowania dodatków i eliminuje ograniczenia związane z używaniem Service Workers. Event Pages pozwoli na dostosowanie istniejących dodatków z stronami tła do wymagań trzeciej wersji manifestu, jednocześnie zachowując dostęp do wszystkich możliwości niezbędnych do pracy z DOM. W dostępnej do testowania implementacji manifestu w Firefox wspierane są tylko Event Pages, a wsparcie dla rozwiązania opartego na Service Workers obiecano dodać później. Propozycję poparła firma Apple, która wdrożyła Event Pages w wydaniu Safari Technology Preview 136.
- Nowy granularny model żądania uprawnień — rozszerzenie nie będzie mogło aktywować się od razu na wszystkich stronach (usunięto uprawnienie „all_urls”), a będzie działać tylko w kontekście aktywnej karty, tzn. użytkownik będzie musiał potwierdzić działanie rozszerzenia dla każdej strony. W Firefox wszystkie żądania dostępu do danych strony będą traktowane jako opcjonalne, a ostateczną decyzję o przyznaniu dostępu podejmie użytkownik, który będzie mógł wybiórczo decydować, któremu rozszerzeniu przyznać dostęp do swoich danych na danej stronie.
- Zmiana w obsłudze zapytań cross-origin – zgodnie z nowym manifestem, na skrypty przetwarzania treści będą miały zastosowanie te same ograniczenia praw, co do głównej strony, do której te skrypty są wbudowane (na przykład, jeśli strona nie ma dostępu do API lokalizacji, skrypt dodatku również nie uzyska tego dostępu). Ta zmiana jest całkowicie wdrożona w Firefox.
- API oparte na Promise. Firefox już wspiera to API i w trzeciej wersji manifestu przeniesie je do przestrzeni nazw „chrome.*”.
- Zakaz wykonywania kodu, załadowanego z zewnętrznych źródeł. serwerów (mowa o sytuacjach, w których dodatek ładował i wykonywał zewnętrzny kod). W Firefox stosowana jest już blokada zewnętrznego kodu, a programiści Mozilla dodali dodatkowe techniki śledzenia ładowania kodu, proponowane w trzeciej wersji manifestu. Dla skryptów obsługujących treść wprowadzono oddzielną politykę ograniczeń dostępu do treści (CSP, Content Security Policy).
Źródło: opennet.ru
