Programiści Google odpowiedzialni za przeglądarkę internetową „Google Chrome” ogłosili włączenie w Chrome 88 (spodziewany start 19 stycznia 2021 r.) trzeciej edycji manifestu, co spowodowało wiele konfliktów wśród twórców rozszerzeń przeglądarek, z powodu naruszenia pracy wielu dodatków blokujących nieodpowiednie treści i zabezpieczenia.
Należy zauważyć, że kompatybilność z wtyczkami używającymi drugiej wersji z manifestu pozostanie na jakiś czas. Koniec wsparcia dla Manifest V2 nie został jeszcze określony, ale okres migracji do nowego manifestu potrwa co najmniej rok.
Jako przypomnienie, Manifest Chrome definiuje możliwości i zasoby dostarczane przez wtyczki.
Nowy manifest jest częścią inicjatywy mającej na celu poprawę bezpieczeństwa, prywatność i wydajność wtyczek. Głównym celem zmian jest ułatwienie tworzenia wydajnych i bezpiecznych wtyczek oraz utrudnienie tworzenia wolnych i niebezpiecznych wtyczek.
Wraz z wprowadzeniem Manifest V3 nie pozwolimy na kod zdalnie hostowany. Mechanizm ten jest wykorzystywany jako wektor ataku przez złe podmioty, aby ominąć narzędzia Google do wykrywania złośliwego oprogramowania i stanowi poważne zagrożenie dla prywatności i bezpieczeństwa użytkowników.
Główne niezadowolenie z nowym manifestem wiąże się z zakończeniem wsparcia dla trybu blokady operacji API webRequest, który będzie ograniczony do trybu tylko do odczytu.
Wyjątek będzie dotyczył tylko wersji Chrome for Enterprise, który będzie nadal obsługiwany przez interfejs API webRequest. Mozilla zdecydowała się nie podążać za nowym manifestem i będzie w pełni korzystać z interfejsu API webRequest. Zamiast tego interfejs API webRequest do filtrowania treści w nowym manifeście zaproponował deklaratywny interfejs API declarativeNetRequest.
Nowy interfejs API declarativeNetRequest zapewnia dostęp do gotowego do użycia, uniwersalnego wbudowanego silnika filtrującego, który niezależnie przetwarza reguły blokowania, nie pozwala na użycie niestandardowych algorytmów filtrowania i nie pozwala na ustawianie złożonych i nakładających się reguł w zależności od na warunkach.
Jako powód przejścia na declarativeNetRequest API, Uwagi dotyczące prywatności są odnotowywane: Dzięki nowemu interfejsowi API wtyczki utracą nieograniczony dostęp do wszystkich strumieni danych, które mogą zawierać poufne informacje o użytkowniku.
Google próbował złagodzić niektóre z przedstawionych problemów Podczas dyskusji z twórcami wtyczek, na których wpłynie declarativeNetRequest API (np. UBlock Origin, którego autor uważa, że declarativeNetRequest funkcjonalność jest niewystarczająca do poprawnego działania wtyczki), przestanie on działać.
Zgodnie z życzeniem twórców wtyczek, se dodano obsługę używania declarativeNetRequest dla różnych statycznych zestawów reguł filtruj według wyrażeń regularnych, modyfikuj nagłówki HTTP, dynamicznie zmieniaj i dodawaj reguły, usuwaj i zamieniaj parametry żądania.
Nowy manifest wprowadza również następujące zmiany, które wpływają na zgodność wtyczek:
- Przejście na uruchamianie Service Workerów w postaci procesów w tle, co będzie wymagało od programistów zmiany kodu niektórych dodatków.
- Nowy szczegółowy model żądania uprawnień: wtyczka nie będzie mogła być aktywowana dla wszystkich stron w tym samym czasie (uprawnienie „all_urls” zostało usunięte), ale będzie działać tylko w kontekście aktywnej karty, czyli użytkownik będzie musiał potwierdzić działanie wtyczki dla każdej witryny.
- Zmiany w przetwarzaniu żądań między źródłami: zgodnie z nowym manifestem skrypty przetwarzające treść będą podlegać takim samym ograniczeniom uprawnień, jak w przypadku strony głównej, na której są osadzone te skrypty (na przykład, jeśli strona nie ma dostępu do interfejsu API lokalizacji , to wtyczki skryptów również nie będą miały tego dostępu).
- Uniemożliwia wykonanie kodu pobranego z serwerów zewnętrznych (gdy wtyczka ładuje i wykonuje kod zewnętrzny).
W końcu jeśli chcesz dowiedzieć się więcej na ten temat notatki, możesz odwołać się do oryginalnego postu W poniższym linku.