Google은 지난 1년 동안 MV3 확장 프로그램 플랫폼을 개선하는 방법에 관해 여러 콘텐츠 차단 확장 프로그램의 공급업체와 적극적으로 논의해 왔습니다. 이러한 논의를 바탕으로, 그중 많은 부분이 다른 브라우저와 공동작업으로 WebExtensions 커뮤니티 그룹 (WECG)에서 이루어졌으며, 상당한 개선사항을 출시할 수 있었습니다.
더 많은 정적 규칙 집합
필터 규칙 세트는 일반적으로 목록으로 그룹화됩니다. 예를 들어 더 일반적인 목록에는 모든 사용자에게 적용되는 규칙이 포함될 수 있지만, 더 구체적인 목록에는 일부 사용자만 차단하려는 위치별 콘텐츠가 숨겨져 있을 수 있습니다. 최근까지는 각 확장 프로그램에서 사용자에게 50개의 목록 (또는 '정적 규칙 집합')을 제공하고 이 중 10개를 동시에 사용 설정할 수 있었습니다. 커뮤니티와의 논의에서 확장 프로그램 개발자는 특정 사용 사례에 이 기준이 너무 낮다는 것을 보여주는 설득력 있는 증거를 제공했습니다. 이러한 논의를 고려하여 Chrome에서 API의 성능을 살펴본 결과, 이제 최대 50개까지 동시에 사용 설정할 수 있습니다. 이는 WECG에서 요청한 20개 한도보다 훨씬 높습니다. 또한 총 100개의 규칙 집합을 허용합니다. 이 기능은 Chrome 120에서 제공되며, 이 제안에 대한 초기 의견을 제공한 Firefox와 Safari 모두 한도 상향을 지원합니다.
더 많은 동적 규칙
대부분의 규칙은 '정적'이며 확장 프로그램의 각 업데이트와 함께 제공됩니다. 그러나 더 빈번한 업데이트와 사용자 정의 규칙을 지원하기 위해 확장 프로그램은 개발자가 Chrome 웹 스토어에 새 버전의 확장 프로그램을 업로드하지 않아도 동적으로 규칙을 추가할 수 있습니다.
확장 프로그램이 Chrome 웹 스토어 검토 중에 확인되지 않은 방식으로 요청을 동적으로 수정할 수 있으면 사용자에게 피싱 또는 데이터 도용의 위험이 발생합니다. 예를 들어 리디렉션 규칙을 악용하여 동의 없이 제휴사 링크를 삽입할 수 있습니다.
따라서 확장 프로그램이 최대 5,000개의 규칙만 추가할 수 있도록 허용하여 이 기능을 가급적 적게 사용하도록 유도하고 악용을 더 쉽게 감지할 수 있도록 했습니다.
하지만 AdGuard 및 Adblock Plus 등의 확장 프로그램 개발자는 자체 분석을 수행하고 한도를 높여야 더 많은 최신 규칙을 적용하고 맞춤 목록이 더 많은 사용자가 매니페스트 V3로 이전할 수 있다는 데이터를 공유했습니다. 실제로 AdGuard는 인기 목록이 매주 2,600회 이상 변경되고 맞춤 필터 목록을 사용하는 사용자의 5% 중 4분의 1이 총 5,000개가 넘는 동적 규칙을 사용하고 있다고 보고했습니다 (출처). AdGuard는 확장 프로그램을 매니페스트 V3으로 이전하는 데 큰 어려움이 있다고 지적했으며 다른 콘텐츠 차단기에서도 유사한 의견을 보내왔습니다.
block 또는 allow 작업이 있는 필터 규칙과 같은 일부 필터 규칙은 훨씬 더 안전하고 악용될 가능성이 적은 것으로 확인되었습니다. 또한 광고 차단 필터 규칙의 대부분을 차지합니다. 이를 바탕으로 웹 확장 프로그램 커뮤니티 그룹에서 위험도가 낮다고 간주되고 최대 30,000개까지 허용되는 일련의 규칙을 정의하기 위한 초안을 작성하고 제안서를 공유했습니다. 성능 회귀를 방지하기 위해 여전히 상한선을 유지하고 있습니다.
이 제안은 웹 확장 프로그램 커뮤니티 그룹에서 지원되었으므로 구현되었습니다. Chrome 121부터 block, allow, allowAllRequests 또는 upgradeScheme 작업이 있는 규칙으로 정의되는 안전한 DNR 규칙에 30,000개라는 더 높은 한도가 적용됩니다.
AdGuard에서 공유한 데이터에 따르면 98~99%의 규칙이 이 상향된 한도의 혜택을 받을 것으로 예상됩니다. 나머지 규칙은 계속 지원되며 기존 한도 내에서 추가할 수 있습니다.
Chrome에서는 MAX_NUMBER_OF_DYNAMIC_RULES 상수로 사용할 수 있습니다. 다른 모든 동적 네트워크 요청 규칙의 규칙 한도는 5,000개로 유지됩니다.
규칙 세트 크기가 줄었습니다.
Chrome 118에서는 커뮤니티의 의견을 바탕으로 isUrlFilterCaseSensitive 필드의 기본값을 false로 변경했습니다. 이 필드는 URL로 필터링하는 규칙에서 대소문자를 구분하는지 여부를 제어하며, 대부분의 개발자가 확장 프로그램에서 다른 기본값을 사용하고 있는 것으로 확인되었습니다. 따라서 값을 여러 번 설정해야 했습니다. 이렇게 변경하면 개발자는 규칙 집합의 크기를 크게 줄일 수 있습니다.
다음 단계
Google은 최대한 많은 사용 사례를 지원할 수 있도록 declarativeNetRequest API에 지속적으로 투자하고 있으며 커뮤니티와 계속 협력할 수 있기를 기대합니다. 특히 이 작업을 진행하는 데 필요한 상당한 양의 데이터를 공유해 주신 AdGuard와 이 API 설계의 중요한 역할을 담당한 모든 브라우저 공급업체를 비롯하여 WECG 회원들의 참여에 감사드립니다.
YouTube는 필요에 따라 한도를 검토하고 조정할 예정입니다. 이를 지원하기 위해 YouTube는 조만간 이 작업의 일환으로 수집한 일부 데이터를 공유할 계획입니다. 또한 PDF 뷰어 확장 프로그램에서 자주 요청하는 응답 헤더와 일치시키는 기능과 같은 기능을 추가하고 있습니다. 어떤 경우든 Google은 계속해서 진행 상황을 전달하고 웹 확장 프로그램 커뮤니티 그룹을 아이디어를 논의하고 다음에 살펴볼 사항을 조율하는 장소로 정기적으로 활용할 것입니다.