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