Google opublikowało plan zaprzestania obsługi drugiej wersji manifestu Chrome.

Firma Google przedstawiła harmonogram wycofania wersji XNUMX manifestu przeglądarki Chrome na rzecz wersji XNUMX, która była krytykowana za psucie się w wielu dodatkach blokujących zawartość i zapewniających bezpieczeństwo. W szczególności do drugiej wersji manifestu dołączony jest popularny bloker reklam uBlock Origin, którego nie można przenieść do trzeciej wersji manifestu ze względu na zaprzestanie obsługi trybu blokowania działania API webRequest.

Od 17 stycznia 2022 r. Chrome Web Store nie będzie już akceptować dodatków korzystających z drugiej wersji manifestu, ale twórcy dodatków dodanych wcześniej będą nadal mogli publikować aktualizacje. W styczniu 2023 r. Chrome przestanie obsługiwać drugą wersję manifestu, a wszystkie powiązane z nią dodatki przestaną działać. Jednocześnie zabronione będzie publikowanie aktualizacji takich dodatków w sklepie Chrome Web Store.

Przypomnijmy, że w trzeciej wersji manifestu, który określa możliwości i zasoby udostępniane dodatkom, w ramach inicjatywy wzmacniającej bezpieczeństwo i prywatność, zamiast API webRequest, o ograniczonych możliwościach API deklarativeNetRequest, jest zaproponowane. O ile webRequest API pozwala na podłączenie własnych handlerów, które mają pełny dostęp do żądań sieciowych i są w stanie na bieżąco modyfikować ruch, o tyle deklarativeNetRequest API zapewnia dostęp jedynie do gotowego silnika filtrującego wbudowanego w przeglądarkę, który samodzielnie przetwarza blokowanie reguł i nie pozwala na stosowanie własnych algorytmów filtrujących oraz nie pozwala na ustalanie skomplikowanych reguł, które nakładają się na siebie w zależności od warunków.

Jak podaje Google, w dalszym ciągu pracuje nad wdrożeniem w deklarativeNetRequest możliwości wymaganych w dodatkach korzystających z webRequest i zamierza doprowadzić nowe API do postaci w pełni odpowiadającej potrzebom twórców istniejących dodatków. Na przykład Google uwzględnił już życzenia społeczności i dodał obsługę deklarativeNetRequest API w zakresie korzystania z wielu statycznych zestawów reguł, filtrowania za pomocą wyrażeń regularnych, modyfikowania nagłówków HTTP, dynamicznego zmieniania i dodawania reguł, usuwania i zastępowania parametrów żądań, filtrowania z wiązaniem zakładek i tworzeniem określonych sesji zestawu reguł. W nadchodzących miesiącach planowane jest dodatkowo wdrożenie obsługi dynamicznie konfigurowalnych skryptów przetwarzania treści oraz możliwości przechowywania danych w pamięci RAM.

Źródło: opennet.ru

Dodaj komentarz