Chrome 확장 프로그램에서 콘텐츠 및 네트워크 필터링을 구현하는 방법에는 여러 가지가 있습니다. 이 가이드에서는 확장 프로그램에서 사용할 수 있는 콘텐츠 필터링 기능과 Chrome 확장 프로그램에서 사용할 수 있는 다양한 필터링 접근 방식, 기법, API를 간략하게 설명합니다.
네트워크 요청 필터링
Chrome 확장 프로그램에서 네트워크 요청을 필터링하는 기본적인 방법은 chrome.declarativeNetRequest API를 사용하는 것입니다. 선언적 넷 요청을 사용하면 개발자는 선언적 규칙을 지정하여 네트워크 요청을 차단하거나 수정할 수 있습니다. 선언적 Net Request 규칙 형식은 대부분의 광고 차단 프로그램에서 사용하는 필터 목록 구문의 기능을 기반으로 합니다.
이러한 규칙으로 수행할 수 있는 작업은 다음과 같습니다.
- 네트워크 요청을 차단합니다.
- URL 스키마를 보안 스키마로 업그레이드합니다 (http에서 https로 또는 ws에서 wss로).
- 네트워크 요청을 리디렉션합니다.
- 요청 또는 응답 헤더를 수정합니다.
Chrome은 확장 프로그램과 번들로 묶인 규칙 및 동적으로 업데이트되는 규칙 (원격 구성 또는 사용자 입력에 대한 응답 등)을 지원합니다.
확장 프로그램과 필터 규칙 번들로 묶기
확장 프로그램 패키지에 포함된 규칙을 '정적 규칙'이라고 합니다. 이러한 규칙은 확장 프로그램이 설치되거나 업그레이드될 때 설치되고 업데이트됩니다. Chrome에서는 확장 프로그램이 선언할 수 있는 정적 규칙 수가 제한됩니다.
정적 선언적 넷 요청 규칙의 경우 Chrome에는 설치된 확장 프로그램 세트에서 함께 사용할 수 있는 300,000개의 규칙의 글로벌 공유 풀이 있습니다. 또한 모든 확장 프로그램에는 30, 000개의 정적 규칙이 허용됩니다. 예를 들어 사용자에게 콘텐츠 필터링 확장 프로그램을 하나만 설치한 경우 확장 프로그램은 최대 330,000개의 정적 선언적 순 요청 규칙을 사용할 수 있습니다. 이 규칙이 몇 개인지 알아보기 위해 대부분의 광고 차단 프로그램에서 널리 사용되는 EasyList 필터 목록은 약 35,000개의 네트워크 규칙으로 구성되어 있습니다.
정적 선언적 순 요청 규칙은 다양한 규칙 세트로 구성할 수 있습니다. 확장 프로그램은 최대 100개의 정적 규칙 세트를 지정할 수 있으며 이러한 규칙 세트 중 50개를 한 번에 사용 설정할 수 있습니다.
런타임에 필터 규칙을 동적으로 추가
일부 규칙은 확장 프로그램과 함께 번들로 묶을 수 없습니다. 대신 확장 프로그램은 런타임에 추가해야 합니다. 이러한 규칙을 '동적 규칙'이라고 합니다.
동적 선언적 순 요청 규칙의 경우 Chrome은 확장 프로그램당 최대 30,000개의 안전한 동적 규칙을 허용합니다. block, allow, allowAllRequests, upgradeScheme 등 대부분의 규칙은 안전한 규칙으로 간주됩니다. 안전한 것으로 간주되지 않는 규칙 (예: redirect)에도 계속해서 동적으로 추가할 수 있지만, 최대 한도인 5,000개로 제한하여 동적 규칙 30,000개에 합산됩니다. 이해를 돕기 위해 허용 목록 필터 목록에 있는 규칙의 98~99% 는 안전한 규칙입니다.
콘텐츠 필터링 확장 프로그램은 각각 정적 및 동적 규칙을 사용하여 알려진 필터링 규칙을 확장 프로그램과 번들로 묶고 필요할 때마다 서버에서 새 콘텐츠 필터링 규칙으로 확장 프로그램을 업데이트할 수 있습니다.
관찰된 요청을 기준으로 규칙 조정
광고 생태계는 끊임없이 진화하고 있으며 이에 따라 콘텐츠 필터도 업데이트되어야 합니다. chrome.webRequest와 동적 선언적 순 요청 규칙을 결합하면 잠재적인 개인 정보 보호 위반에 대한 네트워크 요청을 분석하고 향후 이를 차단할 수 있습니다.
기본 접근 방식은 다음과 같습니다.
chrome.webRequestAPI를 사용하여 웹 요청을 분석하고 머신러닝 등의 개인 정보 보호 요구사항을 충족하지 않는 요청을 자동으로 식별합니다.- 향후 유사한 요청이 차단되도록 2단계에서 확인한 각 요청에 대해 동적 선언적 순 요청 규칙을 만듭니다.
- (선택사항) 확인된 선언적 Net Request 규칙을 서버에 다시 전송하여 다음 확장 프로그램 업데이트 시 정적 선언적 Net Request 규칙으로 추가할 수 있도록 합니다.
이 접근 방식의 이점은 분석이 비동기식으로 이루어지고 웹사이트 성능에 부정적인 영향을 미치지 않는다는 것입니다.
사용자가 자체 필터링 규칙을 정의하도록 허용
확장 프로그램에서 필터 구성 UI를 제공하여 사용자가 자체 콘텐츠 필터링 규칙을 정의하도록 할 수 있습니다. 이러한 사용자 정의 규칙을 선언적 순 요청 규칙으로 변환하여 동적 규칙으로 추가합니다. 이러한 규칙은 브라우저 세션 및 확장 프로그램 업그레이드에 걸쳐 유지되므로 사용자에게 계속 제공됩니다. 이 방법을 사용하면 사용자가 최대 30,000개의 맞춤 규칙을 추가할 수 있습니다.
웹페이지의 요소 필터링
네트워크 요청 필터링은 콘텐츠 필터링의 중요한 요소 중 하나일 뿐입니다. 원치 않는 콘텐츠를 웹페이지에서 직접 삭제하는 것도 또 다른 중요한 부분입니다. 예를 들어 이지 필터 목록 규칙의 40% 이상이 클라이언트가 페이지 요소를 숨기는 방법을 정의합니다.
이렇게 하려면 콘텐츠 스크립트를 사용하면 됩니다. 콘텐츠 스크립트는 웹페이지의 컨텍스트에서 실행되며 DOM을 사용하여 변경할 수 있습니다.
Chrome 확장 프로그램에서는 원격 호스팅 코드를 실행할 수 없습니다. 하지만 숨길 요소에 대한 서버의 데이터는 구성 데이터로 간주되므로 영향을 받지 않습니다. 따라서 필요할 때마다 런타임에 요소 규칙을 업데이트할 수 있습니다.
정책에 설치된 확장 프로그램에서 네트워크 요청 필터링
엔터프라이즈 및 교육의 사용 사례에서는 콘텐츠를 기반으로 요청을 필터링하는 등 콘텐츠 및 네트워크 필터링에 대해 매우 엄격한 요구사항을 적용하는 경우가 많습니다. 이러한 사용 사례를 지원하기 위해 정책에 설치된 확장 프로그램에는 네트워크 요청을 필터링하고 차단하는 추가적인 방법이 있습니다. webRequest API의 이벤트에 '차단' 옵션을 사용하면 모든 요청에서 맞춤 로직을 실행하는 프로그래매틱 콘텐츠 필터를 구현하여 요청을 차단해야 하는지 여부를 결정할 수 있습니다. 정책에 따라 설치된 확장 프로그램은 신뢰도가 더 높으므로 이러한 확장 프로그램으로 제한됩니다.
내비게이션 요청 가로채기
탐색 요청은 선언적 순 요청 규칙을 사용하여 필터링할 수 있습니다. 예를 들어 사용자를 원하는 도착 페이지로 리디렉션하는 추적 URL을 우회할 수 있습니다. 이를 처리하는 한 가지 방법은 탐색 요청 https://tracker.com?redirect=https%3A%2F%2Fexample.com를 확장 프로그램 페이지 (웹 액세스 가능 리소스로 구성해야 함)로 리디렉션하는 것입니다. 그러면 스크립트에서 링크 추적기를 우회하여 리디렉션 타겟을 추출하고 window.location.replace("https://example.com")를 사용하여 대상으로 리디렉션합니다.