Google uzasadnia ograniczenie interfejsu API webRequest używanego przez programy blokujące reklamy

Twórcy przeglądarki Chrome wypróbowany uzasadniać zaprzestanie obsługi trybu blokowania działania webRequest API, który umożliwia zmianę odbieranych treści na bieżąco i jest aktywnie wykorzystywany w dodatkach do blokowania reklam,
ochrona przed złośliwym oprogramowaniem, phishingiem, szpiegowaniem aktywności użytkowników, kontrolą rodzicielską i prywatnością.

Motywy Google:

• Tryb blokowania API żądanie internetowe prowadzi do dużego zużycia zasobów.
  Podczas korzystania z tego API przeglądarka najpierw wysyła do dodatku wszystkie dane zawarte w żądaniu sieciowym, dodatek je analizuje i zwraca zmodyfikowaną wersję do dalszego przetwarzania w przeglądarce lub wydaje instrukcje blokujące. W tym przypadku główne opóźnienia powstają nie na etapie przetwarzania ruchu przez dodatek, ale w wyniku ogólnych kosztów koordynacji wykonania dodatku. W szczególności takie manipulacje wymagają uruchomienia osobnego procesu w celu uzupełnienia, a także wykorzystania IPC do interakcji z tym procesem i mechanizmami serializacji danych;

• Dodatek całkowicie kontroluje cały ruch na niskim poziomie, co otwiera ogromne możliwości nadużyć i naruszeń prywatności. Według statystyk Google, 42% wszystkich wykrytych szkodliwych dodatków korzystało z interfejsu API webRequest. Należy zauważyć, że co miesiąc próby umieszczenia średnio 1800 szkodliwych dodatków są blokowane w katalogu Chrome Web Store. Niestety przeglądanie nie pozwala nam wyłapać wszystkich bez wyjątku szkodliwych dodatków, dlatego w celu zwiększenia ochrony zdecydowano się ograniczyć dodatki na poziomie API. Główną ideą jest zapewnienie dodatkom dostępu nie do całego ruchu, a jedynie do danych, które są niezbędne do realizacji zamierzonej funkcjonalności. W szczególności do zablokowania treści nie jest konieczne nadawanie dodatkowi pełnego dostępu do wszystkich poufnych danych użytkownika;
• Proponowany zastępczy deklaratywny interfejs API declarativeNetRequest przejmuje całą pracę związaną z wydajnym filtrowaniem treści i wymaga jedynie dodatków do ładowania reguł filtrowania. Dodatek nie może zakłócać ruchu, a prywatne dane użytkownika pozostają nienaruszalne;
• Google uwzględnił wiele uwag dotyczących braku funkcjonalności deklarativeNetRequest API i rozszerzył limit liczby reguł filtrowania z początkowo proponowanych 30 tys. na rozszerzenie do globalnego maksimum 150 tys., a także dodał możliwość dynamicznego zmieniać i dodawać reguły, usuwać i zastępować nagłówki HTTP (Referer, Cookie, Set-Cookie) oraz parametry żądań;
• Dla przedsiębiorstw możliwe jest skorzystanie z trybu blokowania działania webRequest API, gdyż politykę korzystania z dodatków ustala administrator, który rozumie cechy infrastruktury i jest świadomy zagrożeń. Przykładowo określone API można wykorzystać w przedsiębiorstwach do rejestrowania przepływów ruchu pracowniczego i integracji z systemami wewnętrznymi;
• Celem Google nie jest osłabianie lub eliminowanie dodatków blokujących reklamy, ale umożliwienie tworzenia bezpieczniejszych i skuteczniejszych programów blokujących reklamy;
• Niechęć do wychodzenia z blokowania trybu działania webRequest API wraz z nowym deklarativeNetRequest tłumaczona jest chęcią ograniczenia dostępu dodatków do poufnych danych. Jeśli pozostawisz API webRequest bez zmian, większość dodatków nie będzie używać bezpieczniejszego deklarativeNetRequest, ponieważ przy wyborze pomiędzy bezpieczeństwem a funkcjonalnością większość programistów zazwyczaj wybiera funkcjonalność.

zastrzeżenia programiści wzbogacenie:

• Prowadzone przez twórców dodatków testy wykazują nieistotny ogólny wpływ na wydajność dodatków blokujących reklamy (podczas testów porównywano wydajność różnych dodatków, ale bez uwzględnienia narzutu dodatkowego procesu koordynującego wykonywanie procedur obsługi w trybie blokowania API webRequest);
• Całkowite zaprzestanie obsługi interfejsu API aktywnie używanego w dodatkach nie jest praktyczne. Zamiast go usuwać, możesz dodać osobne zezwolenie i ściśle kontrolować zasadność jego użycia w dodatkach, co oszczędziłoby autorom wielu popularnych dodatków całkowitego przerobienia swoich produktów i uniknięcia obcinania funkcjonalności;
• Aby zmniejszyć koszty ogólne, nie można usunąć API, ale stworzyć je na nowo w oparciu o mechanizm Promise, podobnie jak w przypadku implementacji webRequest w przeglądarce Firefox;
• Proponowana alternatywa, deklarativeNetRequest, nie pokrywa wszystkich potrzeb twórców dodatków w zakresie blokowania reklam oraz bezpieczeństwa/prywatności, ponieważ nie zapewnia pełnej kontroli nad żądaniami sieciowymi, nie pozwala na użycie niestandardowych algorytmów filtrowania i nie pozwala stosowanie skomplikowanych zasad, które nakładają się na siebie w zależności od warunków;
• Przy obecnym stanie API deklarativeNetRequest nie ma możliwości odtworzenia dotychczasowej funkcjonalności dodatków uBlock Origin i uMatrix w niezmienionej formie, a ponadto dalszy rozwój portu NoScript dla Chrome staje się bezcelowy;
• Obawy o prywatność są daleko idące, ponieważ pozostawiono tryb tylko do odczytu, nieblokujący interfejsu API webRequest, który nadal umożliwia złośliwym dodatkom kontrolowanie całego ruchu, ale nie zapewnia możliwości ingerencji w niego na stronie latać (zmieniaj treść, umieszczaj swoje reklamy, uruchamiaj górniki i analizuj zawartość formularzy wejściowych, z których możesz skorzystać po zakończeniu ładowania strony);
• Twórcy przeglądarek Odważny, Opera и Vivaldi, zbudowane na silniku Chromium, zamierzają pozostawić w swoich produktach obsługę trybu blokowania webRequest.

Źródło: opennet.ru