곧 출시될 Google Chrome 확장 프로그램용 Manifest V3는 Chrome에서 광고 차단기가 작동하는 방식을 변경합니다. 이것이 광고 차단기와 Google이 앞으로 나아가는 올바른 길인가요?
구글 크롬 현재 시장에서 가장 인기 있는 크로스 플랫폼 웹 브라우저입니다. 전 세계 브라우저 사용 점유율의 62.7%를 차지 2019년 5월까지 Apple의 Safari가 15.89%로 2위를 차지했고 Mozilla의 Firefox는 5.07%를 차지했습니다. 가장 큰 비중을 차지하기 때문에 Google Chrome이 플랫폼에 대해 수행하는 가장 작은 변경 사항도 결국 전 세계 수백만 명의 사용자에게 영향을 미치게 됩니다. 그래서 Google이 Google Chrome 확장 프로그램용 Manifest V3 형식의 다음 확장 프로그램 매니페스트 버전을 발표했을 때 우리는 특히 Google이 Chrome 내에 콘텐츠 차단기 API를 구축하고 있다는 사실이 밝혀졌을 때 큰 변화가 있었습니다. 그 자체.
매니페스트 V3란 무엇입니까?
활동적인 Chrome 사용자라면 의심할 여지 없이 몇 가지 확장 프로그램을 사용하게 될 것입니다. 확장 프로그램은 다음을 사용하여 탐색 환경을 사용자 정의하는 작은 소프트웨어 프로그램입니다. 브라우저가 제공하는 API를 통해 사용자는 개인의 필요와 선호도에 맞게 기능과 동작을 조정할 수 있습니다. 이러한 확장은 주로 다음을 통해 배포됩니다. Chrome 웹 스토어, 여기에는 180,000개 이상의 확장 프로그램이 있습니다.
부터 작년 말, Google은 "획기적인 변경 사항"으로 분류될 수 있는 Chrome 확장 프로그램 플랫폼에 대한 제안된 변경 사항 집합인 "Manifest V3"를 작업해 왔습니다. 다음과 같이 Manifest V3에 대한 공개 토론 문서 상태에 따르면 확장 매니페스트 버전은 특정 기능을 특정 확장 클래스로 제한하는 메커니즘입니다. 이러한 제한은 최소 버전 또는 최대 버전의 형태일 수 있습니다. 최소 버전으로 제한하면 최신 API 또는 기능을 최신 확장에서만 사용할 수 있습니다. 최대 매니페스트 버전으로 제한하면 이전 API 또는 기능을 점진적으로 사용할 수 있습니다. 더 이상 사용되지 않습니다.
간단히 말해서, 새로운 매니페스트 버전을 사용하면 Chrome에서 API와 기능을 이 새로운 매니페스트 버전으로 제한할 수 있습니다. 사용자에게 부정적인 영향을 미치기 때문에 확장 개발자가 특정 이전 API에서 마이그레이션하도록 강제하기 위해 경험. Manifest V3에서 확장을 구현하면 이론적으로 보안, 개인 정보 보호 및 성능 측면에서 더 강력한 보장이 제공되어야 합니다.
Manifest V3에는 다양한 변경 사항이 설명되어 있지만 가장 논란이 많은 변경 사항은 기존 V3에 존재하는 차단 기능을 제한하려는 Google의 결정과 관련이 있습니다. chrome.web요청 API를 사용하고(차단 대신 관찰에 API 초점을 맞춘 다음) 새로운 차단 기능을 통해 이러한 차단 기능을 제시합니다. chrome.declarativeNetRequest API. 이 특별한 변화는 커뮤니티에 불을 지폈다 결국 유명한 광고 차단 확장 프로그램의 광고 차단 메커니즘을 표적으로 삼게 되므로, 유블록 오리진, 천만 명 이상의 사용자에게 직접적인 영향을 미칩니다.
이 문제를 다루기 전에, 웹요청 API는 다음과 비교됩니다. 선언적NetRequest API.
웹 요청 API 및 선언적 네트 요청 API
본
Web Request의 공식 설명은 API를 다음과 같이 설명합니다.
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
웹 요청을 통해 Chrome은 다음을 보냅니다. 모두 이를 수신하는 확장 프로그램에 대한 네트워크 요청의 데이터입니다. 그런 다음 확장 프로그램은 요청을 평가하고 Chrome에 요청 처리 방법(허용, 차단 또는 일부 수정하여 전송)을 지시할 수 있습니다.
확장 프로그램이 Web Request API를 사용할 때 무슨 일이 일어나는지 이해하려면 일련의 이벤트를 따르세요. 웹 요청 확장 프로그램이 설치된 사용자가 링크를 클릭하면 Chrome은 요청이 서버에 도달하기 전에 데이터 요청이 이루어졌다는 사실을 확장 프로그램에 알립니다. 확장 프로그램은 이 단계에서 요청을 수정하도록 선택할 수 있습니다. 그러면 서버가 응답하지만 응답은 다시 확장 프로그램을 통과하며 확장 프로그램은 응답을 수정해야 하는지 여부를 지정할 수 있습니다. 그런 다음 Chrome은 마침내 페이지를 렌더링하고 사용자는 클릭 작업의 결과를 볼 수 있습니다.
Chrome이 넘겨지면서 네트워크 요청의 모든 데이터, Web Request API를 사용하는 확장 프로그램은 사용자가 웹에서 수행하는 모든 작업을 읽고 수정할 수 있는 액세스 권한을 갖습니다. 따라서 uBlock Origin과 같은 콘텐츠 차단기는 이 API의 잠재력을 현명하게 활용하지만 Google은 다음과 같이 주장합니다. 악의적인 의도를 가진 다른 확장 프로그램은 이를 악용하여 사용자의 개인 정보에 접근했습니다. 정보. Google에 따르면 2018년 1월 이후 악성 확장 프로그램의 42%가 Web Request API를 사용했습니다. Google은 또한 차단 버전인 API와 관련된 "상당한 성능 비용"이 있다고 주장합니다. 그 중 '게으른' 프로세스와 근본적으로 호환되지 않는 지속적이고 장기간 실행되는 프로세스가 필요합니다. 프로세스.
Manifest V3를 통해 Google은 이 API를 차단 형식으로 제한할 것을 제안합니다. 대안으로 Google은 Declarative Net Request API를 제공하고 있습니다.
미래
Declarative Net Request의 공식 설명은 API를 다음과 같이 설명합니다.
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
선언적 넷 요청을 사용하면 Chrome은 요청에 대한 모든 정보를 수신 확장 프로그램에 보낼 필요가 없습니다. 대신 확장 프로그램은 특정 유형의 요청이 표시될 경우 수행할 작업을 브라우저에 미리 알려주는 규칙을 Chrome에 등록합니다.
확장은 사전에 규칙을 지정합니다. 그런 다음 브라우저(확장 프로그램이 아님)에 의해 사용자의 요청이 이 규칙과 일치되고 해당 작업도 브라우저에 의해 수행되며 이후에 페이지가 렌더링됩니다. 구글은 이를 통해 결과를 결정하는 알고리즘을 제어할 수 있고 비효율적인 규칙을 예방하거나 비활성화할 수 있기 때문에 효율성을 보장할 수 있다고 언급합니다. 또한 네트워크 요청의 세부 정보가 확장 프로그램에 노출되지 않으므로 최종 사용자에게 더 나은 개인 정보 보호를 보장합니다. 지속적이고 장기간 실행되는 프로세스가 더 이상 필요하지 않기 때문에(규칙이 사전에 등록되었기 때문에) Google은 다음과 같이 주장합니다. 이 접근 방식은 또한 리소스가 제한된 환경에서 확장을 훨씬 더 실행 가능하게 만드는 성능 향상을 제공합니다. 플랫폼.
선언적 넷 요청은 Manifest V2(현재)와 Manifest V3 모두에서 사용할 수 있지만 이는 Google이 Manifest V3에서 네트워크 요청을 수정하도록 허용하는 기본 방법이 될 것입니다.
논쟁
Google의 변경 사항은 주로 광고 차단기에 대한 이야기의 다른 측면을 듣기 전까지는 의미가 있는 것처럼 보입니다. 이 특정 API 마이그레이션은 가장 널리 사용되는 광고 차단기 중 하나의 작동 방식을 근본적으로 변경하므로 광고 차단기를 제거하는 Google의 방법으로 간주됩니다. 이는 Google이 사용자 보안의 관점보다는 비즈니스 관점에서 이러한 변화를 지향한다는 '이론'과 관련이 있습니다. 결국 Google은 수익을 광고에 크게 의존하고 있으며 광고 차단 프로그램은 이러한 측면에서 Google 고객에게 직접적인 위협으로 인식되고 있습니다. Alphabet의 2018 SEC 양식 10-K 제출 (을 통해 레지스터):
새로운 기술과 기존 기술은 광고를 맞춤화하는 능력에 영향을 미치거나 온라인 광고를 차단하여 비즈니스에 해를 끼칠 수 있습니다.
맞춤형 광고를 더욱 어렵게 만들거나 광고 표시를 완전히 차단하고 일부 제공업체를 차단하는 기술이 개발되었습니다. 의 온라인 서비스에는 타사 디지털의 핵심 기능을 잠재적으로 손상시킬 수 있는 통합 기술이 있습니다. 광고하는. Google 수익의 대부분은 온라인 광고 게재와 관련하여 우리에게 지불된 수수료에서 발생합니다. 결과적으로, 그러한 기술과 도구는 당사의 운영 결과에 부정적인 영향을 미칠 수 있습니다.
구글은 그래야만 했다 성명을 발표하다 이 문제를 해결하기 위해 변경 사항은 사용자 개인 정보 보호를 위한 것이며 광고 차단 프로그램에 대한 직접적인 공격이 아니라는 입장을 반복합니다.
우리는 광고 차단기의 개발을 막거나 사용자의 광고 차단을 막지 않습니다. 대신, 우리는 콘텐츠 차단기를 포함한 개발자가 사용자의 개인 정보를 보호하는 방식으로 확장 프로그램을 작성하도록 돕고 싶습니다.
Google Chrome에서 사용할 수 있는 가장 인기 있는 광고 차단기 중 두 가지를 참조해야 합니다. 유블록 오리진 그리고 애드블록 플러스, 둘 다 동일한 콘텐츠 차단 결과를 얻기 위해 서로 다른 접근 방식을 취합니다. uBlock Origin은 Web Request API에 크게 의존하고 있으며 커뮤니티는 수년 동안 이 확장을 선호해 왔습니다. Adblock Plus 및 기타 콘텐츠 차단 확장 프로그램도 웹 요청의 차단 부분에 의존하므로 이 API에 대한 변경 사항은 결국 적어도 일부 용량에서 대부분의 콘텐츠 차단기에 영향을 미치게 됩니다.
Web Request를 더 이상 사용하지 않으려는 Google의 추진은 본질적으로 현재 형식의 uBlock Origin을 종료하게 되며 이는 실제로 많은 사용자에게 영향을 미칠 것입니다. 충성심이 없는(그리고 광고 차단이 달성되는 방법에 대해 스스로를 귀찮게 할 의도가 없는) 사용자는 자신의 단점이 있는 대체 솔루션을 찾을 것이지만 불가능해질 것입니다. 충성도가 높은 사람들과 지지자들은 이 특정 API의 광고 차단기에 맞서기 위해 웹사이트에서 결국 등장하게 될 다양한 기술을 우회하기 위해 새로운 필터링 엔진 설계를 고안해야 합니다.
선언적 네트 요청(Declarative Net Request)도 다소 제한된 필터링 엔진으로 제안되었습니다. 처음에 계획된 확장명당 정적 필터 규칙(설치 중에 선언된 규칙)에 대해 30,000개의 규칙 제한을 갖습니다. 확장명당 동적 필터 규칙에 대한 규칙 제한은 5,000개입니다(설치 후 추가할 수 있는 규칙). 초과 규칙은 무시됩니다. 이는 Adblock Plus용 EasyList 자체에 70,000개의 규칙이 있는 반면 uBlock Origin은 100,000개 이상의 규칙으로 실행되도록 구성할 수 있기 때문에 약간의 문제입니다. 커뮤니티의 초기 반발 이후, Google이 응답했습니다. 정적 규칙 제한을 확장당 규칙 30,000개에서 전역 최대 규칙 150,000개로 변경하겠다고 약속합니다. 그러면 사용자가 광고 차단기와 함께 규칙이 많은 다른 스크립트를 사용하지 못하게 되는 부작용이 있으므로 사용자는 자신의 선호도에 따라 저글링해야 합니다.
제한된 필터링 제한 외에 Declarative Net Request 정적 URL로만 리디렉션할 수 있습니다.이므로 패턴 일치에 대한 지원이 포함되지 않습니다. uBlock Origin은 패턴 일치에 크게 의존하며 확장 프로그램 개발자는 개조는 불가능하다고 밝혔습니다 API 요구 사항을 충족하기 위해 확장 프로그램의 일치 알고리즘을 사용합니다. 또한 API는 단순히 필터 목록을 업데이트하기 위해 완전한 확장 업데이트가 필요합니다. 이는 다음을 고려하면 너무 빈번한 활동입니다. 필터 목록이 업데이트되는 빈도. 물론 이러한 업데이트는 Google의 확장 프로그램 검토 기준 및 프로세스에 따라 달라집니다.
반면, Google은 웹 요청에서 벗어나려는 의도가 웹 요청에서 비롯된다는 입장을 항상 유지해 왔습니다. Web Request API는 현재 형태로는 너무 강력하고 보안 측면에서 매우 넓은 여지를 열어두기 때문입니다. 남용. Google이 악성 확장 프로그램의 42%가 이 API를 악용했다고 언급했듯이 이러한 남용은 단순히 이론적인 것이 아닙니다. 애플 사파리의 콘텐츠 차단기 API 악성 개발자가 악용할 여지가 적기 때문에 비슷한 이유로 Declarative Net Request처럼 설계되었습니다. 너프된 웹 요청에서는 네트워크 요청을 계속 관찰할 수 있지만 관련 호스트에 대한 권한이 필요합니다. Manifest V3에서는 호스트 권한도 크게 변경되어 설치 시 더 이상 포괄적인 방식으로 부여할 수 없습니다.
Google은 또한 성능 오버헤드를 전환 동기로 사용했습니다. 네트워크 요청 평가는 확장의 JavaScript 스레드에서 이루어지므로 성능이 저하될 수 있습니다. 반박으로 uBlock Origin의 개발자는 자신의 확장 프로그램이 상당한 성능 저하가 발생하지 않습니다. 적용할 정적 필터가 140,000개나 되는 경우에도 마찬가지입니다. 발생한 비용은 원격 서버에서 다운로드가 차단되어 브라우저에서 처리되지 않는 리소스에 의해 쉽게 복구된다고 주장됩니다.
Google이 이러한 추론을 사용하지 않더라도 웹 요청에 대한 한 가지 주장은 광고 차단의 효율성을 위해 이루어질 수도 있습니다. 웹 요청을 사용하면 확장 프로그램이 시간 내에 응답하지 않는 경우(지연 또는 충돌로 인해) 네트워크 처리 요청이 명백히 허용되므로 광고가 광고 차단기를 통과할 수 있습니다. 반면에 선언적 네트 요청(Declarative Net Request)은 이러한 단점을 겪지 않습니다. 대신 광고는 정적 규칙에 걸리지 않으면 통과하게 되며, 이런 일이 자주 발생합니다.
결론
위의 설명에서 선언적 네트 요청은 차단을 위한 1:1 기능 복제가 아니라는 것이 분명합니다. Web Request API의 기능과 확장 개발자는 자신의 노력이 방해를 받게 되면 당황하게 될 것입니다. 그러한 변화. 그러나 Google의 추론에는 무게도 있습니다. 웹 요청은 너무 강력하므로 그 힘은 더욱 강력해야 합니다. 사용자 커뮤니티(일반 사용자와 일반 사용자로 구성됨)의 더 큰 관심으로 인해 축소되었습니다. 매니아).
Declarative Net Request로의 움직임은 긍정적인 PR 움직임일 수도 있습니다. 결국 Google은 내장된 콘텐츠 차단기 API를 Chrome에 추가하고 있습니다! 그러나 새로운 API에는 자체적으로 엄격한 제한이 있기 때문에 커뮤니티는 이를 자신들의 날개가 잘린 것으로 간주합니다. 이상적인 세상에서 Google은 새로운 API를 추진하기 전에 uBlock Origin과 같은 광고 차단기의 작동을 탐색했어야 했습니다. 현재로서는 새 API는 사용자가 두 개의 필터가 많은 확장을 사용하려는 시나리오를 수용하기 위해 규칙 제한을 더욱 완화할 수 있습니다.
에 따르면 레지스터, Manifest V3 변경 사항이 포함된 첫 번째 빌드는 2019년 7월부터 제공될 예정입니다. Google이 이러한 빌드를 통해 확장 개발자 커뮤니티로부터 받은 피드백을 수용하기를 바랍니다.
XDA의 편집장인 Mishaal Rahman의 의견과 도움에 특별히 감사드립니다!
편집: 기사에서는 Adblock Plus의 작업을 Declarative Net Request API의 작업과 잘못 동일시했습니다. 그에 따라 기사가 수정되었습니다. Adblock Plus는 Web Request API의 차단 기능 제거로 인해 영향을 받습니다.