Mozilla ogłosiła, że rozpoczęła testowanie implementacji w Firefoksie trzeciej wersji manifestu Chrome, która definiuje możliwości i zasoby dostępne dla dodatków napisanych przy użyciu interfejsu API WebExtensions. Aby przetestować trzecią wersję manifestu w przeglądarce Firefox 101 beta, należy ustawić parametr „extensions.manifestV3.enabled” na wartość true i parametr „xpinstall.signatures.required” na wartość false na stronie about:config. Aby zainstalować dodatki, możesz użyć interfejsu about:debugging. Trzecia wersja manifestu ma zostać domyślnie włączona do końca roku.
Począwszy od wersji 57, Firefox całkowicie przestawił się na korzystanie z API WebExtensions do tworzenia dodatków i przestał wspierać technologię XUL. Przejście na WebExtensions umożliwiło ujednolicenie rozwoju dodatków z platformami Chrome, Opera, Safari i Edge, uprościło przenoszenie dodatków pomiędzy różnymi przeglądarkami internetowymi oraz umożliwiło pełne wykorzystanie trybu wieloprocesowego działanie (dodatki WebExtensions mogą być uruchamiane w oddzielnych procesach, odizolowanych od reszty przeglądarki). Aby ujednolicić rozwój dodatków z innymi przeglądarkami, Firefox zapewnia prawie pełną kompatybilność z drugą wersją manifestu Chrome.
Chrome pracuje obecnie nad przejściem do wersji 2023 manifestu, a obsługa wersji XNUMX zostanie zakończona w styczniu XNUMX r. Ponieważ trzecia wersja manifestu znalazła się pod ostrzałem i zepsuje wiele dodatków blokujących zawartość i zabezpieczających, Mozilla zdecydowała się odejść od praktyki zapewniania pełnej zgodności z manifestem w przeglądarce Firefox i wprowadzić pewne zmiany w inny sposób.
Główne niezadowolenie z trzeciej wersji manifestu wiąże się z tłumaczeniem na tryb tylko do odczytu interfejsu API webRequest, co umożliwiło podłączenie własnych handlerów, które mają pełny dostęp do żądań sieciowych i mogą na bieżąco modyfikować ruch. Ten interfejs API jest używany w uBlock Origin i wielu innych dodatkach do blokowania nieodpowiednich treści i zapewniania bezpieczeństwa. Zamiast webRequest API, trzecia wersja manifestu oferuje deklarativeNetRequest API o ograniczonych możliwościach, który zapewnia dostęp do wbudowanego silnika filtrującego, który samodzielnie przetwarza reguły blokujące, nie pozwala na stosowanie własnych algorytmów filtrujących i nie pozwalają na ustawienie skomplikowanych reguł, które nakładają się na siebie w zależności od warunków.
W implementacji trzeciej wersji manifestu zaproponowanej w Firefoksie dodano nowe deklaratywne API do filtrowania treści, ale w przeciwieństwie do Chrome nie przestały one wspierać starego trybu blokowania działania API webRequest. Inne funkcje nowej implementacji manifestu w przeglądarce Firefox obejmują:
- Manifest definiuje zastąpienie stron działających w tle opcją Service Workers, która działa jako procesy działające w tle (Workers Service Workers w tle). Aby zapewnić kompatybilność, Firefox zaimplementuje ten wymóg, ale dodatkowo zaoferuje nowy mechanizm Event Pages, który jest bardziej znany twórcom stron internetowych, nie wymaga całkowitej przeróbki dodatków i eliminuje ograniczenia związane z korzystaniem z Service Workerów. Strony zdarzeń umożliwią dostosowanie istniejących dodatków do stron tła do wymagań trzeciej wersji manifestu, przy jednoczesnym zachowaniu dostępu do wszystkich możliwości potrzebnych do pracy z DOM. W implementacji manifestu dostępnej do testowania w przeglądarce Firefox obsługiwane są obecnie tylko strony zdarzeń, a obsługa rozwiązania opartego na Service Workerach zostanie dodana w późniejszym terminie. Firma Apple poparła tę propozycję i wdrożyła strony zdarzeń w przeglądarce Safari Technology Preview 136.
- Nowy model szczegółowego żądania uprawnień - dodatek nie będzie mógł być aktywowany dla wszystkich stron jednocześnie (usunięto uprawnienie „all_urls”), ale będzie działał tylko w kontekście aktywnej karty, tj. użytkownik będzie musiał potwierdzić, że dodatek działa dla każdej witryny. W przeglądarce Firefox wszystkie prośby o dostęp do danych witryny będą traktowane jako opcjonalne, a ostateczna decyzja o przyznaniu dostępu zostanie podjęta przez użytkownika, który będzie mógł selektywnie decydować, który dodatek udzieli dostępu do jego danych w konkretnej witrynie.
- Zmiana w obsłudze żądań Cross-Origin - zgodnie z nowym manifestem, skrypty przetwarzające treść będą podlegały takim samym ograniczeniom uprawnień, jak w przypadku strony głównej, na której te skrypty są osadzone (np. jeśli strona nie ma dostępu do Location API, wówczas dodatki skryptowe również nie otrzymają tego dostępu). Ta zmiana została w pełni zaimplementowana w przeglądarce Firefox.
- API oparte na obietnicach. Firefox obsługuje już ten interfejs API i przeniesie go do przestrzeni nazw „chrome.*” dla trzeciej wersji manifestu.
- Zakaz wykonywania kodu pobranego z serwerów zewnętrznych (mówimy o sytuacjach, gdy dodatek ładuje i wykonuje kod zewnętrzny). Firefox korzysta już z zewnętrznego blokowania kodu, a programiści Mozilli dodali dodatkowe techniki śledzenia pobierania kodu oferowane w trzeciej wersji manifestu. W przypadku skryptów przetwarzających treść dostępna jest osobna polityka ograniczeń dostępu do treści (CSP, Content Security Policy).
Źródło: opennet.ru