Mozilla zacznie akceptować dodatki w oparciu o trzecią wersję manifestu Chrome

21 listopada katalog AMO (addons.mozilla.org) zacznie akceptować i podpisywać cyfrowo dodatki przy użyciu wersji 109 manifestu Chrome. Te dodatki można testować w nocnych kompilacjach Firefoksa. W stabilnych wersjach obsługa manifestu w wersji 17 zostanie włączona w przeglądarce Firefox 2023, co zaplanowano na 2023 stycznia XNUMX r. Wsparcie dla drugiej wersji manifestu zostanie utrzymane w dającej się przewidzieć przyszłości, jednak pod koniec XNUMX roku, po ocenie dynamiki przenoszenia dodatków do trzeciej wersji manifestu, istnieje możliwość wycofania wsparcia dla drugiej wersji manifestu zostanie rozważony.

Manifest Chrome definiuje możliwości i zasoby dostępne dla rozszerzeń napisanych przy użyciu interfejsu API WebExtensions. 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 2024 manifestu, a obsługa wersji XNUMX zostanie zakończona w styczniu XNUMX r. Głównym celem zmian wprowadzonych w nowej wersji jest ułatwienie tworzenia bezpiecznych i wydajnych dodatków oraz utrudnienie tworzenia niebezpiecznych i powolnych dodatków. 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 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śród funkcji implementacji nowego manifestu w przeglądarce Firefox:

  • Dodano nowy deklaratywny interfejs API do filtrowania treści, ale w przeciwieństwie do Chrome nie zaprzestano obsługi starego trybu blokowania interfejsu API webRequest.
  • 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ść w przyszłości, Firefox będzie obsługiwał Service Workers, ale obecnie zostały one zastąpione nowym mechanizmem stron zdarzeń, który jest bardziej znany twórcom stron internetowych, nie wymaga całkowitej przeróbki dodatków i eliminuje ograniczenia związane z korzystanie z Pracowników Serwisu. 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.
  • 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.

    Aby zarządzać uprawnieniami, do interfejsu dodano nowy przycisk „Ujednolicone rozszerzenia”, który można już przetestować w nocnych kompilacjach Firefoksa. Przycisk umożliwia bezpośrednią kontrolę witryn, do których dany dodatek ma dostęp — użytkownik może udzielić lub odebrać dostęp dodatku do dowolnej witryny. Zarządzanie uprawnieniami dotyczy tylko dodatków opartych na trzeciej wersji manifestu; w przypadku dodatków opartych na drugiej wersji manifestu nie jest wykonywana szczegółowa kontrola dostępu do witryn.

    Mozilla zacznie akceptować dodatki w oparciu o trzecią wersję manifestu Chrome
  • 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 ten interfejs API i w przypadku trzeciej wersji manifestu przeniesie go do przestrzeni nazw „chrome.*”.
  • Zakaz wykonywania kodu pobranego z serwerów zewnętrznych (mówimy o sytuacjach, gdy dodatek ładuje i wykonuje kod zewnętrzny). Firefox korzysta z zewnętrznego blokowania kodu, a twórcy 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

Dodaj komentarz