Simeon Vincent, rzecznik programistów rozszerzeń Chrome, kierownik zespołu Chrome, Obecne stanowisko Google w sprawie trzeciej wersji manifestu Chrome, wiele dodatków blokujących nieodpowiednie treści i zapewniających bezpieczeństwo. Firma nie zamierza rezygnować z pierwotnego planu zaprzestania wspierania blokowego trybu działania API webRequest, które pozwala na zmianę akceptowanych treści w locie. Wyjątek będzie dotyczył tylko korporacyjnej wersji Chrome (), co zapewni nienaruszoną obsługę interfejsu API webRequest.
Dla zwykłych użytkowników Chrome API będzie ograniczony do trybu tylko do odczytu. Zaproponowano deklaratywny interfejs API, który ma zastąpić interfejs API webRequest do filtrowania treści , który obejmuje tylko ograniczoną część funkcji używanych w nowoczesnych blokerach reklam. W rzeczywistości zamiast własnych programów obsługi, które mają pełny dostęp do żądań sieciowych, oferowany jest gotowy uniwersalny wbudowany silnik filtrujący, który samodzielnie przetwarza reguły blokowania. Na przykład API declarativeNetRequest nie pozwala na użycie własnych algorytmów filtrowania i nie pozwala na tworzenie złożonych reguł, które nakładają się na siebie w zależności od warunków.
Twórcy dodatków blokujących reklamy wspólnie przygotowali , w którym wymieniono wady interfejsu API deklarativeNetRequest. Google zgodził się z wieloma komentarzami i dodał interfejs API deklarativeNetRequest. W szczególności dodano obsługę dynamicznej zmiany i dodawania reguł oraz możliwe było usuwanie nagłówków HTTP, ale tylko tych znajdujących się na białej liście (Referer, Cookie, Set-Cookie). W planach jest wdrożenie obsługi dodawania i zastępowania nagłówków HTTP (np. zastępowania dyrektyw Set-Cookie i CSP) oraz możliwości usuwania i zastępowania parametrów żądania.
Szkicowa wersja trzeciej wersji manifestu, która definiuje listę funkcji i zasobów udostępnianych przez dodatki do Chrome, ma zostać wykorzystana do testowania w eksperymentalnych kompilacjach Chrome Canary w nadchodzących miesiącach.
Jednocześnie motywacja zakazu wprowadzania zmian w akceptowanych treściach poprzez API webRequest pozostaje nie do końca jasna. Twierdzenia, że tryb blokowania interfejsu API webRequest ma negatywny wpływ na wydajność, ponieważ przeglądarka czeka na zakończenie obsługi uzupełniania przed wyrenderowaniem strony, nie wytrzymuje kontroli. Wcześniej prowadzone Wydajność dodatków blokujących reklamy pokazała, że wprowadzane przez nie opóźnienia są znikome. Średnio użycie blokera spowalnia wykonanie żądania tylko o ułamek milisekundy, co na tle ogólnym jest pomijalne.
Drugi argument, związany z chęcią ochrony użytkowników przed niekontrolowanym dostępem do treści dodatkowych, również nie wydaje się przekonujący, gdyż zamiast usuwać ugruntowaną i powszechną funkcjonalność legalnych dodatków, można by dodać nowy rodzaj pozwolenie i dać użytkownikowi ostateczny wybór, zainstaluj dodatek, który ma pełny dostęp do żądań sieciowych lub nie. Ponadto Google pozostawił wsparcie dla korzystania z webRequest API w trybie tylko do odczytu, co pozwala na pełne monitorowanie ruchu, ale bez ingerencji w niego na niskim poziomie.
Dodatki mogą zmieniać zawartość pobranych stron internetowych za pośrednictwem innych interfejsów API (na przykład złośliwe dodatki mogą nadal wyświetlać reklamy, uruchamiać koparki i analizować zawartość formularzy wejściowych).
Raymond Hill, autor systemów blokowania niechcianych treści uBlock Origin i uMatrix, jest wystarczająco twardy odpowiedź przedstawiciela Google i zasugerowała demagogię i zakulisowe gry, w których Google pod pozorem dobrej okazji stara się realizować swoje interesy biznesowe w dziedzinie reklamy internetowej, przejąć kontrolę nad swoimi mechanizmami filtrowania i usprawiedliwić te działania w oczach opinii publicznej.
Nie otrzymał żadnych przekonujących argumentów przemawiających za koniecznością zatrzymania API, które jest szeroko rozpowszechnione i pożądane wśród twórców dodatków. Zdaniem Raymonda spadek wydajności nie jest argumentem, ponieważ strony ładują się wolno z powodu ich rozdęcia, a nie z powodu użycia trybu blokowania webRequest w poprawnie zaimplementowanych dodatkach. Gdyby Google naprawdę dbał o wydajność, przeprojektowałby webRequest w oparciu o , analogicznie do webRequest w Firefoksie.
Według Raymonda strategia Google polega na znalezieniu właściwej równowagi między poszerzaniem bazy użytkowników Chrome a szkodami dla biznesu powodowanymi przez stosowanie blokerów treści. Na pierwszym etapie ekspansji Chrome'a Google musiał pogodzić się z blokowaniem reklam jako jednym z najpopularniejszych dodatków wśród użytkowników. Ale po tym, jak Chrome zyskał dominację, firma próbowała przechylić szalę na swoją korzyść i przejąć kontrolę nad blokowaniem poprzez promowanie osadzić nieodpowiednie blokowanie reklam w Chrome. WebRequest API pokonuje ten cel, ponieważ kontrola nad blokowaniem treści jest teraz w rękach zewnętrznych programistów blokujących reklamy.
Źródło: opennet.ru