Google은 광고 차단기가 사용하는 webRequest API의 제한을 정당화합니다.

Chrome 브라우저 개발자 시도했다 신이 옳다고 하다 수신된 콘텐츠를 즉시 변경할 수 있고 광고 차단용 애드온에서 적극적으로 사용되는 webRequest API 작동 차단 모드에 대한 지원 중단
맬웨어, 피싱, 사용자 활동 감시, 자녀 보호 및 개인정보 보호.

Google의 동기:

• API 차단 모드 웹요청 높은 자원 소모로 이어집니다.
  이 API를 사용할 때 브라우저는 먼저 네트워크 요청에 포함된 모든 데이터를 추가 기능에 보내고 추가 기능은 이를 분석한 후 브라우저에서 추가 처리를 위해 수정된 버전을 반환하거나 차단 명령을 발행합니다. 이 경우 주요 지연은 추가 기능에 의한 트래픽 처리 단계가 아니라 추가 기능 실행을 조정하는 데 드는 오버헤드 비용으로 인해 발생합니다. 특히, 이러한 조작에는 보완을 위한 별도의 프로세스 실행과 이 프로세스 및 데이터 직렬화 메커니즘과 상호 작용하기 위한 IPC의 사용이 필요합니다.

• 추가 기능은 낮은 수준에서 모든 트래픽을 완전히 제어하므로 남용 및 개인 정보 침해에 대한 광범위한 기회가 열립니다. Google 통계에 ​​따르면, 탐지된 모든 악성 애드온 중 42%가 webRequest API를 사용했습니다. 매달 평균 1800개의 악성 애드온을 배치하려는 시도가 크롬 웹 스토어 카탈로그에서 차단되는 것으로 나타났습니다. 안타깝게도 검토를 통해 모든 악성 애드온을 예외 없이 잡아낼 수는 없으므로 보호 강화를 위해 API 수준에서 애드온을 제한하기로 결정했습니다. 주요 아이디어는 모든 트래픽이 아닌 의도한 기능을 구현하는 데 필요한 데이터에만 액세스할 수 있는 추가 기능을 제공하는 것입니다. 특히 콘텐츠를 차단하기 위해 추가 기능에 모든 기밀 사용자 데이터에 대한 전체 액세스 권한을 부여할 필요는 없습니다.
• 제안된 대체 선언적 API 선언적NetRequest 고성능 콘텐츠 필터링의 모든 작업을 처리하며 필터링 규칙을 로드하기 위한 추가 기능만 필요합니다. 추가 기능은 트래픽을 방해할 수 없으며 사용자의 개인 데이터는 침해할 수 없습니다.
• Google은 declarativeNetRequest API의 기능 부족에 대한 많은 의견을 고려하여 필터링 규칙 수 제한을 처음에 제안된 확장 프로그램당 30개에서 전역 최대 150개로 확장했으며 동적으로 다음을 수행하는 기능도 추가했습니다. 규칙을 변경 및 추가하고, HTTP 헤더(Referer, Cookie, Set-Cookie) 및 요청 매개변수를 제거 및 교체합니다.
• 기업의 경우 webRequest API 작동의 차단 모드를 사용할 수 있습니다. 추가 기능 사용 정책은 인프라의 기능을 이해하고 위험을 인식하는 관리자가 결정하기 때문입니다. 예를 들어, 지정된 API는 기업에서 직원 트래픽 흐름을 기록하고 내부 시스템과 통합하는 데 사용될 수 있습니다.
• Google의 목표는 광고 차단 추가 기능을 약화하거나 억제하는 것이 아니라 더 안전하고 강력한 광고 차단기를 만들 수 있도록 하는 것입니다.
• 새로운 declarativeNetRequest와 함께 webRequest API의 작동 차단 모드를 떠나는 것을 꺼리는 것은 추가 기능의 액세스를 기밀 데이터로 제한하려는 욕구로 설명됩니다. webRequest API를 그대로 두면 대부분의 애드온은 더 안전한 declarativeNetRequest를 사용하지 않을 것입니다. 왜냐하면 보안과 기능 중 하나를 선택할 때 대부분의 개발자는 일반적으로 기능을 선택하기 때문입니다.

반대 개발자 추가:

• 애드온 개발자가 수행 검사들 광고 차단 애드온의 성능에 미치는 전반적인 영향은 미미합니다(테스트 중에 다양한 애드온의 성능을 비교했지만 차단 모드에서 핸들러 실행을 조정하는 추가 프로세스의 오버헤드는 고려하지 않았습니다). webRequest API);
• 애드온에서 활발하게 사용되는 API에 대한 지원을 완전히 중단하는 것은 현실적이지 않습니다. 이를 제거하는 대신 별도의 권한을 추가하고 추가 기능에서 해당 사용의 적절성을 엄격하게 제어할 수 있습니다. 이렇게 하면 많은 인기 있는 추가 기능 작성자가 제품을 완전히 재작업하지 않고 기능을 자르는 일을 피할 수 있습니다.
• 오버헤드 비용을 줄이기 위해 API를 삭제할 수는 없지만 Firefox의 webRequest 구현과 유사한 Promise 메커니즘을 기반으로 다시 만듭니다.
• 제안된 대안인 declarativeNetRequest는 네트워크 요청에 대한 완전한 제어를 제공하지 않고, 사용자 정의 필터링 알고리즘의 사용을 허용하지 않으며, 광고 차단 및 보안/개인 정보 보호에 대한 추가 기능 개발자의 모든 요구 사항을 충족하지 않습니다. 조건에 따라 서로 겹치는 복잡한 규칙의 사용;
• declarativeNetRequest API의 현재 상태에서는 uBlock Origin 및 uMatrix 추가 기능의 기존 기능을 변경 없이 다시 만드는 것이 불가능하며 Chrome용 NoScript 포트의 추가 개발도 무의미해집니다.
• webRequest API의 읽기 전용, 비차단 모드는 그대로 유지되고 악성 추가 기능이 모든 트래픽을 제어할 수 있도록 허용하지만 트래픽을 방해할 수 있는 기능은 제공하지 않기 때문에 개인 정보 보호에 대한 우려는 매우 큽니다. 플라이(콘텐츠 변경, 광고 배치, 마이너 실행 및 입력 양식의 콘텐츠 분석은 페이지 로딩이 완료된 후 사용할 수 있습니다);
• 브라우저 개발자 용감한, Opera и 비발디는 Chromium 엔진을 기반으로 구축되었으며 자사 제품에서 webRequest 차단 모드에 대한 지원을 남길 계획입니다.

출처 : opennet.ru