Google은 Chromium Adblock 차단 문제에 대응합니다.

XNUMX월에 우리는 webRequest API를 더 이상 사용하지 않을 Google의 계획 훨씬 덜 강력하고 개발자가 광고를 필터링하는 데 사용할 수 있는 규칙의 수를 제한하는 새로운 declarativeNetRequest API로 대체합니다.

당시 최고의 adbock 앱 중 하나인 uBlock Origin의 개발자는 bugs.chromium.org에서 다음과 같이 말했습니다.

이 (상당히 제한된) declarativeNetRequest API가 콘텐츠 차단기가 자신의 임무를 수행할 수 있는 유일한 방법으로 끝나는 경우 이는 본질적으로 내가 수년간 유지해 온 두 가지 콘텐츠 차단기인 uBlock Origin("uBO")과 uMatrix가 더 이상 존재할 수 없다는 것을 의미합니다.

이제 Chromium에서 작업하는 Google 엔지니어가 응답했습니다. 우려에 부응하고 일부 양보에 동의했지만 이것이 충분히 진행되는지는 확실하지 않습니다.

Google은 webRequest AP가 남용이 증가하는 소스라고 말하면서 제거하기로 결정했지만 다음과 같은 방식으로 declarativeNetRequest API를 개선하기로 동의했습니다.

• 동적 규칙 지원: 우리는 이것이 정교한 콘텐츠 차단 확장을 만드는 데 중요하며 런타임에 declarativeNetRequest API에 추가하거나 제거할 수 있는 선언적 규칙에 대한 지원을 추가할 것이라는 데 동의합니다.
• 증가된 규칙 세트 크기: 초안 30K 값에서 규칙 제한을 높입니다. 그러나 사용자의 성능을 보장하기 위해서는 여전히 상한선이 필요합니다. 차단 목록은 새 규칙이 추가되지만 더 이상 사용되지 않는 규칙은 제거되는 경우가 거의 없는 "푸시 전용"인 경향이 있습니다(외부 조사 EasyList 차단 규칙의 90%가 일반적인 차단 시나리오에서 이점을 제공하지 않는 것으로 나타났습니다. 이 목록을 계속 무한대로 늘리는 것은 문제가 됩니다.
• 추가 조치 및 조건: 리소스 크기와 같은 더 많은 조건을 기반으로 한 일치에 대한 지원을 추가할 계획이며 쿠키 제거와 같이 요청을 차단하는 대신 요청의 일부를 수정하는 작업을 제공할 것입니다. 또한 최상위 도메인을 기반으로 한 일치와 같이 추가할 수 있는 다른 조건 및 작업을 조사하고 있습니다. (추가 참고 사항: CSP 수정에 대한 지원 추가를 조사하는 동안 JavaScript를 비활성화하기 위해 CSP 헤더를 추가하는 것이 사용 사례로 자주 언급되었습니다. 이는 이미 다음을 통해 가능합니다. 콘텐츠 설정 API. 부족하다면 그 이유를 알려주세요.)

Google은 개발자와 계속 협력할 것이며 교체가 준비되고 성숙되기 전에 webRequest API를 제거하지 않을 것이라고 말했습니다.

다시 한 번 Chrome에서 확장 프로그램을 지원하기 위해 최선을 다하고 있습니다. 우리는 계속해서 개발자들과 협력할 것입니다. Manifest V3가 준비될 때까지 출시하지 않을 것이며, 피드백과 문제를 계속 해결할 수 있는 마이그레이션 기간이 있을 것입니다. 플랫폼에 대한 확신이 생길 때까지 Manifest V2에 대한 지원을 제거하지 않을 것입니다.

많은 사람들이 여전히 회의적이지만 Google의 실제 목표는 수십억 명의 사용자를 추적하고 광고를 게재할 수 있도록 사용자 경험을 보다 엄격하게 제어하는 ​​것입니다.

독자들은 Google이 Chromium을 통해 전 세계 웹 렌더링 엔진에 대한 통제력을 높여 광고 비즈니스를 더욱 강화할 것이라고 생각합니까, 아니면 정직하게 유지하기에 충분한 브라우저 경쟁이 있습니까? 아래에 알려주십시오.

통하다 등록