Firma Google trzeciej wersji manifestu Chrome, wielu dodatków do blokowania niechcianych treści oraz zapewnienia bezpieczeństwa. Wsparcie dla nowego manifestu, który określa możliwości i zasoby udostępniane dodatkom, zostało dodane do eksperymentalnych wersji .
Nowy manifest został opracowany w ramach wzmocnienia bezpieczeństwa, prywatności i wydajności dodatków (głównym celem jest uproszczenie tworzenia bezpiecznych i wydajnych dodatków oraz utrudnienie tworzenia niebezpiecznych i wolnych dodatków).
Manifest znajduje się jeszcze w fazie wczesnego testowania alfa, nie jest ostateczny i został dodany, aby dać deweloperom możliwość eksperymentowania i dostosowywania swoich dodatków.
Aktywacja nowego manifestu przewidziana jest na przyszły rok. Czas zakończenia wsparcia dla drugiej wersji manifestu nie jest jeszcze określony.
Aby uprościć migrację dodatków do nowego manifestu, przygotowano , zawierającą zmiany, na które powinni zwrócić uwagę deweloperzy dodatków.
Przypomnijmy, że związanym z zaprzestaniem wsparcia dla blokującego trybu pracy API webRequest, które będzie ograniczone do trybu tylko do odczytu. Wyjątek zostanie zrobiony jedynie dla edycji Chrome dla przedsiębiorstw (Chrome for Enterprise), w których wsparcie dla API webRequest zostanie zachowane. Firma Mozilla zdecydowała się nie podążać za nowym manifestem i zachować w Firefoxie możliwość pełnego wykorzystania API webRequest.
Zamiast API webRequest do filtrowania treści w nowym manifestie zaproponowano deklaratywne API . Jeśli API webRequest pozwalało na podłączanie własnych handlerów, które miały pełny dostęp do zapytań sieciowych i mogły w czasie rzeczywistym modyfikować ruch, nowy API declarativeNetRequest oferuje dostęp do gotowego uniwersalnego wbudowanego silnika do filtrowania, który samodzielnie przetwarza zasady blokady, nie pozwalając na używanie własnych algorytmów filtrowania ani na definiowanie skomplikowanych zasad, które wzajemnie się wykluczają w zależności od warunków.
W nowym manifeście wprowadzono również inne zmiany, które wpływają na zgodność z dodatkami. Wśród nich są:
- Przejście na wykonywanie Service workers w formie procesów w tle, co wymusi na deweloperach zmianę kodu niektórych dodatków.
- Nowy model granularnego żądania 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 karty, tj. użytkownik będzie musiał potwierdzić działanie dodatku dla każdej strony.
- Zmiana w obsłudze zapytań cross-origin — zgodnie z nowym manifestem, te same ograniczenia uprawnień będą miały zastosowanie do skryptów przetwarzania treści, co dla głównej strony, na którą te skrypty są wdrażane (na przykład, jeśli strona nie ma dostępu do API określania lokalizacji, to skrypt dodatku również nie uzyska tego dostępu).
- Zakaz wykonywania kodu ładowanego z zewnętrznych serwerów (mowa o sytuacjach, kiedy dodatek ładuje i wykonuje zewnętrzny kod).
Źródło: opennet.ru
